如何檢查無障礙設計

Rob Dodson

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

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

從鍵盤開始

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

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

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

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

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

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

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

讓焦點控制可供使用

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

管理畫面外內容

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

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

使用螢幕閱讀器進行測試

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

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

  • 檢查所有圖片是否有正確的 alt 文字。這項做法例外狀況是，圖片主要用於呈現目的，而非必要的內容。如要表示螢幕閱讀器應略過圖片，請將值設為空字串：alt=""。
  • 檢查標籤的所有控制項。如為自訂控制項，可能需要使用 aria-label 或 aria-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 等螢幕閱讀器會提供內容選單，可跳至網頁上的重要區域。測試無障礙功能時，您可以使用這些選單查看網頁概覽，並判斷標題層級是否適當，以及哪些地標正在使用。

如需更多資訊，請參閱以下說明影片，瞭解 VoiceOver 和 NVDA 的基本概念。

自動化程序

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

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

使用 Lighthouse 測試 PWA

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

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

其他資源