網站上線前如何做無障礙檢測？給產品團隊的檢查流程

上線前先選定任務與測試狀態，再安排自動掃描、鍵盤與輔助科技檢查，最後記錄修正重測、未測範圍及交接事項。

最後更新: 2026年9月28日

重點摘要

上線前檢測不應只是一張全站掃描報告。比較有效的做法，是先列出這次更新會影響的主要任務，例如註冊、登入、搜尋、加入購物車、送出表單、下載文件或完成付款。

每個任務都要有明確起點、成功狀態與失敗狀態。這樣檢查時才知道問題會不會真的阻擋使用者，而不是只是在處理一串沒有優先順序的掃描結果。

例如檢查報名流程，不只打開首頁：列出空表單、輸入錯誤、修正後送出、成功提示，以及登入逾時等實際存在的狀態。記錄網址、版本、帳號權限與如何進入每個狀態。

使用已授權的測試站、測試帳號與虛構資料。付款、寄信、建立訂單或刪除資料會有真實副作用；先使用測試模式或安排可控的驗證，不要在正式服務反覆試送。

自動化檢查適合放在第一輪，因為它可以快速抓出明確、可重複、容易回歸的問題，例如缺少表單標籤、錯誤 ARIA、部分對比不足、標題結構異常或地標區域（landmark）使用不清楚。

DevCheck 的實際用途是在目前瀏覽器分頁內檢查 localhost、測試站、登入後頁面與互動後狀態。這和只能掃描公開 URL 的工具不同，因為很多上線風險在正式公開前就已經存在。

鍵盤檢查是上線前最容易被低估的項目。測試時不要只按幾次 Tab 就結束，而是要真的不用滑鼠完成主要任務。

如果焦點看不見、順序跳來跳去、選單打開後無法離開、對話框關閉後焦點遺失，或自訂元件只能用滑鼠操作，這些通常都應該在上線前處理。

有些問題不會被掃描工具直接判斷。連結文字是否說得清楚、圖片替代文字是否符合情境、錯誤訊息是否告訴使用者下一步、狀態改變是否被看見或聽見，這些都需要人工判斷。

這一輪的目標不是產生漂亮分數，而是確認使用者在不同操作方式下仍然知道自己在哪裡、發生什麼事、接下來可以做什麼。

不是每一個無障礙問題都會有同樣風險。比較務實的判斷方式，是先看問題是否阻擋主要任務、是否影響多人或關鍵使用情境、是否容易在元件層被修正，以及是否會讓使用者無法理解錯誤或無法離開目前狀態。

每一筆確認的問題都記錄操作步驟、預期與實際結果、影響狀態及負責人。修正後，用同一任務和環境重測，再抽查共用元件的其他頁面；不要只刪掉掃描截圖中的那一條。

例如報名表單修正錯誤提示後，重新輸入相同錯誤值，確認能找到欄位、理解提示、完成修正並得知送出結果。螢幕閱讀器尚未測就標「未測」，不能以 AX tree、模擬朗讀或純鍵盤測試代替。

交接時列出已確認修正、尚未解決、待確認與未測範圍，以及檢查日期、頁面版本、瀏覽器和輔助科技版本。由負責發布的人評估未完成事項及替代方式，不把這份流程當成完整 WCAG 符合證明。

依頁面內容選擇適用的下一步。有 PDF 才需要另外檢查文件；完成修正後仍要重測。