如何檢查無障礙設計

Rob Dodson

判斷使用者能否存取您的網站或應用程式，似乎 實在令人吃驚如果您是第一次接觸無障礙設計， 主題的廣度可能會讓您不知道該從何開始。畢竟， 並融入不同的能力，意味著 要考量的問題類型也不同

此文章將這些問題化為有邏輯的逐步操作流程 審查現有網站的無障礙功能

先使用鍵盤操作

如果使用者無法使用滑鼠或不想使用滑鼠 也就是將畫面上所有元素這組目標對象包括 動作障礙的使用者，例如重複性壓力傷害 (RSI) 或 以及螢幕閱讀器使用者

為了提供良好的鍵盤使用體驗，請以有邏輯的 Tab 鍵順序， 可明顯識別的焦點風格

  • 先透過分頁瀏覽您的網站。元素聚焦的順序 必須遵循 DOM 順序如果您不確定該將哪些元素 請參閱「學習無障礙程度」課程單元，瞭解焦點。最佳 都是使用者能與自身互動或輸入內容的控制項 應可聚焦，並顯示焦點指標 (例如對焦環)。

  • 自訂互動控制項應可聚焦。如果您使用 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、 。如果你使用 PC，請參閱這篇文章 NVDA 相關影片 捐款支持的開放原始碼螢幕閱讀器 (Windows 適用)。

aria-hidden 未禁止鍵盤焦點

請務必瞭解，ARIA 只會影響 語意 element;但不會影響元素的「行為」。您可以 螢幕閱讀器使用 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" 的經驗，否則請避免使用。 application 地標角色會指示輔助技術停用其 快速鍵，並按下所有按鍵來返回頁面。也就是說 螢幕閱讀器使用者通常用來在頁面進行瀏覽時無法運作 您必須自行實作所有鍵盤處理方式。

使用螢幕閱讀器查看標題和地標

VoiceOver 和 NVDA 等螢幕閱讀器會提供內容選單，方便您跳到 也就是網頁上的重要區域測試無障礙功能時 藉此概略瞭解頁面內容並判斷您要設定的標題是否 級別適當，並使用哪些地標。

如要進一步瞭解，請觀看這些教學影片 VoiceOver 和 NVDA。

將程序自動化

手動測試網站的無障礙程度並不容易，而且很容易出錯。 自動化測試也有利於 您可以使用瀏覽器擴充功能和指令列無障礙功能 測試套件

  • 網頁是否通過 aXe 或 WAVE 瀏覽器擴充功能？還有其他可行的選項 這類程式碼也能派上用場 包括失敗對比度和缺少 ARIA 等細微問題 屬性。
    • 如果偏好使用指令列 axe-cli 提供相同的功能 視為 aXe 瀏覽器擴充功能，但可以從終端機執行。
  • 為了避免發生迴歸問題 (尤其是在持續整合環境中)， 導入 axe-core 等程式庫 導入自動化測試套件axe-core 與 aXe Chrome 擴充功能，但位於指令列公用程式中
  • 如果您使用架構或程式庫，是否提供其自身的無障礙功能 這些工具呢？舉例來說， protractor-accessibility-plugin 。盡可能善用可用的工具。

使用 Lighthouse 測試 PWA

Lighthouse 這項工具 會評估漸進式網頁應用程式 (PWA) 的成效。 並使用 axe-core 程式庫來支援無障礙功能測試。

如果你已使用 Lighthouse，也請檢查是否有無障礙設計故障 測試。修正錯誤以改善 你的網站

其他資源