無障礙系列走到收官,前四天都在教你怎麼「做對」——WCAG 的底線、鍵盤與焦點、語意化 HTML 與 ARIA、表單錯誤提示。今天換一件事:怎麼「驗證你真的做對了」。因為無障礙有個殘酷的現實——你憑感覺覺得沒問題的東西,螢幕報讀器(screen reader)使用者可能完全用不了;而你以為靠一個工具跑出綠色 100 分就沒事了,那 100 分其實只涵蓋了問題的一小角。測試,是把「我以為」換成「我確認」的唯一手段。
📖 學
先建立一個心智模型:無障礙測試不是一件事,是三層互補的事,少任何一層都會漏。第一層是自動化工具(automated testing),第二層是手動測試(manual testing),第三層是輔助科技實測(assistive technology testing)。三層抓的問題種類不同,能力邊界很清楚,理解這點比會用任何單一工具都重要。
自動化工具是第一道防線,也是最容易被高估的一層。像 axe-core(Deque 開源的檢測引擎,DevTools、Lighthouse 背後都是它)、Google Lighthouse、WAVE、Pa11y 這些,能在幾秒內掃出一整頁的機器可判定問題:圖片缺 alt、表單控制項沒有標籤、色彩對比不足、標題階層跳號、ARIA 屬性用錯值。它們的價值在於快、可重複、零成本,適合天天跑。但關鍵數字要記牢——自動化工具大約只能抓到 30~40% 的 WCAG 問題。這不是工具做得不夠好,而是結構性的極限:機器只能檢查「能被程式量測」的東西。
為什麼剩下 60% 以上抓不到?因為那些都需要「人來判斷語意是否合理」。舉三個典型例子:一張圖有 alt="image123.jpg",自動化工具會判定「有替代文字,通過」——但這段文字對使用者毫無意義,機器讀不出這件事。一個頁面的 Tab 焦點順序在視覺上跳來跳去、邏輯錯亂,自動化工具看到每個元素都能聚焦,判定通過——但「順序合不合理」需要人走一遍才知道。一段紅字寫著「錯誤」,顏色對比也達標,工具通過——但它有沒有說清楚錯在哪、怎麼改,只有人讀得懂。語意是否正確、替代文字是否有意義、焦點邏輯是否合理,這三類全都在機器的射程之外,而它們恰恰是最影響真實體驗的部分。所以 Lighthouse 跑出 100 分,只代表「機器能測的部分沒踩雷」,不等於「這頁無障礙」。
第二層手動測試,門檻低到不可思議,收穫卻極大。最核心的一招:收起滑鼠,只用鍵盤走一遍。用 Tab 前進、Shift+Tab 後退、Enter/Space 觸發、方向鍵操作選單。你在檢查四件事——每個互動元素都到得了嗎(沒有滑鼠才點得到的東西)?焦點順序跟視覺閱讀順序一致嗎?**每一步都看得到清楚的焦點框(visible focus indicator)嗎?會不會卡在某個元件出不來(焦點陷阱,keyboard trap)?接著做兩件視覺檢查:用瀏覽器 DevTools 或對比檢查器量幾處關鍵文字的色彩對比(color contrast)**是否達 4.5:1;再把頁面轉灰階,看資訊是不是只靠顏色在傳達。這一輪不用任何專業工具,五分鐘就能抓出一堆自動化工具永遠看不到的問題。
第三層,也是最能逼近真相的一層:用真的輔助科技聽一遍。桌面上用 NVDA(Windows 免費開源)或 VoiceOver(macOS 內建,Cmd+F5 開),手機上用 VoiceOver(iOS)或 TalkBack(Android)。閉上眼睛,或把螢幕關掉,純靠耳朵操作你的頁面:報讀器把每個元素念成什麼?一個按鈕被念成「按鈕」還是「連結 未加標籤」?表單填錯時,錯誤訊息有沒有被念出來?這一層會殘忍地暴露前兩層的所有盲點,因為它就是你的真實使用者每天在經歷的東西。實測時可以只挑幾條關鍵動線(登入、搜尋、結帳),不必整站聽完,但一定要「真的用聽的」,不能用看的。
光會測還不夠,要把測試接進流程,才不會每次改版又退步。務實的三個接入點:設計階段就檢查色彩對比與焦點狀態,別等寫完 code 才發現主色過不了對比(這是最便宜的修法);CI 中跑 axe,用 @axe-core/playwright 或 jest-axe 把自動化檢測寫成測試,每次 push 自動擋掉低級錯誤;PR 檢查清單放一條「鍵盤能走完新功能嗎」,把手動測試變成人人要勾的動作。記住自動化只擋得住 30~40%,所以 CI 是安全網不是保證書,真正的把關還是靠 PR 裡那個人的手和耳朵。
最後補上合規背景,因為這正在從「最佳實踐」變成「法律義務」。WCAG 2.2 已是 W3C 正式推薦標準(2023 年發布,2024 年底修訂,並成為 ISO/IEC 40500:2025),新增 9 條成功準則,目標 AA 的網站要多顧到其中六條。而更硬的推力是歐盟無障礙法案(European Accessibility Act, EAA):自 2025 年 6 月 28 日起,新上市的產品與服務就必須符合;27 個成員國都已完成立法,法國在 2025 年 11 月出現首批訴訟。如果你的產品觸及歐洲市場,這已經不是加分題。實務上,企業會產出**符合性聲明(conformance statement)**或 VPAT(Voluntary Product Accessibility Template,自願性產品無障礙範本),誠實記錄符合到什麼程度——而這份聲明的可信度,完全建立在你上面那三層測試到底做得多紮實。
🧠 記
- 三層測試法:自動化(快、抓機器可判定問題)→ 手動(鍵盤走一遍、焦點、對比)→ 輔助科技實測(用 NVDA/VoiceOver/TalkBack 真的聽)。三層互補,缺一漏一大片。
- 自動化只抓 30~40%:圖片缺
alt、對比不足、標籤缺失這類機器可測的問題它很行;但這是結構性上限,不是工具不夠好。 - 剩下靠人判斷:替代文字有沒有意義、焦點順序合不合理、錯誤訊息說不說得清楚——語意類問題機器測不出來。Lighthouse 100 分 ≠ 無障礙。
- 最划算的一招:收起滑鼠,只用
Tab/Shift+Tab/Enter走一遍,檢查「到得了、順序對、看得見焦點、不卡住」。 - 接進流程:設計階段查對比、CI 跑 axe、PR 清單放「鍵盤能走完嗎」。愈早查愈便宜。
- 合規在收緊:WCAG 2.2(ISO/IEC 40500:2025)是標準,歐盟 EAA 自 2025-06-28 起強制;VPAT / 符合性聲明的可信度靠測試撐。
✍️ 實踐
今天挑一個你天天用的網站(自己做的最好,沒有就挑常逛的),做兩件事,十分鐘內做得完:
- 只用鍵盤走一遍:滑鼠移開,從網址列按
Tab開始,走過導覽、搜尋、一個主要動作。邊走邊問自己三題——每一步都看得到焦點框嗎?焦點順序跟你視覺上讀的順序一樣嗎?有沒有哪個地方Tab進去出不來?把卡住或看不到焦點的地方記下來。 - 跑一次自動化檢測:開 Chrome DevTools 的 Lighthouse 選 Accessibility 跑一次,或裝 axe DevTools 擴充功能掃一頁。看它報幾個問題、分幾類。
然後把兩份結果對照一下:你用鍵盤親手發現的問題,自動化工具抓到了幾個?你會很直接地體會到「為什麼三層都不能省」。
🔗 延伸學習
- axe-core — Deque 開源的無障礙檢測引擎(GitHub)
- Web Content Accessibility Guidelines (WCAG) 2.2 — W3C 正式推薦標準
- What’s New in WCAG 2.2 — W3C WAI(9 條新準則整理)
- European Accessibility Act 2025:2025 年 6 月上路的意義(Siteimprove)
💬 問 AI
我想紮實地驗證一個網頁的無障礙(accessibility),請用「三層測試法」帶我走一遍:
1. 自動化工具:推薦我在 CI 裡用 axe-core(例如 @axe-core/playwright 或 jest-axe)
的最小可行設定,並說明它「抓得到 / 抓不到」哪些類型的問題。
2. 手動測試:給我一份「只用鍵盤走一遍」的檢查清單,涵蓋焦點順序、可見焦點、
焦點陷阱、色彩對比,以及每一項該怎麼判斷通過。
3. 輔助科技實測:教我用 VoiceOver(macOS)或 NVDA(Windows)實際聽一遍我的
頁面時,該重點確認哪些點(標籤、狀態、錯誤朗讀)。
最後幫我把這三層對應到 WCAG 2.2 的準則,並說明若要面向歐盟市場(EAA),
我的符合性聲明 / VPAT 應該誠實揭露哪些資訊。