不要只裝 Overlay：真正改善網站無障礙的做法

先判斷：問題在哪一層？

無障礙問題通常不只存在於單一程式碼。它可能在內容、設計、元件、資料狀態、互動流程或上線後的真實使用情境裡。

如果問題在網站本身，外加工具列通常只能遮住一部分症狀，不能讓原本的流程變得可靠。

• 內容層：連結文字、圖片替代文字、錯誤訊息是否清楚。
• 設計層：對比、焦點、觸控目標、狀態提示是否足夠。
• 元件層：名稱、角色、狀態、鍵盤操作是否和實際行為一致。
• 流程層：不用滑鼠、放大畫面或使用輔助科技時是否仍能完成任務。
• 上線後：使用者是否在表單、導覽或互動區域反覆受阻。

一個比較穩定的修復順序

最穩定的做法不是最後裝一個東西，而是把無障礙放進日常製作流程。先修容易重複出錯的基礎，再檢查互動流程，最後建立上線後的回饋與監測節奏。

• 用語意 HTML 與原生控制項作為基礎。
• 讓設計系統或元件庫先避免常見錯誤。
• 在本機、測試站、登入後頁面與互動狀態執行檢查。
• 補上鍵盤操作、焦點、表單錯誤、圖片描述與語言標記等人工檢查。
• 上線後觀察使用者是否仍遇到重複阻礙。

Overlay 不能替你完成的事

Overlay 很難知道你的產品真正想讓使用者完成什麼任務，也很難判斷內容是否說清楚、圖片描述是否適合情境、或錯誤訊息是否足以讓人繼續操作。

它也無法代替團隊對元件與流程負責。表單送出失敗、對話框焦點錯亂、連結文字模糊、鍵盤陷阱、動態內容未被宣告，這些通常都需要回到原始產品修正。

用工具，但不要把工具當結論

自動化檢測很適合快速找出缺少標籤、ARIA 錯誤、部分對比問題與結構問題。DevCheck 可以在目前瀏覽器分頁執行檢查，也能協助團隊用情境模擬討論頁面是否仍容易使用。

但工具只能協助開始。能不能完成任務、內容是否足夠清楚、輔助科技使用者是否真的能理解流程，仍然需要人工檢查與實際情境測試。

把改善留在系統裡

如果同一種問題一直回來，代表只修單頁不夠。這時候應該回到元件、內容規則、設計規範或驗收流程。UI Kit 的價值就在於讓常用元件從基礎就比較不容易犯錯。

如果問題只在上線後才暴露，則需要 Pulse 這類使用訊號協助團隊知道哪些頁面或流程應該被優先檢查。Signal 則讓公開的認證、聲明與維護訊號，在搜尋階段就比較容易被看見。

相關頁面

• 無障礙覆蓋工具術語頁
• Accesserty DevCheck

  在目前瀏覽器分頁進行初步檢查、情境模擬與語意輔助檢測。

• Accesserty Pulse

  用上線後的互動訊號觀察使用者是否仍遇到操作阻礙。

• Accesserty UI Kit

  從元件基礎減少重複出現的無障礙缺陷。