GitHub 在 ２０２６ 年 ５ 月分享打造 general-purpose accessibility agent 的經驗，主題不是單純用 AI 寫程式，而是讓 agent 協助產品團隊發現 UI 無障礙問題。
這是一個很好的方向。可及性檢查常被放到開發流程後段，等到設計定稿、頁面做完、測試快結束才發現問題。AI agent 的價值，是把一部分檢查往前移，讓工程師和設計師在 PR、component、prototype 階段就看到風險。
accessibility agent 是什麼？
Accessibility agent 是用 AI agent 協助檢查產品介面的可及性問題。它可以結合：
- 瀏覽器自動化。
- DOM 結構。
- 截圖。
- 文字與標籤。
- 鍵盤操作。
- ARIA 屬性。
- 色彩對比。
- 已知規則。
- 人工審查回饋。
它不是只問模型「這個畫面有沒有問題」。比較可靠的做法，是讓 agent 讀取結構化資訊、操作頁面、執行規則檢查，再把可疑問題整理給人。
可以檢查哪些問題？
適合 AI agent 初步檢查的項目包括：
| 類型 | 例子 |
|---|---|
| 文字替代 | 圖片是否缺 alt text |
| 表單標籤 | input 是否有 label |
| 鍵盤操作 | 是否能 tab 到關鍵元件 |
| focus 狀態 | focus 是否可見 |
| 色彩對比 | 文字與背景是否太接近 |
| 語意結構 | heading 階層是否混亂 |
| ARIA | role 或 aria-label 是否錯用 |
| 錯誤提示 | 表單錯誤是否只靠顏色 |
這些問題很多可以自動化發現，但也需要人工判斷情境。
為什麼 agent 比單純 lint 更有用？
Lint 和規則檢查很重要，但它們通常只能看靜態結構。Agent 可以多做幾件事：
- 實際點擊與輸入。
- 模擬鍵盤路徑。
- 檢查互動後狀態。
- 比對截圖與 DOM。
- 整理問題成工程師看得懂的 PR comment。
- 將可疑問題對應到元件或檔案。
這使它更接近 QA assistant，而不是單純規則掃描器。
不能期待它做什麼？
Accessibility agent 不應取代：
- 專業可及性稽核。
- 使用者測試。
- 螢幕閱讀器實測。
- 法規符合性判斷。
- 設計系統治理。
模型可能誤判，也可能漏掉語境問題。例如某個 icon 是否足夠清楚、某段 microcopy 是否能被輔助科技正確理解，仍需要人審。
適合放在哪些流程？
建議放在：
- PR review。
- component library CI。
- design QA。
- release checklist。
- 重要頁面 regression tests。
- 新功能驗收。
比較實用的流程是：
- PR 建立後自動跑 accessibility agent。
- Agent 操作預覽頁或 Storybook。
- 產生問題清單與截圖。
- 標註嚴重度與對應元件。
- 工程師修正。
- 人工確認高風險項目。
這能把可及性變成日常開發的一部分，而不是最後一關。
企業導入建議
先從低風險、可重複的檢查開始：
- 常用元件。
- 登入流程。
- 表單。
- checkout。
- dashboard。
- 搜尋結果頁。
- 重要 landing page。
不要一開始就要求 agent 判定整站是否符合所有標準。比較合理的是建立一組常見錯誤測試，逐步擴大。
重點整理
GitHub accessibility agent 的啟發，是 AI agent 可以成為產品品質流程的一部分。它不只寫 code，也可以幫團隊提早發現互動、結構、標籤與可及性問題。
最好的定位不是「AI 無障礙專家」，而是「早期檢查助手」。它讓更多問題在 PR 前後被看見，再由人做最終判斷。