如何檢查無障礙設計

判斷網站或應用程式是否符合無障礙標準,可能會讓您感到不知所措。如果您是第一次接觸無障礙設計,可能會因為主題範圍廣泛,而不知道該從何處著手。畢竟,為了滿足不同能力需求,我們必須考慮各種問題。

本文將這些問題分解為邏輯的逐步程序,協助您檢查現有網站的無障礙功能。

從鍵盤開始

對於無法或選擇不使用滑鼠的使用者,鍵盤瀏覽是瀏覽畫面上所有內容的主要方式。這類目標對象包括行動不便的使用者 (例如因重複性勞損 (RSI) 或癱瘓而行動不便),以及螢幕閱讀器使用者。

為提供良好的鍵盤體驗,請盡量採用合理的分頁順序,並使用清晰可辨識的焦點樣式。

  • 首先請使用 Tab 鍵瀏覽網站。元素的聚焦順序應遵循 DOM 順序。如果不確定哪些元素應接收焦點,請參閱 Learn Accessibility 課程中有關焦點的單元。最佳做法是,任何使用者可互動或提供輸入內容的控制項,都應可聚焦並顯示聚焦指標 (例如聚焦環)。

  • 自訂互動式控制項應可聚焦。如果您使用 JavaScript 將 <div> 轉換為精美的下拉式選單,系統不會自動將其插入分頁順序中。如要讓自訂控制項可聚焦,請為其提供 tabindex="0"tabindex 值大於 0 會變更分頁順序,可能會讓螢幕閱讀器使用者感到困惑。

  • 請只讓互動式內容可聚焦。將 tabindex 新增至標題等非互動元素,會讓可看到螢幕的鍵盤使用者操作速度變慢,對螢幕閱讀器使用者也沒有幫助,因為螢幕閱讀器已知曉要讀出這些元素。

  • 如果您在頁面中新增內容,請先將使用者的焦點導向該內容,方便他們採取行動。如需範例,請參閱「在網頁層級管理焦點」。

  • 設計網站時,請讓使用者隨時可以將焦點移至下一個元素。請留意自動完成小工具和其他可能會鎖定鍵盤焦點的內容。當您希望使用者與模式互動,而非與網頁的其他部分互動時,可以暫時鎖定焦點,但您應一律提供可透過鍵盤存取的模式退出方式。如需範例,請參閱「模式和鍵盤陷阱」。

讓焦點控制可供使用

如果您已建構自訂控制項,請讓使用者只需使用鍵盤即可存取所有功能。如要瞭解如何改善鍵盤存取功能,請參閱「在元件中管理焦點」一文。

管理畫面外內容

許多網站都包含畫面外內容 (存在於 DOM 但沒有在畫面上顯示),例如回應式導覽匣選單中的連結,或互動視窗內尚未顯示的按鈕。在 DOM 中保留這些元素可能導致鍵盤操作體驗不佳,特別是在螢幕閱讀器將這類元素視為頁面中的內容,並照常朗讀出來,使用者卻無法透過鍵盤存取這些內容時。

請參閱「處理畫面外的內容」,瞭解如何處理這些元素。

使用螢幕閱讀器進行測試

改善一般鍵盤支援功能後,您就可以進行下一個步驟,也就是檢查網頁是否有適當的標籤和語義,以及是否有任何會妨礙螢幕閱讀器導覽的障礙。

如果您不熟悉輔助技術如何解讀語意標記,請參閱「內容結構」一文。

  • 檢查所有圖片是否有正確的 alt 文字。這項做法例外狀況是,圖片主要用於呈現目的,而非必要的內容。如要表示螢幕閱讀器應略過圖片,請將值設為空字串:alt=""
  • 檢查標籤的所有控制項。如為自訂控制項,可能需要使用 aria-labelaria-labelledby。如需相關範例,請參閱「ARIA 標籤和關係」。
  • 請檢查所有自訂控制項,確認是否有適當的 role,以及任何用於傳達狀態的必要 ARIA 屬性。舉例來說,自訂核取方塊需要 role="checkbox"aria-checked="true|false",才能正確傳達其狀態。如要瞭解 ARIA 如何為自訂控制項提供缺少的語義,請參閱「ARIA 簡介」一文。
  • 讓網頁中的資訊流程更合理。由於螢幕閱讀器會依 DOM 順序瀏覽網頁,因此會以不合理的順序,宣讀您使用 CSS 視覺上重新定位的任何元素。如果您需要在頁面中較前方顯示某些內容,請實際將其移至 DOM 中較前方的位置。
  • 請盡量支援螢幕閱讀器瀏覽頁面上所有內容的功能。請確認網站的任何部分都不會永久隱藏或禁止螢幕閱讀器存取。
    • 如果內容「應」隱藏在螢幕閱讀器中 (例如內容位於畫面外或僅供呈現),請將該內容設為 aria-hidden="true"。如需更詳細的說明,請參閱「隱藏內容」。

熟悉螢幕閱讀器

學習操作螢幕閱讀器聽起來好像很難,但其實很容易上手。大部分開發人員只要學會幾個簡單的鍵盤指令,通常就足以因應基本需求。

如果您使用 Mac,請觀看這部關於 VoiceOver 的影片,瞭解如何操作 macOS 內建的螢幕閱讀器。如果您使用的是 PC,請觀看這部關於 NVDA 的影片。NVDA 是一款捐款贊助開發的開放原始碼螢幕閱讀器,適用於 Windows。

aria-hidden 不會阻止鍵盤焦點

請務必瞭解,ARIA 只能影響元素的語意,對元素的行為沒有任何影響。您可以使用 aria-hidden="true" 將元素隱藏起來,以便螢幕閱讀器使用,但這不會變更該元素的焦點行為。如要處理螢幕外的互動內容,請使用 inert 屬性,確保內容確實已從鍵盤流程中移除。針對舊版瀏覽器,請將 aria-hidden="true"tabindex="-1" 合併。

互動元素應指出其用途和狀態

提供關於控制項功能的視覺提示或操作元素,有助於各種裝置的使用者操作及瀏覽網站。

  • 連結和按鈕等互動元素應與非互動元素有所區別。如果使用者無法判斷元素是否可點選,就很難瀏覽網站或應用程式。指示互動元素的方法有很多種,常見做法之一是為連結加上底線,以便與周圍文字區分開。
  • 與焦點要求類似,連結和按鈕等互動元素需要 hover 狀態,才能在滑鼠游標懸停在可點選項目上時,告知滑鼠使用者。不過,為了讓其他輸入法能夠存取這些元素,這些元素必須在沒有 hover 狀態的情況下可辨識。

善用標頭和地標

標題和地標元素可為網頁提供語意結構,大幅提升輔助技術使用者的瀏覽效率。許多螢幕閱讀器使用者回報,當他們首次造訪不熟悉的網頁時,通常會嘗試依標題導覽

同樣地,螢幕閱讀器也能跳轉至 <main><nav> 等重要位置標記。因此,請務必考量如何運用網頁結構引導使用者體驗。

  • 使用 h1-h6 階層。您可以將標題視為建立網頁大綱的工具,請勿依賴標題內建的樣式。請改為將這些內容視為同樣大小,並為主要、次要和次要內容使用語義上適當的層級。然後使用 CSS 讓標題符合您的設計。
  • 使用里程碑元素和角色,讓使用者能略過重複的內容。許多輔助技術都提供捷徑,可跳至網頁的特定部分,例如由 <main><nav> 元素定義的部分。這些元素具有隱含的地標角色。您也可以使用 ARIA role 屬性,明確定義網頁上的區域,如 <div role="search"> 所示。如需更多範例,請參閱「語意和導覽內容」。
  • 除非您有使用 role="application" 的經驗,否則請避免使用 role="application"application 地標角色會告知輔助技術停用其捷徑,並將所有按鍵操作傳遞至網頁。也就是說,螢幕閱讀器使用者通常用於在頁面中移動的按鍵不再運作,您必須自行實作「所有」鍵盤處理作業。

透過螢幕閱讀器查看標題和地標

VoiceOver 和 NVDA 等螢幕閱讀器會提供內容選單,可跳至網頁上的重要區域。測試無障礙功能時,您可以使用這些選單查看網頁概覽,並判斷標題層級是否適當,以及哪些地標正在使用。

如需更多資訊,請參閱以下說明影片,瞭解 VoiceOverNVDA 的基本概念。

自動化程序

手動測試網站無障礙功能可能會很耗時,且容易出錯。盡可能自動化測試會帶來許多好處。您可以使用瀏覽器擴充功能和指令列無障礙測試套件。

  • 網頁是否通過 aXeWAVE 瀏覽器擴充功能的所有測試?雖然還有其他選項,但這些擴充功能可用於任何手動測試程序,因為它們可以找出細微的問題,例如對比率不符和缺少 ARIA 屬性。
    • 如果您偏好使用指令列,axe-cli 提供與 aXe 瀏覽器擴充功能相同的功能,但可透過終端機執行。
  • 為避免迴歸問題 (特別是在持續整合環境中),請將 axe-core 等程式庫納入自動化測試套件。axe-core 是 aXe Chrome 擴充功能的運作引擎,但以指令列公用程式的方式運作。
  • 如果您使用的是架構或程式庫,那麼該架構或程式庫是否提供專屬的無障礙工具?例如 Angular 的 protractor-accessibility-plugin。盡可能充分發揮可用工具的優勢。

使用 Lighthouse 測試 PWA

Lighthouse 是一項評估漸進式網頁應用程式 (PWA) 效能的工具。並使用 axe-core 程式庫執行無障礙功能測試。

如果您已使用 Lighthouse,請在報告中找出失敗的無障礙性測試。修正錯誤,改善網站的整體使用者體驗。

其他資源