WCAG 檢測結果怎麼看？從發現問題到修正重測

拿到掃描結果，先分清楚這幾件事

以下以 DevCheck 的 axe-core 網頁掃描為例。結果描述的是這次掃描的頁面狀態；先看項目屬於哪一類，再決定修正或補查，不用把所有提示都當成同一種錯誤。

• 已確認的檢測項目：查看規則與元素

  例如 button-name 指出某個按鈕沒有可及名稱。查看列出的元素與說明，再確認按鈕實際用途。這是規則偵測結果，不是整個網站的符合性結論。

• 需要人工確認：還不能定案

  工具無法完成判斷時會要求人工確認，例如無法確定文字背後的背景色。回到畫面與相關狀態查核；不要直接算作通過，也不要直接算作確定錯誤。

• 沒有列出：不等於已檢查過

  尚未打開的選單、其他頁面、沒有走過的錯誤流程與實際朗讀，不會因這次沒有發現問題就自動變成通過。把這些範圍記為未測，安排操作與輔助科技測試。

• 數量：不是人數或失敗頁數

  同一規則可能列出多個元素，一個元素也可能涉及多個規則。例如一頁的三個按鈕缺少名稱，不是三頁失敗，也不是三個使用者遇到問題。先看是否來自同一個共用元件。

• 嚴重度：搭配實際任務排序

  Critical、Serious 等分類是檢查優先順序的線索，不是法律風險分數。確認是否阻擋主要任務、出現在哪些狀態，以及能否在共用元件修正，不只看總數下降。

把一項發現修正並重測

保留頁面與操作狀態，讓修正前後可以比較。請在可控制的測試環境操作，避免送出真實訂單或聯絡訊息。

1. 步驟 1

   記下頁面、瀏覽器、視窗寬度、登入與展開狀態。

2. 步驟 2

   查看規則 ID、元素與說明；如果無法定位，回到相同狀態重新掃描，不把定位失敗當成問題消失。

3. 步驟 3

   依元件用途修正程式或內容；例如替沒有名稱的按鈕補上清楚的可見文字。

4. 步驟 4

   重新載入並掃描相同狀態，確認該元素的原問題不再出現，也檢查是否新增其他問題。

5. 步驟 5

   重走相關鍵盤流程，另測朗讀與內容是否清楚；未做的檢查保留為未測，再把摘要交給負責的人。

自動化檢測不是符合法規的保證

DevCheck 可以協助需要檢查頁面的人更早發現可被機器偵測的無障礙問題，但任何自動化工具都無法保證完整符合 WCAG、ADA 或其他法規要求。正式檢測仍需要人工檢查、鍵盤操作測試、輔助科技測試與實際使用情境判斷。

誰適合參考這份判讀說明？

• PM 與產品人員

  分清楚已確認的問題與未測範圍，和負責修正的人討論受影響任務、優先順序與驗收方式。

• QA 人員

  記錄畫面與互動狀態，修正後重測相同情境，並保留尚未完成的鍵盤與螢幕閱讀器檢查。

• 設計師與工程師

  把規則與元素對回實際用途，確認修改解決了原來的障礙，也沒有破壞其他互動狀態。

• 替客戶交付網站的開發者

  拿到掃描結果或稽核報告時，分清楚已確認的問題和還要人工判斷的項目，再決定交付前先修哪些。

接下來想檢查什麼？

• Accesserty DevCheck

  了解各項檢查功能、哪些內容留在本機，以及如何安裝使用。

• 網頁無障礙檢測工具

  從目前開啟的網頁開始檢查，包括本機開發、測試站、登入後頁面與操作後才出現的內容。

• 自動化檢測限制指南

  如果需要理解自動化掃描能找什麼、找不到什麼，以及什麼時候需要人工確認，請看這篇指南。

常見問題