Try   HackMD

行動化應用軟體無障礙檢測項目清單(非官方)

編按:

  • 以下內容重新編排自數位發展部無障礙空間服務網〈App檢測指引〉中的「檢測單」頁面。藉由手動編寫與 AI (Claude) 協作,將表格變更為列表,以便螢幕報讀器與點字顯示器使用者閱讀。所作的變更,皆以 CC0 授權條款發布。歡迎更新內容、共同編寫完善!

  • 本文件當中,除了「編按」開頭的訊息框外的內容皆儘可能重複使用前述網站的文字內容,並儘可能切合原意。然而作者們並不保證這份文件內容與來源網站內容完全符合或完全正確。對於本文件的使用也不承擔任何責任。

行動化應用軟體無障礙檢測指引共分為13檢測單,55個檢核點。各個檢核點之檢測結果分為三種,分別為符合、不符合、未適用等三種情況。受測行動化應用軟體,若檢測結果為符合則表示滿足此項檢測點之要求;若檢測結果為不符合則表示未滿足此項檢測點之要求,應需依提供之建議進行調整;若檢測過程中未發現該項檢核點之要求則表示未適用,在最後結果計算時則會排除該檢核點

通過原則為「檢測條件」為「必要」者需全數符合,另「選項」者則需符合其中適用一半以上。為使瞭解13張檢測單的期望值及測試程序,以下簡要說明,並列出其表單格式包含檢測條件、規則識別碼/名稱、規則說明與檢測結果。

編按:

呈現組件

AT替代文字與圖片

  • 期望

    • 每個有意義的圖片、元件或物件等,都有替代文字,且能正確描述其意義
    • 每個替代文字不需包含描述網頁元素的類型,如影片、圖片、鏈結等。
  • 檢測程序

    1. 啟動螢幕報讀軟體。
    2. 識別任何有意義的圖片,元件或物件。
    3. 驗證具有相等意義的文字說明替代,簡要描述功能的意圖。
    4. 確認避免僅使用如「圖片」、「鏈結」之類的詞。
  • 檢測規則

    • AT1非文字內容的替代品(必要):替代文字必須簡要描述圖片,物件或元件的編輯意圖或目的。
    • AT2裝飾性內容(必要):裝飾性圖片必須從輔助技術中隱藏。
    • AT3驗證碼或身份認證(必要):驗證碼或身份認證應該依據行動裝置特性提供另一種驗證方式。
    • AT4視覺格式(必要):不得單獨使用視覺格式來傳達含義。
    • AT5系列圖片(選項):在一組緊連圖片中的第一個項目使用替代文字,描述該組圖片的所有項目資訊。
    • AT6文字圖片(選項):除了標誌圖標(logo),圖示(icon)或使用畫布(canvas)的互動式內容,應避免文字圖片。
    • AT7背景圖片(選項):傳達訊息或特別含義的背景圖片應該有其他無障礙的替代方式。

AV時序媒體

  • 期望

    • 時序媒體提供任何音訊內容的重要訊息同步字幕(開放或關閉的字幕)。
    • 音訊內容不會自動播放。
  • 檢測程序

    1. 啟動應用程式。
    2. 識別時序媒體。
    3. 確定時序媒體是否具有包含重要訊息的音訊內容,例如口頭敘述。
    4. 檢查是否透過字幕/打開/隱藏式字幕,同時提供與音訊同步的理解媒體所需的所有可聽訊息。
    5. 確定時序媒體是否具有包含重要訊息的視覺內容-例如重要標示或加入新文字。
    6. 檢查是否將理解時序媒體所需的任何視覺訊息之描述,作為音訊的一部分,或者是否提供音訊描述的單獨音軌,並與視訊同步。在適當的情況下,可以透過螢幕報讀軟體使用。
  • 檢測規則

    • AV1視聽內容的替代品(必要):時序媒體的替代內容(如字幕,手語,音訊描述)必須在可用的情況下隨嵌入式媒體一起提供。
    • AV2不得自動播放音訊(必要):除非使用者知道會產生音訊或事先知道該音訊可提供暫停/停止/靜音的按鈕,否則音訊不得自動播放。
    • AV3提供詮釋資料(選項):應該為所有媒體提供相關的詮釋資料。
    • AV4音量控制(選項):應該為背景音樂、環境聲音、敘述性和編輯上重要的音效提供單獨的音量控制。
    • AV5不得音訊衝突(選項):遊戲或互動式媒體中的敘事音訊不應蓋過或與原生輔助技術衝突。

互動組件

NT通知

  • 期望

    • 通知訊息必須同時可見和可聽。
    • 提供明確的錯誤訊息。
  • 檢測程序

    1. 啟動應用程式。
    2. 在應用程式中的物件,元件或控件上觸發警告或錯誤。
    3. 驗證警告或錯誤指示是否存在可見和可聽的提示。
    4. 驗證警告或錯誤通知是否清楚指示需要更正的操作。
    5. 啟動螢幕報讀軟體。
    6. 重複步驟2-3。
  • 檢測規則

    • NT1包容性通知(必要):通知訊息必須同時可見和可聽。
    • NT2錯誤訊息和更正(必要):必須提供明確的錯誤訊息。
    • NT3標準作業系統通知(選項):在可用且適當的地方,應使用標準作業系統通知。
    • NT4反饋和幫助(選項):適當時應提供非關鍵性的反饋或幫助。

TS觸控操作

  • 期望
    • 所有多點觸控或路徑觸控有替代的單點觸控。
    • 觸控目標可以順利以手指觸發動作/事件且不易誤觸。

* 檢測程序

  1. 使用觸控螢幕瀏覽該應用程式。
  2. 識別提供多點觸控或路徑觸控操作的物件、元件和控件。
  3. 驗證具有複雜功能的項目是否提供有替代的單點觸控,例如使用箭頭鍵代替上下滑動手勢來移動滑塊。
  • 檢測規則
    • TS1單點觸控(必要):確認多點觸控或路徑觸控需有替代的單點觸控。
    • TS2觸發操作(必要):觸發操作以向上事件為主,需有防止誤觸設計。
    • TS3觸控目標尺寸(必要):觸控目標尺寸至少 48dp*48dp(9mm*9mm)
    • TS4並行輸入機制(選項):容許並行輸入機制的方式,如外接鍵盤或手寫筆等。

FC焦點

  • 期望

    • 每個可操作的元件都可以通過觸摸的方式,以視圖的焦點順序顯示。
    • 目標元件或控件可以使用標準導航方法進行瀏覽或離開。
  • 檢測程序(Android系統)

    1. 開啟TalkBack。
    2. 確認每個可操作元素都可以直接導航(透過觸控Android 4+)。
    3. 確認可以使用鍵盤或d-pad導航到每個可操作的元素。
  • 檢測規則

    • FC1可聚焦元件(必要):所有互動元件必須是可聚焦的,非互動元件必須不能聚焦。
    • FC2鍵盤陷阱(必要):不得有鍵盤陷阱。
    • FC3焦點順序(必要):必須以有意義的順序瀏覽可操作的內容。

FM表單

  • 期望

    • 螢幕報讀軟體會報讀所有表單欄位標籤及輸入類型。
    • 對於每組項目之間的導航和互動必須按順序進行。
    • 輸入表單欄位或選擇物件、元件和控件中的項目時,焦點不會移開。
  • 檢測程序

    1. 啟動螢幕報讀軟體。
    2. 瀏覽頁面上的表單欄位。
    3. 確認導航到表單欄位時螢幕報讀軟體可以識別表單欄標籤。
    4. 根據表單欄位填寫內容時,不會強行移動焦點位置。
  • 檢測規則

    • FM1標記表單控件(必要):必須標記所有表單控件。
    • FM2表單輸入(必要):必須指明並支援預設輸入格式。
    • FM3分組表單元件(必要):控件、標籤和其他表單元件必須正確配對。
    • FM4管理焦點(必要):在使用者輸入過程中,焦點或上下文不得自動更改。
    • FM5表單佈局(選項):標籤必須放置在靠近相關表單控件的位置,並適當佈置。
    • FM6輸入提示(選項):在需要時,應提供輸入提示並可提供視覺和聽覺表現。

LK鏈結

  • 期望

    • 通過文字充分描述鏈結,按鈕或導航項,清楚地表明其目的。
    • 螢幕報讀軟體只會報讀一次,同時帶有圖片和文字標籤的物件,元件和控件。
  • 檢測程序

    1. 啟動螢幕報讀軟體。
    2. 找到鏈結、按鈕或導航項目。
    3. 確定鏈結或項目本身是否足以唯一地描述組件並清楚地指出其目的。
  • 檢測規則

    • LK1描述式鏈結(必要):鏈結和導航文字必須唯一地描述鏈結或項目的目標或功能。
    • LK2合併重複的鏈結(必要):必須將到同一組件的重複鏈結合併成單個鏈結。
    • LK3鏈結目的格式(選項):告知使用者將要使用不同行動化應用軟體開啟

DC動態內容

  • 期望

    • 避免動態內容的閃爍造成癲癇、痙攣等身體不適的反應。
    • 當螢幕包含動態更新,移動,閃爍的滾動內容或動畫時,可以使用方法來停止,隱藏,暫停或控制內容。
    • 螢幕內容不會自動重整或改變,或者焦點在物件、元件或控件之間移動時不會自動重整或改變。
  • 檢測程序

    1. 瀏覽內容,驗證螢幕不會自動重整或改變。
    2. 確認頁面/螢幕上內容閃爍的位置。
    3. 使用閃爍測試儀(Flicker Tester)將相機靠近光源。
    4. 儲存閃爍曲線指數、頻率與閃爍百分比。
    5. 驗證是否符合閃爍要求或提供警告與開關按鈕。
  • 檢測規則

    • DC1禁止閃爍(必要):動態內容不得明顯或有意地在任何一秒鐘中閃爍三遍。
    • DC2動態內容控制(必要):更新媒體或動畫內容必須具有暫停,停止或隱藏控件。
    • DC3懸浮內容(必要):指標懸停時觸發的附加內容可由使用者移除或移動,指標可以在附加內容上移動,而且原內容不會消失。
    • DC4頁面更新(必要):不得在沒有警告的情況下使用自動頁面重整。
    • DC5超時(必要):時間限制的回應必須可調整。

ST結構

  • 期望

    • 每個頁面/螢幕必須具有唯一的上下文相關標題。
    • 所有複合物件、元件和控件需有整體描述的聲明,如滑塊控件應顯示為滑塊,而不是向上按鈕、向下按鈕和指示器。
  • 檢測程序

    1. 檢查網站/應用程式上每個頁面/螢幕的標題。
    2. 驗證標題是否存在:
      • 對於HTML,必須由螢幕報讀軟體報讀一個獨特的title元素。
      • 對於Android和iOS,標題必須出現在螢幕頂部,並由螢幕報讀軟體報讀。
  • 檢測規則

    • ST1單一頁面標題(必要):所有頁面或螢幕標題必須唯一且清晰可辨。
    • ST2分組元件(必要):可控元件,以分組進行呈現時,訪問須表示為同一整體結構,非單一控件。
    • ST3標頭(選項):內容必須提供平台支援的邏輯和分層標頭結構。
    • ST4容器與地標(選項):容器應用於描述平台支援的頁面/螢幕結構。

設計方式

AD可調適設計

  • 期望

    • 內容以有意義的順序宣告。
    • 當行動裝置變更螢幕方向時,可以立即調適內容呈現方向。
  • 檢測程序

    1. 啟動螢幕報讀軟體。
    2. 使用標準命令導航下一個和上一個。
    3. 驗證內容按照有意義的順序報讀。
  • 檢測規則

    • AD1內容順序(必要):內容順序必須符合邏輯順序。
    • AD2螢幕方向(必要):確認內容可以響應設備變更螢幕方向。
    • AD3可調整設定(選項):互動式媒體(包括遊戲)應根據使用者的能力和偏好進行可調。

DT可辨識設計

  • 期望

    • 可以從視覺上區分可操作項目和不可操作項目。
    • 對於非粗體的標準字體,文字母和背景之間的對比度滿足WCAG 2.0要求的最小彩色對比度為4.5:1。
    • 更改畫面比例後,不會遺失資訊。
    • 調整大小後,內容可以正確重排。
  • 檢測程序

    1. 啟動螢幕報讀軟體。
    2. 找出所有可操作的項目。
    3. 驗證可以從視覺上區分可操作項目和不可操作項目。
    4. 驗證螢幕報讀軟體可指出可操作狀態。
  • 檢測規則

    • DT1可操作元件(必要):鏈結和其他可操作元素必須清楚區分。
    • DT2文字對比(必要):小文字(標準樣式小於 18 點/粗體小於 14 點)需符合 4.5:1 ;大文字(標準樣式大於 18 點/粗體大於 14 點)需符合 3.0:1。
    • DT3調整文字尺寸(必要):確認文字可以放大到200%而不會失去內容或功能性。
    • DT5非文字對比(選項):使用者介面元件和圖形物件內容的視覺呈現與相鄰顏色的對比度至少為3:1。
    • DT6流動排版(選項):確保內容響應設備螢幕大小自動調整,並避免二維捲軸。

PD可預期性設計

  • 期望

    • 所有內容、文字、文本圖片、音訊、視訊字幕和替代項均按照系統中設定的預期語言發布或顯示。
    • 元件,控件和物件的視覺佈局與樣式可指示其操作動作。
    • 執行相同的功能元件,控件和物件的視覺圖示及文字,具有一致性的說明及呈現。
  • 檢測程序

    1. 設置作業系統語言。
    2. 以作業系統標準輔助技術啟用的情況下啟動應用程式。
    3. 驗證以下內容是否以正確的語言顯示或報讀:
      • 文字
      • 網站/應用程式不同語言的文字
      • 文字圖片
      • 網站/應用程式不同語言的文字圖片
      • 標籤
      • 提示
      • 聲音
      • 影片字幕
      • 頁面和螢幕標題
      • 網站/應用程式不同語言的圖片、物件和元件的替代內容
  • 檢測規則

    • PD1指示語言(必要):指定頁面或應用程式的語言,並且必須指示語言的更改。
    • PD2一致的導覽(必要):除非使用者做出變更,否則在一組元件中,反覆出現的導覽機制每次都要有相同的相對順序。
    • PD3一致的識別(必要):具有相同功能性的元件,就要有一致的識別。
    • PD4依請求變更(選項):只有當使用者提出請求時,才開始變更上下文,否則就要有個機制來關掉這類變更。

CP相容性設計

  • 期望

    • 保使用者在離線或支援不完整時仍有功能體驗。
    • 可以順利切換到電話、簡訊、電子郵件正常操作,並可回到應用程式。
  • 檢測程序

    1. 識別可能依賴於JavaScript的內容和功能。
    2. 在未支援JavaScript或停用JavaScript的裝置或行動瀏覽器、或輔助技術,執行應用程式或網站。
    3. 驗證內容是否可用,或提供有關為何不可用的訊息。
    4. 驗證功能是否可用。
  • 檢測規則

    • CP1漸進式功能(選項):以漸進式方式構建應用程式和網站,以確保使用者在離線或支援不完整時仍有功能體驗。
    • CP2功能切換(選項):和行動裝置原有的電話、簡訊、電子郵件等功能可相容切換。