Accessibility testing 有一個常見的誤解：「我們用自動化工具掃過了，WCAG 合規了。」
問題是自動化工具能找到的問題大約是全部問題的 30–40%。剩下的 60–70% 只有人工操作或真實輔助科技（螢幕閱讀器、鍵盤導航）才能發現——圖片的 alt text 有沒有意義、表單錯誤訊息是否夠清楚、焦點順序是否符合閱讀邏輯。
但「先讓自動化工具把明顯問題擋掉」是合理的起點。
自動化工具：CI 裡的第一道關卡
axe-core：最廣泛整合的 accessibility 引擎，有 Playwright / Cypress / Jest-axe 的 binding。在 CI 裡跑，抓 WCAG 2.1 A / AA 違規。
// Jest + axe-core
import { axe, toHaveNoViolations } from 'jest-axe'
expect.extend(toHaveNoViolations)
test('login form is accessible', async () => {
const { container } = render(<LoginForm />)
const results = await axe(container)
expect(results).toHaveNoViolations()
})Playwright + axe：
import AxeBuilder from '@axe-core/playwright'
test('homepage accessibility', async ({ page }) => {
await page.goto('/')
const results = await new AxeBuilder({ page }).analyze()
expect(results.violations).toEqual([])
})WAVE（WebAIM）：瀏覽器 extension，視覺化標示頁面上的 accessibility 問題，適合開發時快速檢查。
Lighthouse：Chrome DevTools 內建，accessibility 分數可以加進 CI threshold。
自動化抓不到的：必須人工驗證
鍵盤導航：Tab 鍵能不能瀏覽所有互動元素？焦點順序是否符合頁面閱讀邏輯？操作 modal 時焦點有沒有 trap 在 modal 裡？
螢幕閱讀器：VoiceOver（macOS/iOS）或 NVDA（Windows）實際讀出頁面時，有沒有提供足夠的上下文？「按這裡」三個字不足以描述一個按鈕的功能。
色彩對比：工具能測算對比值，但測不出「設計上這個灰色文字在白底上雖然符合 4.5:1 最低標準，但在強光環境下幾乎看不到」。
動態內容：AJAX 更新後，螢幕閱讀器有沒有被通知到？aria-live 區域設定正確嗎？
WCAG 合規的基本心態
WCAG 2.1 的 AA 等級是大多數企業應用的合規目標，分三層：
- A：基本必要（圖片要有 alt、表單要有 label）
- AA：中等要求（對比度 ≥ 4.5:1、鍵盤可操作）
- AAA：最高要求（手語影片、更高對比度）
可操作的做法：把 axe-core 加進 CI，阻擋 A 和 AA 的嚴重違規。定期（每季或重大 UI 改版後）找一位用螢幕閱讀器的人做人工測試，或者讓工程師蒙上眼睛只用鍵盤操作自己的功能。
Accessibility testing 不是一次性的合規作業，是持續整合進開發流程的品質層次。