無障礙檢測指南

Accesserty 對照三十多個地區的制度後，看到幾種重複出現的公開無障礙訊號模式：官方標章、無障礙聲明、監測與申訴、採購文件、計畫報告，以及獎項或認可。

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

範例和產生器可以幫助起稿，但一份有用的無障礙聲明不能只貼上漂亮文字。這篇說明網站維護者發布前應確認的範圍、標準、限制、回報管道與維護節奏。

無障礙聲明的問題不只在於有沒有寫，而在於使用者、搜尋引擎與輔助工具是否能在需要時找到。這篇研究型文章說明聲明可見性為什麼是一種公開無障礙訊號。

網站無障礙認證與標章是重要的公開證據，但要看來源、範圍、標準、日期與效期。它們能提供信任線索，不能取代持續維護、使用者回報與實際檢查。

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

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

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

PDF 看起來像文件，不代表輔助科技能理解它。這篇用保守方式說明文件語言、標籤、閱讀順序、標題、書籤、連結、圖片替代文字與表單欄位等結構訊號，以及 DevCheck 能協助做的初步檢查。

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

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

鍵盤焦點順序會影響使用者能否順利理解與操作頁面。這份指南說明互動元素能不能被聚焦、焦點能不能移動到所有必要區域、是否會被困住，以及如何用 DevCheck 輔助人工檢查。

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

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

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

色彩對比不是只檢查品牌主色。Release 前應確認文字、連結、錯誤訊息、焦點提示、按鈕狀態、圖示與元件邊界在真實畫面中是否清楚。

鍵盤操作是網站無障礙檢測的核心項目。檢查互動元素是否可聚焦、Tab 順序、焦點提示、焦點是否被困住、對話框與表單流程。

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

網站上線後仍會改變。比較實際的無障礙維護方式，是用使用者回報、操作困難線索與低頻掃描摘要判斷哪些 live 頁面該先人工檢查。

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

每週無障礙檢查的目的不是重做完整稽核，而是用回報、操作事件、最新掃描狀態與近期變更排出最值得先檢查的頁面。

網站維護者收到無障礙回報後，應先確認收到、理解使用者任務、判斷影響範圍，再把問題放進可追蹤的維護流程。

好的無障礙回報管道不只是 email。它應該讓使用者能低負擔描述問題，保留維護者需要的脈絡，並把回報帶進可追蹤流程。

找到無障礙問題只是開始。這篇說明如何把掃描結果、使用者回報、互動線索與人工檢視輔助整理成可分派、可回測、可追蹤的網站無障礙修復計畫。

無障礙認證、聲明、使用者回報與機器掃描都能提供線索，但不能被簡化成網站是否完全無障礙的最終答案。這篇說明為什麼好的無障礙資料應該讓不確定性更清楚。

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

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