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

English version: [https://accesserty.com/en/ai/guides/accessibility-testing-before-launch.md](https://accesserty.com/en/ai/guides/accessibility-testing-before-launch.md)

Page version: [https://accesserty.com/guides/accessibility-testing-before-launch/](https://accesserty.com/guides/accessibility-testing-before-launch/)

Last updated: 2026-09-28

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

## 重點整理

- 先選定這次變更影響的任務、頁面及狀態，再安排檢查。
- 接著補上鍵盤操作、焦點順序、互動狀態、ARIA 與內容理解等人工檢查。
- 修正後重跑相同步驟，未測項目明確保留；上線決策不能只看掃描是否歸零。

## 先定義這次上線要保護的流程

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

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

## 準備狀態與安全的測試資料

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

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

## 第一輪：先跑可自動化偵測的問題

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

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

## 第二輪：只用鍵盤走完主要任務

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

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

## 第三輪：確認內容、錯誤與狀態是否能被理解

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

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

## 哪些問題應該先修再上線？

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

- 主要任務無法不用滑鼠完成。
- 焦點遺失、看不見，或被困在互動元件內。
- 表單錯誤只靠顏色或不提供可操作的修正方向。
- 重要按鈕、連結或欄位沒有可及名稱。
- 自訂元件的角色、狀態和實際互動不一致。

## 修正重測與交接紀錄

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

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

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

## 接下來可以做什麼

- [自動化無障礙檢測能找到什麼，又找不到什麼](<https://accesserty.com/guides/automated-accessibility-checks-limits/>) — 用掃描結果找出可機器偵測的問題，同時保留需要人工判斷的部分。

- [如何檢查鍵盤焦點路徑](<https://accesserty.com/guides/how-to-check-keyboard-focus-path/>) — 確認焦點是否可到達、順序是否合理、是否被困住，以及操作路徑是否符合頁面脈絡。

## 延伸閱讀

- [執行各項檢查：WCAG 實用清單](<https://accesserty.com/guides/wcag-testing-checklist/>)

- [修正與重測工作如何安排](<https://accesserty.com/guides/web-accessibility-remediation-plan/>)

- [自動化檢測限制指南](<https://accesserty.com/guides/automated-accessibility-checks-limits/>)

- [焦點路徑檢查指南](<https://accesserty.com/guides/how-to-check-keyboard-focus-path/>)

- [可及的身份驗證術語頁](<https://accesserty.com/glossary/accessible-authentication/>)

- [螢幕閱讀器如何理解頁面？](<https://accesserty.com/glossary/screen-reader/>)

- [W3C WAI：在開發過程中評估無障礙](<https://www.w3.org/WAI/test-evaluate/>) — 說明及早、持續評估並結合工具與人工判斷。本文的上線檢查流程是實務建議，不是完整合規驗收。

- [Accesserty DevCheck](<https://accesserty.com/devcheck/>) — 用瀏覽器內工具檢查本機、測試站、登入後頁面與互動狀態。

- [網站無障礙檢測工具](<https://accesserty.com/web-accessibility-checker/>) — 針對實際頁面、登入後狀態與互動狀態做初步無障礙檢查。

- [看懂 WCAG 檢測結果](<https://accesserty.com/wcag-compliance-tool/>) — 檢視 WCAG A/AA 相關問題、嚴重程度、受影響元素與修正線索。

- [無障礙實作與維護指南](<https://accesserty.com/guides/>) — 依實際任務瀏覽公開訊號、上線前檢查、上線後維護與標準限制指南。