跳至中央內容區塊 :::
:::

為什麼無障礙問題常在網站上線後才出現？

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

最後更新:

重點摘要

  • 上線前檢查只能代表當時的頁面狀態，不能保證後續更新都維持可用。
  • 內容、登入狀態、資料長度、第三方嵌入、A/B 測試與元件更新，都可能讓無障礙問題在上線後才浮現。
  • 比較務實的做法，是把無障礙放進日常維護節奏，用回報、互動訊號與人工確認找出需要優先處理的頁面。

上線前檢查只看得到某個時間點

網站上線前的檢查很重要，因為它能抓出明顯的結構、互動與內容問題。但它看到的是當時的版本：當時的資料、當時的文案、當時的元件、當時的流程。

網站真正開始被使用後，內容會被新增，行銷頁會被替換，表單欄位會被調整，後台資料會變長，登入後狀態會變多。這些變化不一定大到需要重新設計，卻可能足以讓某些人卡住。

常見的上線後變化

很多上線後問題不是因為團隊不在意，而是因為網站本來就會持續變動。無障礙如果只在上線前檢查，就很容易錯過這些後續變化。

  • 內容變多：標題、按鈕、替代文字、錯誤訊息或說明文字可能被改得不清楚。
  • 資料變長：真實姓名、地址、商品名稱或錯誤清單可能破壞原本看起來正常的版面。
  • 狀態變複雜：登入、付款、驗證、空資料、錯誤、逾時與權限不足狀態，常常沒有在第一次檢查時完整出現。
  • 第三方服務改版：聊天工具、付款、地圖、嵌入表單、影片播放器或活動工具可能帶入新的鍵盤與語意問題。
  • 元件重複使用：同一個元件被放到新的情境後，焦點順序、文字脈絡或互動預期可能改變。
  • A/B 測試與行銷活動：短期頁面常常更新快，也最容易跳過完整檢查。

使用者遇到的是整個流程，不是單一頁面

機器掃描可以找出部分明確問題，但使用者遇到的困難常發生在流程中。例如：按鈕有名稱，送出失敗後卻找不到錯誤欄位；一般狀態的對比足夠，取得焦點或顯示錯誤後卻看不清楚；對話框可以開啟，關閉後焦點卻遺失。真正停用的控制項有對比例外，不應只因看起來較淡就判定不符合。

這些問題不一定在單次掃描中完整出現，卻會直接影響使用者是否能完成任務。

例子：新增的錯誤提示沒有被注意到

以下是虛構的預約表單情境，不是 Accesserty 的實測或客戶案例。上線前只檢查有效資料能否送出；更新後新增「這個時段已額滿」的回應，卻沒有再走一次失敗流程。按鈕與欄位仍有名稱，但使用者可能不知道預約沒有成立。

先用安全的測試資料重現：選擇測試用的額滿時段、送出、確認頁面顯示失敗原因，再只用鍵盤找到可改選的時段。不要在正式服務重複建立預約來測試。

  • 應有結果：失敗原因可見、不只靠顏色；訊息與需要修改的位置能連得起來，已填內容不會無故消失。
  • 鍵盤確認：可找到錯誤與修改欄位；若移動焦點，目的應清楚，不要求每次錯誤都強制跳焦點。
  • 螢幕閱讀器確認：實際操作檢查失敗訊息能否得知。DOM 中有訊息或 live region，不等於已聽到正確朗讀。
  • 重測範圍：額滿、有效送出、其他驗證錯誤與窄螢幕狀態。只記錄實際測過的環境，其他保留未測。

上線後需要的是維護節奏，不是每天重新檢測

持續監測不代表每天重新做完整檢測。比較實際的方式，是建立一個輕量節奏：看哪些頁面收到回報、哪些頁面出現重複操作困難、哪些頁面的最新機器掃描摘要有值得確認的線索，再決定哪些地方需要人工確認。

這也是 Pulse 的位置。Pulse 不取代專業檢測，也不宣稱網站符合要求；它把上線後的線索集中起來，讓維護者更容易知道先看哪裡。

Pulse 的掃描檢視呈現最新保存的摘要，不是掃描歷史的前後差異比較；操作事件的趨勢圖也不是掃描結果趨勢。若要確認修正前後的變化，請自行保留有日期與頁面狀態的前次結果，再以相同範圍重測、人工對照。沒有新掃描或事件減少，都不能單獨證明問題已修好。

團隊可以先做什麼？

如果團隊還沒有完整無障礙流程，可以先從小的維護習慣開始。每週看一次使用者回報與高風險頁面，比等到下一次大型檢測才發現問題更實際。

  • 在重要流程更新後，重新檢查鍵盤操作、焦點順序與錯誤狀態。
  • 把使用者回報集中到可以追蹤的地方，不要只散落在 email 或聊天訊息。
  • 對常改版的頁面設定定期檢視節奏。
  • 用機器掃描找明顯問題，但用人工確認流程是否真的可用。
  • 把修正回饋給設計、內容與元件系統，避免同一類問題重複發生。

相關頁面