# 網站維護者每週應該看哪些無障礙風險？

English version: [https://accesserty.com/en/ai/guides/weekly-accessibility-risk-review.md](https://accesserty.com/en/ai/guides/weekly-accessibility-risk-review.md)

Page version: [https://accesserty.com/guides/weekly-accessibility-risk-review/](https://accesserty.com/guides/weekly-accessibility-risk-review/)

Last updated: 2026-10-06

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

## 重點整理

- 每週檢查的目的不是證明網站符合要求，而是讓維護者知道這週該先看哪些頁面。
- 優先看本週回報與操作事件，再搭配目前最新掃描狀態、近期變更與重要流程判斷檢查順序。
- 最新掃描狀態不是本週新問題；它代表該頁目前保存的最近一次掃描摘要，應和近期事件分開解讀。

## 週報先回答：這週該看哪裡？

每週無障礙檢查不應該變成看分數或追求報表漂亮。比較務實的目標是：找出哪些頁面或流程最可能讓使用者無法完成事情，然後把有限的維護時間放在那裡。

好的週報應該先把「本週新出現的維護線索」和「目前仍存在的頁面掃描狀態」分開。前者告訴你最近哪裡有動靜，後者告訴你這些頁面目前保存的機器掃描風險。

## 每週建議看的六類訊號

以下訊號不是完整檢測，也不能單獨證明某個頁面有問題。它們的價值在於幫維護者縮小範圍，知道本週應該先看哪裡。

- 使用者回報：有人具體說明在哪個頁面遇到看不懂、按不到、送不出或無法完成的問題。
- 優先頁面：Pulse 依操作事件與掃描摘要排序，不直接納入 Signal 回報；回報要另外查看，再依任務重要性調整人工檢查順序。
- 重複互動線索：重複點擊、疑似鍵盤操作未明、焦點折返、Escape 關閉疑慮或鍵盤反覆循環，可能代表流程需要複查。
- 最新掃描狀態：先看工具標為 critical、serious（影響較高）的結果及 WCAG A/AA 相關問題，再看最佳實務建議。critical／serious 是掃描工具的影響標籤，不是 WCAG 等級；保存的結果也不代表本週新發現。
- 近期變更頁面：本週更新過文案、元件、表單、第三方嵌入、活動頁或登入後狀態的頁面。
- 重要流程：即使沒有很多訊號，仍應定期抽查登入、付款、搜尋、表單與客服聯絡等核心流程。

## 不要把每個訊號都當成同等嚴重

維護者最容易遇到的問題，是訊號一多就不知道從哪裡開始。比較好的排序方式，是看「影響任務的可能性」與「是否有多個訊號指向同一處」。

例如，同一個付款頁同時有本週使用者回報、鍵盤操作事件與 serious 掃描狀態，通常比一個低流量內容頁只有 minor 掃描建議更值得優先處理。相反地，單一訊號不一定代表錯誤；它可能只是提示你需要確認。

## 什麼時候需要人工確認？

只要訊號牽涉流程、語意、焦點、錯誤狀態、圖片替代文字或使用者是否能完成任務，就不應只靠數字判斷。這些情況需要有人打開頁面，實際操作一次。

DevCheck 可以在這裡補上瀏覽器內的初步人工檢查，例如模擬不同視覺情境、查看焦點路徑、執行 axe-core 初步掃描、檢查圖片替代文字建議或 PDF 結構訊號。但最後仍需要維護者判斷這個流程對人是否真的可用。

## 一個簡單的每週檢查節奏

如果團隊只有少量時間，可以從 30 分鐘開始。重點不是完成所有事情，而是讓無障礙風險不要累積到下次大型改版或正式檢測才被發現。

- 先看本週新增的使用者回報，確認是否有阻擋任務完成的問題。
- 查看 Pulse 的優先頁面清單，再對照另外收到的 Signal 回報與近期改版；具體的任務受阻回報不必等到頁面進入清單才處理。
- 比對本週改版或新增內容的頁面，確認是否需要重新檢查。
- 挑 1 到 3 個頁面做人工確認，先看鍵盤、焦點、錯誤訊息與主要互動。
- 把確認後的問題交給最接近問題來源的人：內容、設計、工程、第三方服務設定或元件系統。
- 記錄負責人、下一次確認時間與本週不處理的原因；修正後重跑原本的操作步驟。

## 範例：有事件、沒有掃描發現的篩選頁

週報範例中的 /products/filter 是虛構情境：11 次事件，分布在 4 次頁面瀏覽，最新掃描沒有發現問題。Pulse 為每次頁面瀏覽產生一個只存在該頁記憶體的隨機識別碼來分組事件；頁面瀏覽次數不是使用者人數，也不是完成或失敗的任務次數。因此這不是四個人操作失敗的證據，也不能直接診斷控制項故障。

先確認事件期間與掃描日期是否涵蓋這次改版，再用鍵盤進入篩選器、選擇條件、更新結果並移到下一個可操作項目。記下焦點位置、結果是否更新，以及錯誤或載入提示。需要確認朗讀時，再使用實際螢幕閱讀器測試。

若能重現焦點消失，就將具體步驟交給負責該元件的人；若無法重現，記下測試環境與待確認條件，不把線索當成已修復，也不要補寫成確定的失敗。

## 下週如何確認修正，而不是只看數字下降？

在你原本的工作清單記錄：頁面與狀態、線索日期、重現步驟、預期與實際結果、負責人、修正內容、重測環境，以及「待確認／已重現／已修正待重測／重測通過」。這是你的維護紀錄，不是 Pulse 會自動建立的工單。

重測應使用修正後的版本，執行原本失敗的操作，並檢查同一元件的相關流程。機器可檢查的項目可以當下重掃；不要等 Pulse 自動產生新摘要才確認修正。

Pulse 的掃描有快取間隔，不是每次開頁都重掃。沒有新事件，可能只是沒有人走到相同狀態；保存的舊掃描也不代表修正失敗。以檢查日期、頁面版本和實際重測結果判斷，不以一週數量下降當成使用體驗改善的證明。

## 延伸閱讀

- [看 Pulse 週報範例與判讀說明](<https://accesserty.com/pulse/report-example/>)

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

- [Accesserty Pulse](<https://accesserty.com/pulse/>) — 觀察上線後的操作困難訊號、機器掃描摘要與使用者回報。

- [網站上線後如何持續監測無障礙](<https://accesserty.com/guides/post-launch-accessibility-monitoring/>)

- [為什麼無障礙問題常在網站上線後才出現？](<https://accesserty.com/guides/why-accessibility-issues-appear-after-launch/>)

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

- [W3C WAI：持續維護無障礙](<https://www.w3.org/WAI/planning-and-managing/sustain/>) — 提供定期檢查與納入使用者回饋的原則。本文的 30 分鐘安排與選頁方式是實務建議，不是 W3C 要求。

- [Accesserty Signal](<https://accesserty.com/signal/>) — 在搜尋結果中查看可回到原始網頁查核的無障礙線索，並在遇到阻礙時回報。

- [網站資料處理說明](<https://accesserty.com/data-handling/>) — 了解 Pulse 與 Signal 會收集什麼、不會收集什麼，以及公開訊號和私有資料的差異。

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