為什麼自動化無障礙測試會漏掉一半的問題

關於自動化無障礙測試令人不安的事實

自動化無障礙測試是 Web 團隊能建立的最佳習慣之一。它能抓到缺少表單標籤、文字對比不足、無效的 ARIA、重複 ID、空按鈕，以及其他不應進入正式環境的缺陷。

它也經常被誤解。

一份通過的自動化無障礙報告，並不代表頁面就是無障礙的。它只代表工具沒有找到它知道如何偵測的那一部分問題。這一部分很有價值，但有限。許多無障礙失敗取決於意義、順序、意圖、情境與人類互動。軟體可以檢查標記。它無法可靠理解使用螢幕閱讀器、鍵盤、放大功能、語音控制、字幕或認知支援的人，實際體驗是否可用。

這就是為什麼說自動化測試會漏掉約一半的問題，並不是憤世嫉俗。這甚至算是保守。有些問題類型高度可自動化。有些則幾乎完全無法自動化。

務實的答案不是放棄自動化工具。而是把它們放在正確的位置：及早、頻繁，並作為更完整測試流程的一部分。

自動化測試擅長什麼

自動化工具非常擅長找出確定性的失敗。如果一條規則可以表達為機器可讀的條件，掃描器通常就能快速且一致地檢查它。

常見例子包括：

• 缺少 alt 屬性的圖片
• 沒有關聯標籤的表單輸入
• 沒有無障礙名稱的按鈕
• 未達對比門檻的文字
• 無效的 ARIA 屬性或角色
• 以可疑方式跳級的標題層級
• 缺少或重複的 landmarks
• 無障礙名稱為空的連結
• 缺少基本結構的表格

這些檢查值得自動化，因為人類不擅長重複性檢查。如果工具能在毫秒內抓到缺少標籤，就不應該有人手動掃描每一頁。

自動化檢查也讓無障礙更容易被納入工程流程討論。CI 中失敗的測試很具體。pull request 中的警告很及時。跨模板的趨勢線能讓團隊有可改善的目標。

問題始於團隊把這些檢查當成無障礙的證明，而不是基本衛生的證明。

自動化在哪裡失效

無障礙不只是程式碼的屬性。它也是使用的屬性。

工具可以告訴你圖片是否有替代文字。它通常無法告訴你該替代文字是否有用。產品圖片在產品頁可能需要詳細描述，在裝飾性的主視覺中可能不需要描述，而在說明文章中可能需要完全不同的描述。正確答案取決於情境。這就是為什麼團隊需要像 圖片替代文字的務實方法 這樣的編輯指引，而不只是 linter 規則。

同樣的問題隨處可見。

掃描器可能確認每個按鈕都有無障礙名稱。它不一定能判斷該名稱是否合理。一個有五個按鈕都叫做「提交」的頁面，可能通過基本規則，卻仍讓螢幕閱讀器使用者非常痛苦。modal 可能具有正確的 ARIA 屬性，卻錯誤地困住焦點。自訂 dropdown 可能在靜態標記中看起來合規，但一旦有人嘗試用鍵盤操作就失敗。

自動化難以處理以下問題：

• 焦點順序是否符合視覺與邏輯順序？
• 每個任務是否都能只用鍵盤完成？
• 錯誤訊息是否具體、及時，並與欄位關聯？
• 文字調整大小或縮放時，頁面是否仍可使用？
• 對輔助技術而言，閱讀順序是否合理？
• 指示是否不依賴顏色或位置也能理解？
• 字幕、逐字稿與標籤是否真的傳達內容？
• 元件在不同狀態下的行為是否可預期？

這些不是邊緣案例。它們是無障礙的核心。

高分帶來的虛假安慰

無障礙分數很有吸引力，因為它把一個混亂的議題壓縮成一個數字。dashboard 顯示 98。報告顯示綠色勾勾。發布感覺更安全了。

但分數只是在衡量工具所能衡量的東西。

這很像效能測試。Lighthouse 報告可以揭露重要問題，但它不同於觀看真實使用者在中階手機上艱難完成緩慢的結帳流程。如果你的團隊已經使用效能稽核，同樣的思維也適用：仔細閱讀報告，然後優先處理會影響真實使用者的發現。我們曾在 如何閱讀 Lighthouse 報告而不恐慌 中談過這項區別。

無障礙報告也需要同樣的克制。乾淨的自動化掃描是一個起點。它不是證書。

當團隊只針對靜態頁面執行掃描時，風險尤其高。現代介面具有狀態：選單會開啟、抽屜會滑出、toast 會出現、驗證訊息會更新、分頁會切換面板、篩選器會重寫內容，而驗證狀態會改變一切。許多嚴重的無障礙缺陷就藏在這些互動之中。

如果你的掃描器只看到初始 DOM，它漏掉的就是產品本身。

最常被漏掉的類別

1. 鍵盤與焦點行為

鍵盤存取是說明自動化不足的最清楚例子之一。

工具可以偵測元素是否可聚焦。它可能抓到正數的 tabindex 值或明顯的焦點陷阱。但它無法可靠判斷 Tab 順序是否感覺連貫、動作之後焦點是否移到正確位置，或被關閉的元件是否把焦點返回觸發器。

你需要人實際在流程中按 Tab、Shift+Tab、Enter、Space、Escape 與方向鍵。

這對自訂控制項尤其重要。原生 HTML 元素免費提供多年累積的無障礙行為。用 div 重建按鈕、select、checkbox、menu 與 dialog，代表你的團隊現在必須擁有這些行為。如果你正在審查互動元件，請先從 無障礙 Web 按鈕的簡短檢查清單 開始，並把同樣的紀律延伸到每個自訂控制項。

2. 有意義的名稱與描述

自動化工具可以偵測缺失。它們對品質的偵測則差得多。

名為「閱讀更多」的連結，技術上可能具有無障礙名稱。標示為「確定」的按鈕可能有效。表單提示可能存在。但它們在情境中有意義嗎？通常沒有。

無障礙名稱應該告訴使用者將會發生什麼，或該元素代表什麼。這需要判斷。也需要測試介面，而不只是測試程式碼。

3. 錯誤處理

表單充滿了掃描器只能部分抓到的無障礙失敗。

工具可能標記未加標籤的欄位。它可能抓不到驗證訊息出現得太晚、消失得太快、沒有被螢幕閱讀器宣告，或在應該寫「密碼至少必須為 12 個字元」時卻只寫「無效的輸入」。

良好的錯誤處理是互動設計。它需要手動測試，理想情況下也需要使用者測試。

4. 視覺調整

WCAG 包含文字大小調整、重排、對比、間距，以及不依賴單一感官提示等要求。其中有些可以自動檢查，但真正的問題是介面在條件改變後是否仍然可用。

試試 200% 縮放。試試瀏覽器文字大小調整。試試高對比或強制色彩模式。試試窄視窗寬度。試試減少動態效果。許多在預設設定下看起來精緻的網站，會在使用者主張自己的偏好時迅速崩壞。

5. 內容清晰度

沒有任何自動化無障礙工具能完整評估內容是否易懂。

它可以標記缺少標題或含糊的連結文字。它無法知道頁面是否清楚解釋流程、標籤是否符合使用者期待，或密集文案是否造成可避免的認知負荷。

無障礙不只是輔助技術相容性。它也關乎降低在壓力下、使用不熟悉語言、面對注意力限制，或處理複雜任務的人所承受的摩擦。

更好的測試流程

平衡的無障礙流程有多個層次。

持續執行自動化檢查

在開發、pull request、元件預覽與 CI 中使用自動化測試。它們應該無聊、快速且不可協商。新的缺少標籤與無效 ARIA 不應該等到季度稽核才被發現。

把這些失敗視為 linting 失敗。目標不是英雄式補救，而是防止回歸。

加入手動鍵盤測試

針對每個有意義的使用者流程，不使用滑鼠進行測試。這包括導覽、搜尋、帳號建立、結帳、篩選、modal、選單與表單提交。

至少確認：

• 每個互動元素都可到達
• 焦點始終可見
• 焦點順序合乎邏輯
• 預期的按鍵可運作
• Escape 會關閉可關閉的覆蓋層
• 開啟與關閉元件後，焦點受到管理
• 不存在鍵盤陷阱

這個單一習慣會抓到自動化掃描漏掉的大量問題。

至少用一種螢幕閱讀器測試

你不需要成為螢幕閱讀器專家，也能學到有用的東西。但你需要保持謙遜。螢幕閱讀器測試有學習曲線，初學者可能誤判問題。

即便如此，使用 VoiceOver、NVDA 或 JAWS 進行基本測試，仍可揭露損壞的名稱、令人困惑的閱讀順序、未宣告的更新，以及掃描器可能抓不到的 landmark 問題。

搭配語意化 HTML。你使用越多原生元素，無障礙就越不脆弱。

審查內容與狀態

檢查空狀態、載入狀態、錯誤狀態、停用狀態、成功訊息與權限失敗。無障礙 bug 常藏在 happy path 之外。

也要審查實際用字。標籤、標題、指示與錯誤訊息都是介面的一部分。

在風險高時納入身心障礙使用者

對於關鍵流程，手動專家審查並不足夠。與身心障礙參與者進行使用者測試，能找出團隊沒有預料到的問題。這對公共服務、醫療保健、金融、教育，以及任何排除會造成嚴重後果的流程尤其重要。

自動化測試可以擴展。人類測試能夠理解。

如何負責任地解讀自動化結果

不要問：我們通過了嗎？

問更好的問題：

• 這個工具可以偵測哪些問題類別？
• 它掃描了哪些模板與狀態？
• 它是在互動之後執行，還是只在初始載入時執行？
• 違規是按根本原因分組，還是重複計數？
• 哪些失敗會阻止使用者完成任務？
• 哪些仍需要手動審查？

這種框架會改變對話。自動化工具成為證據，而不是權威。

它也能幫助團隊避免忙碌而無效的工作。修正單一元件可能移除數百個重複違規。相反地，一個只有一項回報問題的頁面，仍可能包含嚴重的鍵盤陷阱。數量不等於影響。

務實標準：自動化顯而易見的問題，手動測試體驗

最好的無障礙團隊並不反工具。他們反對幻想。

他們自動化機器能可靠偵測的事項。他們手動測試取決於行為與意義的事項。他們使用 WCAG 這類標準作為共同基準，而不是把它當成使用產品的替代品。

如果你目前的流程只是在上線前做一次自動化掃描，請依這個順序改善：

1. 在開發更早期加入自動化檢查。
2. 手動以鍵盤測試核心流程。
3. 審查名稱、標籤、錯誤與指示。
4. 使用螢幕閱讀器測試常見元件。
5. 針對高風險旅程導入專家與使用者測試。

這不是完美流程。這是務實流程。而它會找到遠比綠色無障礙分數更多的問題。