因應資訊科技快速發展,行動裝置及無線網路已明顯改變大眾取得資訊的方式,網路接取服務載具從電腦網頁趨向於行動裝置網頁,甚至發展為可搭配行動裝置本身設計的軟體服務,針對不同服務特性差異所個別化設計的應用程式,以提供更個人化訴求服務的使用體驗。
為使行動化應用軟體(Mobile Application; Mobile App)的無障礙人工檢測作業,有依循的作業方式,國家通訊傳播委員會參考全球資訊網協會(W3C),於2018年6月5日公告「Web Content Accessibility Guidelines (WCAG) 2.1」,及「網站無障礙規範」,新增加行動版的架構與國內外相關經驗,建立行動化應用軟體(Mobile Application; Mobile App)的無障礙人工檢測指引項目,以提供行動化應用軟體開發人員對無障礙設計有明確的遵循實例,並使檢測有所依據。
本檢測指引提供行動化應用軟體(Mobile Application; Mobile App)開發者、管理者及檢測者,於開發、管理及檢測行動化應用軟體無障礙設計時依循。
一、檢測項目架構說明
行動化應用軟體檢測指引項目主要參照「網站無障礙規範」與行動化裝置本身的特性資料呈現的輸出方式、輸入資料及整體設計,先分為三大特性如呈現組件、互動組件及設計方式,其主要對應如下說明:
(一)呈現組件主要對應行動化應用軟體輸出的部份。
(二)互動組件主要對應行動化應用軟體互動輸入的部份。
(三)設計方式為對應行動化應用軟體的設計原則。
再依三特性之訂定各項檢測單,共計13張檢測單對應網站無障礙規範的13指引,並將相關的內容整合,其概念為相同的檢核點即在同一類別內,如AT替代文字與圖片的檢測單內,即為文字與圖片相關之組件做為檢測原則,以考量開發者及檢測者進行測試時能同時將相關組件一併檢測並完成處理。
各檢測單區分出不同的檢核點,從檢核點中定義出不同的檢測條件,共計55個檢核點,含35個必要檢核點及20個選項檢核點,其與網站無障礙規範指引之對應如表1所示。
表1:行動化應用軟體檢測單對應網站無障礙規範指引
|
特性
|
檢測單
|
對應13指引
|
檢測條件
|
檢核點
|
|
必要
|
選項
|
總計
|
|
呈現組件
|
AT替代文字與圖片
|
指引1.1 替代文字
|
4
|
3
|
7
|
|
AV時序媒體
|
指引1.2 時序媒體
|
2
|
3
|
5
|
|
NT通知
|
指引3.3 輸入協助
|
2
|
2
|
4
|
|
互動組件
|
TS觸控操作
|
指引2.5 輸入方式
|
3
|
1
|
4
|
|
FC焦點
|
指引2.1 鍵盤可操作
|
3
|
0
|
3
|
|
FM表單
|
指引3.3 輸入協助
|
4
|
2
|
6
|
|
LK鏈結
|
指引2.4 可導覽
|
2
|
1
|
3
|
|
DC動態內容
|
指引2.2 充足時間
指引2.3 預防痙攣和身體不適反應
|
5
|
0
|
5
|
|
ST結構
|
指引2.4 可導覽
|
2
|
2
|
4
|
|
設計方式
|
AD可調適設計
|
指引1.3 可調適
|
2
|
1
|
3
|
|
DT可辨識設計
|
指引1.4 可辨識
|
3
|
2
|
5
|
|
PD可預期性設計
|
指引3.1 可讀性
指引3.2 可預期性
|
3
|
1
|
4
|
|
CP相容性設計
|
指引4.1 相容性
|
0
|
2
|
2
|
|
總計
|
35
|
20
|
55
|
人工檢測指引分為呈現組件、互動組件及設計方式,其各特性所含括之檢測單及內容細項,如下分述之。
(一)呈現組件
此特性主要對應行動化應用軟體輸出的部份,故包含替代文字與圖片、時序媒體以及通知三大檢測單。其共有8個必要檢核點,分別為替代文字檢測單之非文字內容的替代品、裝飾性內容、驗證碼或身份認證、視覺格式;時序媒體檢測單之視聽內容的替代品、不得自動播放音訊;通知檢測單之包容性通知、錯誤訊息和更正;以及8個選項檢核點,分別為替代文字檢測單之系列圖片、文字圖片、背景圖片;時序媒體檢測單之提供詮釋資料、音量控制、不得音訊衝突;通知檢測單之標準作業系統通知、反饋和幫助,共計16個檢核點,各檢測單之檢核點與內容說明如表2至表4所示。
二、檢測項目內容
表2:AT替代文字與圖表檢核點說明列表
|
檢測條件
|
檢核點
|
內容說明
|
|
必要
|
AT1非文字內容的替代品
|
替代文字必須簡要描述圖片,物件或元件的編輯意圖或目的。
|
|
必要
|
AT2裝飾性內容
|
裝飾性圖片必須從輔助技術中隱藏。
|
|
必要
|
AT3驗證碼或身份認證
|
驗證碼或身份認證應該依據行動裝置特性提供另一種驗證方式。
|
|
必要
|
AT4視覺格式
|
不得單獨使用視覺格式來傳達含義
|
|
選項
|
AT5系列圖片
|
在一組緊連圖片中的第一個項目使用替代文字,描述該組圖片的所有項目資訊。
|
|
選項
|
AT6文字圖片
|
除了標誌圖徽(logo)、圖示(icon)或使用畫布(canvas)的互動式內容,應避免文字圖片。
|
|
選項
|
AT7背景圖片
|
傳達訊息或特別含義的背景圖片應該有其他無障礙的替代方式。
|
表3:AV時序媒體檢核點說明列表
|
檢測條件
|
檢核點
|
說明
|
|
必要
|
AV1視聽內容的替代品
|
時序媒體的替代內容(如字幕,手語,音訊描述和字幕)必須在可用的情況下隨嵌入式媒體一起提供。
|
|
必要
|
AV2不得自動播放音訊
|
除非使用者知道會產生音訊或事先知道該音訊可提供暫停/停止/靜音的按鈕,否則音訊不得自動播放。
|
|
選項
|
AV3提供詮釋資料
|
應該為所有媒體提供相關的詮釋資料。
|
|
選項
|
AV4音量控制
|
應該為背景音樂、環境聲音、敘述性和編輯上重要的音效提供單獨的音量控制。
|
|
選項
|
AV5不得音訊衝突
|
遊戲或互動式媒體中的敘事音訊不應蓋過或與原生輔助技術衝突。
|
表4:NT通知檢核點說明列表
|
檢測條件
|
檢核點
|
說明
|
|
必要
|
NT1包容性通知
|
通知訊息必須同時可見和可聽。
|
|
必要
|
NT2錯誤訊息和更正
|
必須提供明確的錯誤訊息。
|
|
選項
|
NT3標準作業系統通知
|
在可用且適當的地方,應使用標準作業系統通知。
|
|
選項
|
NT4反饋和幫助
|
適當時應提供非關鍵性的反饋或幫助。
|
(二)互動組件
此特性主要對應行動應用軟體之互動輸入的部份,故包含觸控操作、焦點、表單、鏈結、動態內容以及結構等6張檢測單。其共有19個必要檢核點,分別為觸控操作檢測單的單點觸控、觸發操作、觸控目標尺寸;焦點檢測單的可聚焦元件、鍵盤陷阱、焦點順序;表單檢測單的標記表單控件、表單輸入、分組表單元件、管理焦點;鏈結檢測單的描述式鏈結、合併重複的鏈結;動態內容檢測單的禁止閃爍、動態內容控制、懸浮內容、頁面更新及超時;結構檢測單的單一頁面標題與分組元件;以及6個選項檢核點,分別為觸控操作檢測單的並行輸入機制;表單檢測單的表單佈局、輸入提示;鏈結檢測單的鏈結目的格式;結構檢測單的標題及容器與地標,共計25個檢核點,各檢測單之檢核點與內容說明如表5至表10所示。
表5:TS觸控操作之檢核點說明列表
|
檢測條件
|
檢核點
|
說明
|
|
必要
|
TS1單點觸控
|
確認多點觸控或路徑觸控需有替代的單點觸控。
|
|
必要
|
TS2觸發操作
|
觸發操作以向上事件為主,需有防止誤觸設計。
|
|
必要
|
TS3觸控目標尺寸
|
觸控目標尺寸至少 48dp*48dp(9mm*9mm)。
|
|
選項
|
TS4並行輸入機制
|
容許並行輸入機制的方式,如外接鍵盤或手寫筆等。
|
表6:FC焦點之檢核點說明列表
|
檢測條件
|
檢核點
|
說明
|
|
必要
|
FC1可聚焦元件
|
所有互動元件必須是可聚焦的,非互動元件必須不能聚焦。
|
|
必要
|
FC2鍵盤陷阱
|
不得有鍵盤陷阱。
|
|
必要
|
FC3焦點順序
|
必須以有意義的順序瀏覽可操作的內容。
|
表7:FM表單之檢核點說明列表
|
檢測條件
|
檢核點
|
說明
|
|
必要
|
FM1標記表單控件
|
必須標記所有表單控件。
|
|
必要
|
FM2表單輸入
|
必須指明並支援預設輸入格式。
|
|
必要
|
FM3分組表單元件
|
控件、標籤和其他表單元件必須正確配對。
|
|
必要
|
FM4管理焦點
|
在使用者輸入過程中,焦點或上下文不得自動更改。
|
|
選項
|
FM5表單佈局
|
標籤必須放置在靠近相關表單控件的位置,並適當佈置。
|
|
選項
|
FM6輸入提示
|
在需要時,應提供輸入提示並可提供視覺和聽覺表現。
|
表8:LK鏈結之檢核點說明列表
|
檢測條件
|
檢核點
|
說明
|
|
必要
|
LK1描述式鏈結
|
鏈結和導航文字必須唯一地描述鏈結或項目的目標或功能。
|
|
必要
|
LK2合併重複的鏈結
|
必須將到同一組件的重複鏈結合併成單個鏈結。
|
|
選項
|
LK3鏈結目的格式
|
告知使用者將要使用不同行動化應用軟體開啟。
|
表9:DC動態之檢核點說明列表
|
檢測條件
|
檢核點
|
說明
|
|
必要
|
DC1禁止閃爍
|
動態內容不得明顯或有意地在任何一秒鐘中閃爍三遍。
|
|
必要
|
DC2動態內容控制
|
更新媒體或動畫內容必須具有暫停,停止或隱藏控件。
|
|
必要
|
DC3懸浮內容
|
指標懸停時觸發的附加內容可由使用者移除或移動,指標可以在附加內容上移動,而且原內容不會消失。
|
|
必要
|
DC4頁面更新
|
不得在沒有警告的情況下使用自動頁面重整。
|
|
必要
|
DC5超時
|
時間限制的回應必須可調整。
|
表10:ST結構之檢核點說明列表
|
檢測條件
|
檢核點
|
說明
|
|
必要
|
ST1單一頁面標題
|
所有頁面或螢幕標題必須唯一且清晰可辨。
|
|
必要
|
ST2分組元件
|
可控元件,以分組進行呈現時,訪問須表示為同一整體結構,非單一控件。
|
|
選項
|
ST3標頭
|
內容必須提供平台支援的邏輯和分層標頭結構。
|
|
選項
|
ST4容器與地標
|
容器應用於描述平台支援的頁面/螢幕結構。
|
(三)設計方式
此特性主要對應行動化應用軟體的設計原則,故包含替代可調適設計、可辨識設計、可預期性設計以及相容性設計等4張檢測單。有 8個必要檢核點,分別為可調適設計檢核單的內容順序、螢幕方向;可辨識設計檢測單的可操作元件、文字對比及調整文字尺寸;可預期性設計檢測單的指示語言、一致的導覽及一致的識別;以及6個選項檢核點,分別為可調適設計檢測單的可調整設定;可辨識設計檢測單的非文字對比、流動排版;可預計性設計檢測單的依請求變更;相容性設計檢測單的漸進式功能以及功能切換,共計14個檢核點,各項檢核點說明如表11至表14所示。
表11:AD可調適設計之檢核點說明列表
|
檢測條件
|
檢核點
|
說明
|
|
必要
|
AD1內容順序
|
內容順序必須符合邏輯順序。
|
|
必要
|
AD2螢幕方向
|
確認內容可以響應設備變更螢幕方向。
|
|
選項
|
AD3可調整設定
|
互動式媒體(包括遊戲)應根據使用者的能力和偏好進行可調。
|
表12:DT可辨識設計之檢核點說明列表
|
檢測條件
|
檢核點
|
說明
|
|
必要
|
DT1可操作元件
|
鏈結和其他可操作元素必須清楚區分。
|
|
必要
|
DT2文字對比
|
小文字(小於 18 點標準/14 點粗體)需符合 4.5:1 ;大文字(大於 18 點標準/14 點粗體)需符合 3.0:1。
|
|
必要
|
DT3調整文字尺寸
|
確認文字可以放大到200%而不會失去內容或功能性。
|
|
選項
|
DT4非文字對比
|
使用者介面元件和圖形物件內容的視覺呈現與相鄰顏色的對比度至少為3:1。
|
|
選項
|
DT5流動排版
|
確保內容響應設備螢幕大小自動調整,並避免二維捲軸。
|
表13:PD可預期性設計之檢核點說明列表
|
檢測條件
|
檢核點
|
說明
|
|
必要
|
PD1指示語言
|
指定頁面或應用程式的語言,並且必須指示語言的更改。
|
|
必要
|
PD2一致的導覽
|
除非使用者做出變更,否則在一組元件中,反覆出現的導覽機制每次都要有相同的相對順序。
|
|
必要
|
PD3一致的識別
|
具有相同功能性的元件,就要有一致的識別。
|
|
選項
|
PD4依請求變更
|
只有當使用者提出請求時,才開始變更上下文,否則就要有個機制來關掉這類變更。
|
表14:CP相容性設計之檢核點說明列表
|
檢測條件
|
檢核點
|
說明
|
|
選項
|
CP1漸進式功能
|
以漸進式方式構建應用程式和網站,以確保使用者在離線或支援不完整時仍有功能體驗。
|
|
選項
|
CP2功能切換
|
和行動裝置原有的電話、簡訊、電子郵件等功能可相容切換。
|
為使人工檢測指引的55個檢核點說明能在未來與其他無障礙要求文檔的一致性進行一致的解釋,並促進無障礙測試的一致結果,故參照全球資訊網協會(W3C),於2019年10月31日公告「Accessibility Conformance Testing (ACT) Rules Format 1.0」(以下簡稱ACT規則)文件,將各檢核點依此格式進行說明及編輯排版。
ACT規則格式是說明如何針對無障礙要求的特定方面測試特定類型的內容,旨在描述手動無障礙測試及無障礙測試工具執行的自動測試,並記錄如何測試無障礙要求,將使無障礙測試和可重複的測試結果透明化,測試案例也被編寫為ACT規則的一部分,以提供一種驗證規則的實現能否成功確定預期結果的方法。
表15說明ACT格式各個項目代表之涵義,於後續將55個檢核點套用此格式完整呈現各個檢核點目的及期望成果,於伍、檢核點檢測標準逐一說明。
表15:ACT規則的格式說明
|
原文定義
|
中文定義
|
內容說明
|
|
Rule Identifier
|
規則識別碼
|
ACT規則必須具有識別碼。當規則是規則集的一部分時,此識別碼必須具唯一性。識別碼可以是任何文字,例如純文字、URL或數據庫識別碼,此項也可用於文件名稱的識別碼;其可以包括一個技術目錄,後跟一個包含元素名稱或屬性的控制碼,如:html+svg/視訊替代等。
|
|
Descriptive Title
|
規則名稱
|
簡易說明各項檢核點內容。
|
|
Rule Description
|
規則說明
|
ACT規則必須以通俗易懂的語言進行描述,簡要說明該規則的作用,如:此規則檢查HTML頁面是否具有標題。
|
|
Rule Type
|
規則類型
|
ACT規則必須具有以下規則類型之一:
原子規則是描述如何測試特定類型的解決方式。包含對測試主題要測試哪些元素、節點或其他“部分”以及何時將這些測試目標視為通過或未通過規則的精確定義。這些規則應保持小而原子化,這表示原子規則測試單個“條件”,並且無需使用其他規則的結果。
複合規則是描述如何將多個原子規則的結果組合到測試目標的單個結果中。複合規則可以有多個“條件”,每個條件都可在單獨的原子規則中進行測試。複合規則的邏輯是描述如何使用這些滿足條件中的任何一個或它們的某些組合來確定單個結果。
複合規則不能包含其他複合規則,每當需要嵌套的複合規則時,所有相關的原子規則都可以直接組合到新的複合規則中。
並非所有原子規則都必須是複合規則的一部分,當需要組合多個原子規則的結果以確定測試主題是否滿足無障礙要求時,將使用複合規則。
|
|
Accessibility Requirements Mapping
|
無障礙要求對應
|
當ACT規則旨在測試一個或多個無障礙要求文檔的一致性時,該規則必須列出當一個或多個規則的結果失敗時,未滿足的文檔中的所有無障礙要求。例如,在為WCAG設計規則時,該規則測試圖片按鈕是否具有替代文字,該規則應對應到成功準則1.1.1非文字內容和4.1.2名稱、角色、值。該ACT規則將在其無障礙要求對應中列出這兩個成功準則。
對應中的每個無障礙要求必須包括以下內容:
1.無障礙要求的名稱、標題、識別碼或摘要。
2.無障礙要求文檔名稱。
3.無障礙要求文檔的連結或引用(如果存在)。
4.與無障礙要求關聯的一致性級別(如果存在)。
案例:
1.1.1非文字內容
.必須符合 WCAG 2.0和WCAG 2.1 A級或更高級別
結果對應:
.任何失敗結果:不符合
.所有成功結果:需進一步測試
.未適用結果:需進一步測試
|
|
Applicability
|
適用性
|
主要為描述測試主題的哪些部分進行測試。
|
|
Expectations
|
期望
|
ACT規則必須包含一個或多個期望。期望描述對於源自適用性的測試目標的要求,以及對測試目標的明確肯定。當測試目標滿足所有期望時,測試目標就通過該項規則;若測試目標不能滿足所有期望,則測試目標未通過規則。如果沒有測試目標,則該規則的結果未適用。
|
|
Assumptions
|
假設條件
|
ACT規則必須列出評估測試環境所使用的技術或所測試的主題的任何已知假設,限制任何例外情況。例如,一條規則將部分測試WCAG 2.1成功準則1.4.3對比度(基於CSS特性檢查)(最低)可以聲明該規則僅適用於可使用CSS設置樣式的HTML文字內容,並且該規則不支援圖片文字。
有時,有多種可能的方式可以解釋無障礙要求。例如,在網頁內容可及性指引[WCAG]中,表情符號字符是“文字”還是“非文字內容”並不是很明顯。無論有什麼解釋,都必須記錄在規則中。
儘管這些假設必須包含在ACT規則中,但是當沒有已知的假設、限制或例外時,它可能為空。
|
|
Accessibility Support
|
無障礙支援
|
內容可以設計為依靠不同的輔助技術和使用者代理對特定輔助功能的支援。例如,使用特定WAI-ARIA 1.1功能的內容依賴於輔助技術和使用者代理支援的功能。該內容未適用於不支援WAI-ARIA的輔助技術和使用者代理。有關無障礙支援的Web技術使用,請參閱WCAG定義。
ACT規則必須包括對無障礙支援的已知限制。
儘管ACT規則中必須包含無障礙支持部分,但是當沒有已知的無障礙支持問題時,該部分可能為空。
案例:
檢查是否aria-error message用於滿足WCAG 2.1成功準則4.1.3狀態訊息的規則示例:
眾所周知,aria-error message屬性對多個主要螢幕報讀軟體的支援有限。不能依靠此方法獲得支援。其他選擇如即時區塊,可以作為替代。
|
|
Test Cases
|
測試案例
|
測試案例是可用於驗證ACT規則實現的內容(摘要)。每條規則必須為通過、失敗和未適用的結果具有一個或多個測試案例。一個測試案例包含兩個數據,一個是對規則提供每個輸入部分的摘要,一個是該規則的預期結果。測試案例具有兩個功能,首先是作為提供讀者瞭解規則的結果何時通過、失敗或未適用的示例場景。它還為無障礙測試工具和方法的開發人員和使用者提供服務,以驗證規則是否正確實現。
通過結果的示例:
<img alt="W3C Logo" src="image/w3c.png">
失敗結果的示例:
<img src="image/w3c.png">
未適用的結果示例:
<input type="image" alt="W3C Logo" src="image/w3c.png">
|
|
Change Log
|
變更紀錄
|
追踪ACT規則的更改很重要,以便規則的使用者可以瞭解測試結果的更改是由於執行測試時使用的規則的更改,還是內容本身的更改造成的。對 ACT 規則的所有更改(可以更改評估結果)都必須記錄在變更日誌中。變更日誌可以是規則文檔本身的一部分,也可以從中引用。
|
|
Glossary
|
參考詞彙
|
ACT規則必須有一個詞彙表部分。詞彙表必須包含結果定義,以及規則中適用性和期望部分中使用的任何定義。由於更改定義會更改規則,因此無法獨立於規則來維護這些定義。如果將共享詞彙表用於規則,則任何定義更改都必須包括在使用該定義的所有規則的變更日誌中。
|
為使本檢測指引能適用於行動化應用軟體無障礙檢測,55個檢核點依三特性與13張檢核單順序排列,每一檢核點皆採用ACT規則格式編排,其詳細內容說明如後。
一、呈現組件
此特性主要對應行動化應用軟體輸出的部份。
二、互動組件
此特性主要對應行動應用軟體之互動輸入的部份。
三、設計方式
此特性主要對應各行動化應用軟體的設計原則。
行動化應用軟體無障礙檢測指引共分為13檢測單,55個檢核點。各個檢核點之檢測結果分為三種,分別為符合、不符合、未適用等三種情況。受測行動化應用軟體,若檢測結果為符合則表示滿足此項檢測點之要求;若檢測結果為不符合則表示未滿足此項檢測點之要求,應需依提供之建議進行調整;若檢測過程中未發現該項檢核點之要求則表示未適用,在最後結果計算時則會排除該檢核點。
通過原則為「檢測條件」為「必要」者需全數符合,另「選項」者則需符合其中適用一半以上。為使瞭解13張檢測單的期望值及測試程序,以下簡要說明,並列出其表單格式包含檢測條件、規則識別碼/名稱、規則說明與檢測結果。
一、呈現組件
(一)AT替代文字與圖片
1.期望
- 每個有意義的圖片、元件或物件等,都有替代文字,且能正確描述其意義
- 每個替代文字不需包含描述網頁元素的類型,如影片、圖片、鏈結等。
2.檢測程序
(1)啟動螢幕報讀軟體。
(2)識別任何有意義的圖片,元件或物件。
(3)驗證具有相等意義的文字說明替代,簡要描述功能的意圖。
(4)確認避免僅使用如“圖片”、“鏈結”之類的詞。
3.檢測單
|
檢測條件
|
規則識別碼/名稱
|
規則說明
|
檢測結果
|
|
符合
|
不符合
|
未適用
|
|
必要
|
AT1非文字內容的替代品
|
替代文字必須簡要描述圖片,物件或元件的編輯意圖或目的。
|
□
|
□
|
□
|
|
必要
|
AT2裝飾性內容
|
裝飾性圖片必須從輔助技術中隱藏。
|
□
|
□
|
□
|
|
必要
|
AT3驗證碼或身份認證
|
驗證碼或身份認證應該依據行動裝置特性提供另一種驗證方式
|
□
|
□
|
□
|
|
必要
|
AT4視覺格式
|
不得單獨使用視覺格式來傳達含義
|
□
|
□
|
□
|
|
選項
|
AT5系列圖片
|
在一組緊連圖片中的第一個項目使用替代文字,描述該組圖片的所有項目資訊。
|
□
|
□
|
□
|
|
選項
|
AT6文字圖片
|
除了標誌圖標(logo),圖示(icon)或使用畫布(canvas)的互動式內容,應避免文字圖片
|
□
|
□
|
□
|
|
選項
|
AT7背景圖片
|
傳達訊息或特別含義的背景圖片應該有其他無障礙的替代方式。
|
□
|
□
|
□
|
(二)AV時序媒體
1.期望
- 時序媒體提供任何音訊內容的重要訊息同步字幕(開放或關閉的字幕)
- 音訊內容不會自動播放
2.檢測程序
(1)啟動應用程式。
(2)識別時序媒體。
(3)確定時序媒體是否具有包含重要訊息的音訊內容,例如口頭敘述。
(4)檢查是否透過字幕/打開/隱藏式字幕,同時提供與音訊同步的理解媒體所需的所有可聽訊息。
(5)確定時序媒體是否具有包含重要訊息的視覺內容-例如重要標示或加入新文字。
(6)檢查是否將理解時序媒體所需的任何視覺訊息之描述,作為音訊的一部分,或者是否提供音訊描述的單獨音軌,並與視訊同步。在適當的情況下,可以透過螢幕報讀軟體使用。
3.檢測單
|
檢測條件
|
規則識別碼/名稱
|
規則說明
|
檢測結果
|
|
符合
|
不符合
|
未適用
|
|
必要
|
AV1視聽內容的替代品
|
時序媒體的替代內容(如字幕,手語,音訊描述)必須在可用的情況下隨嵌入式媒體一起提供。
|
□
|
□
|
□
|
|
必要
|
AV2不得自動播放音訊
|
除非使用者知道會產生音訊或事先知道該音訊可提供暫停/停止/靜音的按鈕,否則音訊不得自動播放。
|
□
|
□
|
□
|
|
選項
|
AV3提供詮釋資料
|
應該為所有媒體提供相關的詮釋資料。
|
□
|
□
|
□
|
|
選項
|
AV4音量控制
|
應該為背景音樂、環境聲音、敘述性和編輯上重要的音效提供單獨的音量控制。
|
□
|
□
|
□
|
|
選項
|
AV5不得音訊衝突
|
遊戲或互動式媒體中的敘事音訊不應蓋過或與原生輔助技術衝突。
|
□
|
□
|
□
|
(三)NT通知
1.期望
2.檢測程序
(1)啟動應用程式。
(2)在應用程式中的物件,元件或控件上觸發警告或錯誤。
(3)驗證警告或錯誤指示是否存在可見和可聽的提示。
(4)驗證警告或錯誤通知是否清楚指示需要更正的操作。
(5)啟動螢幕報讀軟體。
(6)重複步驟2-3。
3.檢測單
|
檢測條件
|
規則識別碼/名稱
|
規則說明
|
檢測結果
|
|
符合
|
不符合
|
未適用
|
|
必要
|
NT1包容性通知
|
通知訊息必須同時可見和可聽。
|
□
|
□
|
□
|
|
必要
|
NT2錯誤訊息和更正
|
必須提供明確的錯誤訊息。
|
□
|
□
|
□
|
|
選項
|
NT3標準作業系統通知
|
在可用且適當的地方,應使用標準作業系統通知。
|
□
|
□
|
□
|
|
選項
|
NT4反饋和幫助
|
適當時應提供非關鍵性的反饋或幫助。
|
□
|
□
|
□
|
二、互動組件
(一)TS觸控操作
1.期望
- 所有多點觸控或路徑觸控有替代的單點觸控
- 觸控目標可以順利以手指觸發動作/事件且不易誤觸
2.檢測程序
(1)使用觸控螢幕瀏覽該應用程式。
(2)識別提供多點觸控或路徑觸控操作的物件、元件和控件。
(3)驗證具有複雜功能的項目是否提供有替代的單點觸控,例如使用箭頭鍵代替上下滑動手勢來移動滑塊。
3.檢測單
|
檢測條件
|
規則識別碼/名稱
|
規則說明
|
檢測結果
|
|
符合
|
不符合
|
未適用
|
|
必要
|
TS1單點觸控
|
確認多點觸控或路徑觸控需有替代的單點觸控。
|
□
|
□
|
□
|
|
必要
|
TS2觸發操作
|
觸發操作以向上事件為主,需有防止誤觸設計。
|
□
|
□
|
□
|
|
必要
|
TS3觸控目標尺寸
|
觸控目標尺寸至少 48dp*48dp(9mm*9mm)
|
□
|
□
|
□
|
|
選項
|
TS4並行輸入機制
|
容許並行輸入機制的方式,如外接鍵盤或手寫筆等。
|
□
|
□
|
□
|
(二)FC焦點
1.期望
- 每個可操作的元件都可以通過觸摸的方式,以視圖的焦點順序顯示
- 目標元件或控件可以使用標準導航方法進行瀏覽或離開
- 焦點順序等同於頁面直觀的視覺閱讀順序
2.檢測程序
Android系統:
(1)開啟TalkBack。
(2)確認每個可操作元素都可以直接導航(透過觸控Android 4+)。
(3)確認可以使用鍵盤或d-pad導航到每個可操作的元素。
iOS:
(1)開啟VoiceOver。
(2)驗證每個可操作物件都可以直接訪問(透過觸摸),並以視圖的焦點順序顯示。
(3)驗證每個可操作的物件皆可使用螢幕報讀軟體透過導航(滑動手勢)獲得焦點。
3.檢測單
|
檢測條件
|
規則識別碼/名稱
|
規則說明
|
檢測結果
|
|
符合
|
不符合
|
未適用
|
|
必要
|
FC1可聚焦元件
|
所有互動元件必須是可聚焦的,非互動元件必須不能聚焦。
|
□
|
□
|
□
|
|
必要
|
FC2鍵盤陷阱
|
不得有鍵盤陷阱。
|
□
|
□
|
□
|
|
必要
|
FC3焦點順序
|
必須以有意義的順序瀏覽可操作的內容。
|
□
|
□
|
□
|
(三)FM表單
1.期望
- 螢幕報讀軟體會報讀所有表單欄位標籤及輸入類型
- 對於每組項目之間的導航和互動必須按順序進行
- 輸入表單欄位或選擇物件、元件和控件中的項目時,焦點不會移開
2.檢測程序
(1)啟動螢幕報讀軟體。
(2)瀏覽頁面上的表單欄位。
(3)確認導航到表單欄位時螢幕報讀軟體可以識別表單欄標籤。
(4)根據表單欄位填寫內容時,不會強行移動焦點位置。
3.檢測單
|
檢測條件
|
規則識別碼/名稱
|
規則說明
|
檢測結果
|
|
符合
|
不符合
|
未適用
|
|
必要
|
FM1標記表單控件
|
必須標記所有表單控件。
|
□
|
□
|
□
|
|
必要
|
FM2表單輸入
|
必須指明並支援預設輸入格式。
|
□
|
□
|
□
|
|
必要
|
FM3分組表單元件
|
控件、標籤和其他表單元件必須正確配對。
|
□
|
□
|
□
|
|
必要
|
FM4管理焦點
|
在使用者輸入過程中,焦點或上下文不得自動更改。
|
□
|
□
|
□
|
|
選項
|
FM5表單佈局
|
標籤必須放置在靠近相關表單控件的位置,並適當佈置。
|
□
|
□
|
□
|
|
選項
|
FM6輸入提示
|
在需要時,應提供輸入提示並可提供視覺和聽覺表現。
|
□
|
□
|
□
|
(四)LK鏈結
1.期望
- 通過文字充分描述鏈結,按鈕或導航項,清楚地表明其目的
- 螢幕報讀軟體只會報讀一次,同時帶有圖片和文字標籤的物件,元件和控件
2.檢測程序
(1)啟動螢幕報讀軟體。
(2)找到鏈結、按鈕或導航項目。
(3)確定鏈結或項目本身是否足以唯一地描述組件並清楚地指出其目的。
3.檢測單
|
檢測條件
|
規則識別碼/名稱
|
規則說明
|
檢測結果
|
|
符合
|
不符合
|
未適用
|
|
必要
|
LK1描述式鏈結
|
鏈結和導航文字必須唯一地描述鏈結或項目的目標或功能。
|
□
|
□
|
□
|
|
必要
|
LK2合併重複的鏈結
|
必須將到同一組件的重複鏈結合併成單個鏈結。
|
□
|
□
|
□
|
|
選項
|
LK3鏈結目的格式
|
告知使用者將要使用不同行動化應用軟體開啟
|
□
|
□
|
□
|
(五)DC動態內容
1.期望
- 避免動態內容的閃爍造成癲癇、痙攣等身體不適的反應
- 當螢幕包含動態更新,移動,閃爍的滾動內容或動畫時,可以使用方法來停止,隱藏,暫停或控制內容
- 螢幕內容不會自動重整或改變,或者焦點在物件、元件或控件之間移動時不會自動重整或改變
2.檢測程序
(1)瀏覽內容,驗證螢幕不會自動重整或改變。
(2)確認頁面/螢幕上內容閃爍的位置。
(3)使用閃爍測試儀(Flicker Tester)將相機靠近光源。
(4)儲存閃爍曲線指數、頻率與閃爍百分比。
(5)驗證是否符合閃爍要求或提供警告與開關按鈕。
3.檢測單
|
檢測條件
|
規則識別碼/名稱
|
規則說明
|
檢測結果
|
|
符合
|
不符合
|
未適用
|
|
必要
|
DC1禁止閃爍
|
動態內容不得明顯或有意地在任何一秒鐘中閃爍三遍。
|
□
|
□
|
□
|
|
必要
|
DC2動態內容控制
|
更新媒體或動畫內容必須具有暫停,停止或隱藏控件。
|
□
|
□
|
□
|
|
必要
|
DC3懸浮內容
|
指標懸停時觸發的附加內容可由使用者移除或移動,指標可以在附加內容上移動,而且原內容不會消失。
|
□
|
□
|
□
|
|
必要
|
DC4頁面更新
|
不得在沒有警告的情況下使用自動頁面重整。
|
□
|
□
|
□
|
|
必要
|
DC5超時
|
時間限制的回應必須可調整。
|
□
|
□
|
□
|
(六)ST結構
1.期望
- 每個頁面/螢幕必須具有唯一的上下文相關標題
- 所有複合物件、元件和控件需有整體描述的聲明,如滑塊控件應顯示為滑塊,而不是向上按鈕、向下按鈕和指示器
2.檢測程序
(1)檢查網站/應用程式上每個頁面/螢幕的標題。
(2)驗證標題是否存在:
- 對於HTML,必須由螢幕報讀軟體報讀一個獨特的title元素。
- 對於Android和iOS,標題必須出現在螢幕頂部,並由螢幕報讀軟體報讀。
3.檢測單
|
檢測條件
|
規則識別碼/名稱
|
規則說明
|
檢測結果
|
|
符合
|
不符合
|
未適用
|
|
必要
|
ST1單一頁面標題
|
所有頁面或螢幕標題必須唯一且清晰可辨。
|
□
|
□
|
□
|
|
必要
|
ST2分組元件
|
可控元件,以分組進行呈現時,訪問須表示為同一整體結構,非單一控件。
|
□
|
□
|
□
|
|
選項
|
ST3標頭
|
內容必須提供平台支援的邏輯和分層標頭結構。
|
□
|
□
|
□
|
|
選項
|
ST4容器與地標
|
容器應用於描述平台支援的頁面/螢幕結構。
|
□
|
□
|
□
|
三、設計方式
(一)AD可調適設計
1.期望
- 內容以有意義的順序宣告
- 當行動裝置變更螢幕方向時,可以立即調適內容呈現方向
2.檢測程序
(1)啟動螢幕報讀軟體。
(2)使用標準命令導航下一個和上一個。
(3)驗證內容按照有意義的順序報讀。
3.檢測單
|
檢測條件
|
規則識別碼/名稱
|
規則說明
|
檢測結果
|
|
符合
|
不符合
|
未適用
|
|
必要
|
AD1內容順序
|
內容順序必須符合邏輯順序。
|
□
|
□
|
□
|
|
必要
|
AD2螢幕方向
|
確認內容可以響應設備變更螢幕方向。
|
□
|
□
|
□
|
|
選項
|
AD3可調整設定
|
互動式媒體(包括遊戲)應根據使用者的能力和偏好進行可調。
|
□
|
□
|
□
|
(二)DT可辨識設計
1.期望
- 可以從視覺上區分可操作項目和不可操作項目
- 對於非粗體的標準字體,文字母和背景之間的對比度滿足WCAG 2.0要求的最小彩色對比度為4.5:1
- 更改畫面比例後,不會遺失資訊
- 調整大小後,內容可以正確重排
2.檢測程序
(1)啟動螢幕報讀軟體。
(2)找出所有可操作的項目。
(3)驗證可以從視覺上區分可操作項目和不可操作項目。
(4)驗證螢幕報讀軟體可指出可操作狀態。
3.檢測單
|
檢測條件
|
規則識別碼/名稱
|
規則說明
|
檢測結果
|
|
符合
|
不符合
|
未適用
|
|
必要
|
DT1可操作元件
|
鏈結和其他可操作元素必須清楚區分。
|
□
|
□
|
□
|
|
必要
|
DT2文字對比
|
小文字(小於 18 點標準/14 點粗體)需符合 4.5:1 ;大文字(大於 18 點標準/14 點粗體)需符合 3.0:1
|
□
|
□
|
□
|
|
必要
|
DT3調整文字尺寸
|
確認文字可以放大到200%而不會失去內容或功能性。
|
□
|
□
|
□
|
|
選項
|
DT5非文字對比
|
使用者介面元件和圖形物件內容的視覺呈現與相鄰顏色的對比度至少為3:1。
|
□
|
□
|
□
|
|
選項
|
DT6流動排版
|
確保內容響應設備螢幕大小自動調整,並避免二維捲軸。
|
□
|
□
|
□
|
(三)PD可預期性設計
1.期望
- 所有內容、文字、文本圖片、音訊、視訊字幕和替代項均按照系統中設定的預期語言發布或顯示
- 元件,控件和物件的視覺佈局與樣式可指示其操作動作
- 執行相同的功能元件,控件和物件的視覺圖示及文字,具有一致性的說明及呈現
2.檢測程序
(1)設置作業系統語言。
(2)以作業系統標準輔助技術啟用的情況下啟動應用程式。
(3)驗證以下內容是否以正確的語言顯示或報讀:
- 文字
- 網站/應用程式不同語言的文字
- 文字圖片
- 網站/應用程式不同語言的文字圖片
- 標籤
- 提示
- 聲音
- 影片字幕
- 頁面和螢幕標題
- 網站/應用程式不同語言的圖片、物件和元件的替代內容
3.檢測單
|
檢測條件
|
規則識別碼/名稱
|
規則說明
|
檢測結果
|
|
符合
|
不符合
|
未適用
|
|
必要
|
PD1指示語言
|
指定頁面或應用程式的語言,並且必須指示語言的更改。
|
□
|
□
|
□
|
|
必要
|
PD2一致的導覽
|
除非使用者做出變更,否則在一組元件中,反覆出現的導覽機制每次都要有相同的相對順序。
|
□
|
□
|
□
|
|
必要
|
PD3一致的識別
|
具有相同功能性的元件,就要有一致的識別。
|
□
|
□
|
□
|
|
選項
|
PD4依請求變更
|
只有當使用者提出請求時,才開始變更上下文,否則就要有個機制來關掉這類變更。
|
□
|
□
|
□
|
(四)CP相容性設計
1.期望
- 保使用者在離線或支援不完整時仍有功能體驗
- 可以順利切換到電話、簡訊、電子郵件正常操作,並可回到應用程式
2.檢測程序
(1)識別可能依賴於JavaScript的內容和功能。
(2)在未支援JavaScript或停用JavaScript的裝置或行動瀏覽器、或輔助技術,執行應用程式或網站。
(3)驗證內容是否可用,或提供有關為何不可用的訊息。
(4)驗證功能是否可用。
3.檢測單
|
檢測條件
|
規則識別碼/名稱
|
規則說明
|
檢測結果
|
|
符合
|
不符合
|
未適用
|
|
選項
|
CP1漸進式功能
|
以漸進式方式構建應用程式和網站,以確保使用者在離線或支援不完整時仍有功能體驗。
|
□
|
□
|
□
|
|
選項
|
CP2功能切換
|
和行動裝置原有的電話、簡訊、電子郵件等功能可相容切換。
|
□
|
□
|
□
|
一、國內規範文件
(一)「網站無障礙規範2.0版」,國家通訊傳播委員會,民國一百零六年二月十五日。
(二)「行動版應用程式(APP)無障礙開發指引」,國家通訊傳播委員會,民國一百零六年十一月。
(三)「網站無障礙規範」,國家通訊傳播委員會,民國一百十年三月。
二、 國外規範文件
(一)Accessibility Conformance Testing (ACT) Rules Format 1.0, Editors:Wilco Fiers (Deque Systems),Maureen Kraft (IBM Corp.),Shadi Abou-Zahra (W3C),W3C Recommendation, 31 October 2019,(https://www.w3.org/TR/act-rules-format/)。
(二)Mobile Accessibility Guidelines, Editors:Emma Pratt Richens(BBC),Gareth Ford Williams(BBC),Jamie Knight(BBC),Michael Mathews(BBC),Rebecca Nancarrow(BBC),(https://www.bbc.co.uk/accessibility/forproducts/guides/mobile/)。
(三)Techniques for WCAG 2.1, Editors: Alastair Campbell, Michael Cooper, Andrew Kirkpatrick, Updated 10 July 2020,(https://www.w3.org/WAI/WCAG21/Techniques/)
(四)Web Content Accessibility Guidelines (WCAG) 2.1, Editors:Andrew Kirkpatrick (Adobe),Joshue O Connor (Invited Expert, InterAccess),Alastair Campbell (Nomensa),Michael Cooper (W3C),W3C Recommendation 05 June 2018,(https://www.w3.org/TR/WCAG21/)。