無障礙檢測指南

各國推動網站無障礙的方式不同，有些留下認證標章，有些留下無障礙聲明，有些靠監測、申訴、採購或市場監督。這篇說明為什麼 Accesserty 把它們當作線索，而不是網站好壞排名。

無障礙聲明不是認證，但它能告訴使用者網站如何描述標準、已知限制、回報管道與改善方式。這份指南說明哪些資訊值得看、哪些承諾需要保留判斷。

無障礙標章與認證是重要的公開證據，但通常有範圍、時間與制度限制。它們能提供信任線索，不能取代持續維護、使用者回報與實際檢查。

標章、無障礙聲明、ALLY、使用者回報與機器掃描摘要都是公開或可追溯的無障礙訊號。它們能幫助使用者和網站維護者看見線索，但不能被當成完整符合證明。

公開無障礙訊號能提供線索，但找不到聲明、認證或維護訊號，不代表網站沒有做無障礙；找到了，也不代表整個網站都沒有問題。

無障礙覆蓋工具不能取代語意 HTML、清楚內容、可操作元件、人工檢測與持續監測。這份指南整理團隊如何把無障礙修在產品本身。

自動化檢測很適合找出缺少標籤、ARIA 錯誤、部分對比與結構問題，但仍需要人工檢查內容、流程、鍵盤操作與輔助科技情境。

好的圖片替代文字不是把畫面全部描述出來，而是根據頁面脈絡傳達使用者完成任務所需要的資訊。

可及名稱讓螢幕讀取器等輔助科技知道按鈕、連結與表單欄位的用途。這份指南說明如何優先使用原生 HTML 與可見文字，再視情況補上 aria-label 或 aria-labelledby。

鍵盤焦點順序會影響使用者能否順利理解與操作頁面。這份指南說明常見焦點路徑問題、彈窗與 RWD 狀態，以及如何用 DevCheck 輔助人工檢查。

把網站無障礙檢測放進 release 前流程：先用自動化工具找出可被機器偵測的問題，再補上鍵盤操作、焦點、ARIA 與人工檢查。

開發者需要的不只是 URL 掃描器，而是能檢查 localhost、測試站、登入後畫面與互動狀態的瀏覽器內工具。

用產品、設計、QA 與工程都可執行的方式整理 WCAG 檢查：語意、表單、鍵盤、焦點、對比、ARIA、錯誤訊息與動態內容。

鍵盤操作是網站無障礙檢測的核心項目。檢查 Tab 順序、焦點提示、跳出困境、對話框與表單流程。

ARIA 可以補足複雜元件語意，但錯誤 ARIA 會更糟。用 W3C APG Patterns 檢查 tabs、dialog、accordion、menu button 等互動模式。

一次性檢測無法涵蓋所有後續更新。上線後應結合使用者回報、操作困難訊號、低頻機器掃描與人工確認。

網站上線不是無障礙工作的終點。內容、狀態、資料、第三方服務與真實使用流程都會改變，讓原本通過檢查的頁面再次出現操作阻礙。

網站維護者不需要每天重新檢測整個網站，但應該每週固定查看回報、互動困難、掃描摘要與近期變更，找出最需要優先人工確認的頁面。

使用者回報無障礙問題時，網站維護者需要先確認頁面與流程、判斷問題類型、做初步檢查，並把修正放進可追蹤的維護流程。

WCAG 3.0 仍是 W3C 草案，不能當成正式符合清單。這篇指南說明它和 WCAG 2 的差異、顏色對比案例透露的方向，以及現在網站維護與產品人員該如何務實看待。