判斷網站或應用程式是否可供存取似乎是一項艱鉅的工作。如果您是第一次接觸無障礙設計，很可能會不知道該從何處著手，畢竟，如果能滿足多種不同功能的需求，代表要考量的問題也相當多元。
本文將這些問題，透過邏輯式的逐步流程，協助您審查現有網站是否確立無障礙功能。
從鍵盤開始
對於無法或選擇不使用滑鼠的使用者，鍵盤導覽是顯示畫面上所有內容的主要方式。這類目標對象包含動作失能的使用者，例如重複性壓力受傷 (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 順序瀏覽網頁，因此凡是您在視覺上放置的元素，都會以無意義的順序朗讀。如果您需要在網頁前面顯示某些內容，請在 DOM 中提早將內容移往前移。
- 請盡量支援螢幕閱讀器瀏覽所有頁面內容。確認網站區段不會永久隱藏，或是禁止螢幕閱讀器存取。
- 如果內容應在螢幕閱讀器中隱藏 (例如畫面外或只是呈現)，請將內容設為
aria-hidden="true"。詳情請參閱「隱藏內容」一文。
- 如果內容應在螢幕閱讀器中隱藏 (例如畫面外或只是呈現)，請將內容設為
熟悉螢幕閱讀器
學習操作螢幕閱讀器，聽起來也許很困難，但其實非常容易使用。一般來說，大部分開發人員只要輸入幾個簡單的鍵指令即可。
如果你使用的是 Mac，請觀看這部說明影片 VoiceOver，這是 Mac OS 內建的螢幕閱讀器。如果您使用 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>元素定義的項目。這些元素具有隱含地標角色。您也可以使用 ARIArole屬性來明確定義頁面上的區域，就像在<div role="search">中一樣。如需更多範例，請參閱「語意及瀏覽內容」一文。 - 除非您具備相關經驗，否則請避免使用
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，請在報表中找出無障礙功能測試失敗的情形。請修正錯誤以改善網站的整體使用者體驗。