昨天的 UIUX算的是半透明面板在最壞桌布下的對比度，那是一個「可以用公式驗收」的無障礙問題。今天換到相反的一端：美國聯邦政府的 U.S. Web Design System（USWDS）新任負責人在 2026 年 9 月 22 日的置頂公告裡，把第一項優先事項寫成「盡可能把無障礙測試自動化」，而前任工程負責人說，能可靠自動化的只有約 30%。這個爭議的價值在於，它把一個設計系統團隊每天都在做的假設攤開來：測試工具綠燈，到底等於多少比例的無障礙？我用 USWDS 自己的 3.14.0 發行說明做了一次小型對照，結果和那個 30% 的方向一致，但樣本小、有選擇偏誤，後面會講清楚。以下只談設計系統與無障礙實務，不評論任何人事或政治立場。
先交代讀到什麼。我讀到 GitHub 上 USWDS 優先事項公告的內容（作者 ryparker，2026 年 9 月 22 日）、Matt Henry（前 USWDS 工程負責人）2026 年 9 月 18 日的個人部落格文章、FedScoop 的報導、Nextgov 的報導與 CDO Magazine 的評論，以及 Deque 和 WebAIM 的一手研究頁面；這些頁面是經抓取工具摘要後讀到的，不是我逐字全讀。USWDS 發行日期我另外用 GitHub API 查證，因為抓取工具對發行頁面給的年份是錯的（把 3.14.0 寫成 2024 年），以 API 為準。「約 30%」這個數字，我在 Henry 部落格文章的摘要中沒有找到，出處是 FedScoop 與 CDO Magazine 轉述他的說法，計算基準沒有公開，這一點下面會標存疑。
📖 學
一、事實對帳：發生了什麼、哪些細節對不上
USWDS 是美國聯邦政府的開源設計系統，提供按鈕、表單、對話框、日期選擇器等元件與設計代幣，聯邦、州與地方政府網站大量採用。GitHub 倉庫目前約有 7,218 顆星（我 2026 年 10 月 11 日用 GitHub API 查），最新穩定版 3.14.0 發行於 2026 年 8 月 18 日，上一版 3.13.0 是 2025 年 5 月 23 日，中間隔了 452 天（自算：2025-05-23 到 2026-08-18）。
人事部分兩個來源說法不完全一致，我兩邊都列。Henry 的文章把時間線寫成：2025 年上半年團隊從約 12 人縮減到 4 人再到 2 位聯邦員工；2026 年 8 月，產品負責人被放行政假、開源貢獻者被移除，Ryan Parker 被安排為 USWDS 負責人。FedScoop 則寫 USWDS 計畫負責人 Anne Petersen 在 9 月初被放行政假並移出倉庫，由財政部 AI 工程師 Ryan Parker 接任，同時財政部資訊長 Sam Corcos 兼任三個 GSA 領導職位。8 月與 9 月初的差異我沒有第三個來源可以仲裁，所以不下結論。
和設計系統實務直接相關的事實有這幾項。第一，9 月 22 日的公告列了四項優先事項：自動化無障礙測試、改善 USWDS 3、採用語意化版本控制、探索下一版（含 USWDS Elements 與 AI 工具相容性），並承諾每兩週更新一次進度。第二，倉庫導入了 OpenAI 的 Codex 與 CodeRabbit 做程式碼審查（FedScoop、Nextgov 都這樣寫，Nextgov 並寫到 CodeRabbit 用於自動核准，這點我沒在一手頁面確認）。第三，Nextgov 報導一個近 200 人的 Slack 社群 People’s Design System 要成立治理委員會，做 USWDS 的 hard fork（時間點複本，不接收也不回推上游），並已有 Open Government Design System（OGDS）可用；徵求貢獻者的表單截止日是 2026 年 10 月 1 日，接下來 30 天的工作。第四，倉庫的提交紀錄顯示 9 月 28 日有一個「新增管理聲明到行為準則指引」的提交，10 月 1 日又被 Corcos 以 revert 還原（這是我用 API 讀到的公開紀錄，不含動機解讀）。FedScoop 另外報導有貢獻者質疑流程被回覆「Wrong」且該留言後來被刪，我無法從公開紀錄驗證，只當報導。
要注意的立場：Henry 與 Nextgov 引述的 Noah Kunin、Casey Watts 等人都是前任或社群方，我沒有讀到現任負責人對這些批評的完整回應，只有公告本身。所以下面談的是「這個爭議揭示的測試問題」，而不是誰對誰錯。
二、三個數字，三個分母
討論「自動化能抓多少無障礙問題」時，有三個數字常被混用，它們的分母不同，不能互相對質。
| 數字 | 來源 | 分母是什麼 | 我的標註 |
|---|---|---|---|
| 約 30% | Matt Henry，經 FedScoop、CDO Magazine 轉述 | 未公開；「可靠自動化的無障礙測試比例」 | 存疑：我沒在他文章摘要找到，基準不明 |
| 約一半 | Sheri Byrne-Haber，經 FedScoop | 自動工具「偵測到的違規」佔全部違規的比例 | 轉述，未見其方法 |
| 57% | Deque，2021 年 3 月 10 日研究 | 「問題總量」：2,000 多次稽核、1.3 萬多頁、近 30 萬個問題，axe 完全涵蓋的比例 | 一手頁面，但是 2021 年的資料、僅限首次稽核 |
Deque 的 57% 本身就是爭議點：它把「涵蓋率」從「可自動檢查的 WCAG 成功準則數」改成「問題總量」，因為常見問題（缺替代文字、對比不足）出現頻率高，自動工具抓得到，總量比例就被拉高。換句話說，57% 與 30% 不矛盾，兩者回答不同的問題：一個是「所有被人工稽核找到的問題裡，有多少機器也找得到」，另一個更接近「WCAG 準則中，有多少項能被機器可靠判定」。依 Deque 的數字，剩下的 43% 約 12.9 萬個問題（自算：近 30 萬 × 0.43，是上限估計，因為「近 30 萬」本身是約數），是需要人判斷的部分。Deque 頁面沒有拆解這 43% 是哪些類型。
三、WebAIM：偵測不是瓶頸
2026 年 2 月的 WebAIM Million（分析 100 萬個首頁）給了另一個視角。平均每頁偵測到 56.1 個錯誤，比 2025 年的 51 個多 10.1%；95.9% 的首頁有可偵測到的 WCAG 2 失敗，前一年是 94.8%，結束了連續六年緩步改善的趨勢。六大失敗類型依序是：低對比文字 83.9%、圖片缺替代文字 53.1%、表單欄位缺標籤 51%、空連結 46.3%、空按鈕 30.6%、缺文件語言 13.5%。
這份數字有一個常被忽略的含意：WebAIM 只計算「自動可偵測」的失敗。也就是說，這 56.1 個錯誤在原理上全部是工具抓得到的，卻還是出現在 95.9% 的首頁。瓶頸不是偵測，是修正與預防。報告也指出頁面複雜度升高，並把「依賴第三方框架與函式庫、自動或 AI 輔助寫碼（vibe coding）」列為可能原因；這是 WebAIM 的推測，不是因果證明。報告還有一組數字：82.7% 的頁面使用 ARIA，平均每頁 133.6 個 ARIA 屬性（一年增加 27%），而使用 ARIA 的頁面平均 59.1 個錯誤，沒用的頁面是 42 個，前者高約 40.7%（自算：59.1 ÷ 42 = 1.407）。這是相關而非因果，用 ARIA 的頁面本來就更複雜，但它說明「加屬性」不等於「做對」，而「做對沒有」恰恰是自動工具最難判斷的。
四、用 USWDS 3.14.0 做一次小型對照
最有意思的證據其實在 USWDS 自己的發行說明裡。3.14.0 的變更表一共 22 項，其中標記為無障礙（A11y 欄為 Yes）的有 10 項，佔 45.5%（自算：10 ÷ 22）。我逐項問一個問題：要發現這個缺陷，需要什麼？下面的判斷是我自己的主觀分類，不是任何工具的實測，我也沒有真的拿 axe 去掃這些元件。
| 變更（3.14.0） | 要發現它需要什麼 | 單次靜態掃描能抓？（自評） |
|---|---|---|
對話框關閉後恢復螢幕閱讀器對頁面的存取（開啟者已離開文件時，頁面留著 aria-hidden="true"） | 開、移除觸發者、關的互動序列，加輔助科技 | 否 |
| 修正對話框內容被朗讀兩次；預設焦點改到頁尾第一個按鈕 | 螢幕閱讀器實際聆聽 | 否 |
| 日期欄位拆成每欄各自的提示（原本共用提示在每欄聚焦時重複朗讀整段） | 螢幕閱讀器實際聆聽 | 否 |
字數統計延後 aria-live，避免 iOS VoiceOver 在頁面載入時就朗讀 | iOS 實機加 VoiceOver | 否 |
| 檔案上傳在粗略指標裝置移除「拖曳」提示 | 觸控裝置或模擬，加判斷 | 否 |
| 範圍滑桿新增可見提示（讓視力正常者與螢幕閱讀器使用者得到同樣指引） | 比對兩種使用者收到的資訊 | 否 |
日期選擇器今天按鈕加 aria-current="date" | 螢幕閱讀器、或知道要加這個屬性 | 否 |
範圍滑桿邊框改 2 像素、使用 base-darker，並加焦點環 | 非文字對比與焦點可見的人工或視覺檢查 | 多半否（自評，我沒驗證常見規則集是否涵蓋） |
| 麵包屑預設換行，截斷改為選用 | 縮放與重排的視覺檢查 | 否 |
| 手風琴新增左側展開圖示選項（高倍率放大時更易發現） | 放大情境下的可發現性判斷 | 否 |
十項裡我找不到一項是「掃一次頁面、規則比對就能報錯」的類型。這個結果有兩個必須講明的限制。第一是選擇偏誤：發行說明列的是「人發現並修掉的缺陷」，工具早就能報的低階問題在更早的版本就被修掉了，不會出現在這份清單；所以這個對照不能證明「自動化只能抓 30%」，只能說明「剩下需要人的部分長什麼樣子」。第二是樣本只有一個版本的 10 項，沒有統計意義。我把它當作質性例子：這些缺陷的共同特徵是需要狀態變化（開了再關）、需要輔助科技的實際輸出，或需要比對兩種使用者收到的資訊是否等價。
這也解釋了為什麼設計系統團隊的測試設計與一般產品團隊不同。元件庫的價值是「修一次，所有採用者受惠」，所以它必須測的是行為（焦點去哪、朗讀什麼、狀態怎麼還原），而不只是靜態標記。USWDS 公告裡列的待處理貢獻是對話框鍵盤焦點與日期選擇器的朗讀（這是我讀到的公告摘要內容），這兩項恰好都屬於上表中需要人聽、人按的類型。
五、自動化該放在哪裡
這裡不是反對自動化。工具的角色是把「機器能確定的事」固定住，讓人把時間留給「機器無法判斷的事」。合理的分工可以這樣切：
CI 階段自動跑靜態規則（axe-core 一類），攔截缺標籤、空按鈕、缺語言、明確對比不足這類 WebAIM 前六名；它們佔了首頁錯誤的大宗，擋在合併前最划算。其次是行為測試腳本，把「開啟、關閉、焦點回到哪」寫成元件測試，這需要有人先定義預期，而預期來自人類先用輔助科技操作過一次。最後是人工與輔助科技的定期走查，頻率跟著元件變更：凡是動到焦點管理、aria-live、對話框、日期、表單提示的 PR，都附一張人工驗證紀錄。AI 程式碼審查工具可以放在第一層與第二層，幫忙提醒；但在這個分工下，它的輸出是「建議」，核准權仍要有人，因為 CDO Magazine 的評論也點到：自動化合規流程需要「文件化的標準，說明工具能與不能可靠抓到什麼」。
🧠 記
- USWDS 新優先事項第一項是自動化無障礙測試。 2026 年 9 月 22 日公告；批評者說只有約 30% 能可靠自動化，該數字基準未公開，標存疑。
- 三個數字分母不同。 30%（基準不明）、約一半（Byrne-Haber 轉述）、57%（Deque 2021 年，以問題總量計）；不能互相反駁。
- WebAIM Million 2026：56.1 個錯誤每頁、95.9% 首頁有失敗。 這些全是自動可偵測的失敗，所以瓶頸是修正與預防，不是偵測。
- USWDS 3.14.0 有 22 項變更、10 項標記無障礙。 我主觀判斷其中沒有一項是單次靜態掃描能抓到的。
- 這個對照有選擇偏誤。 發行說明只列人找到的缺陷，不能證明 30%。
- 元件庫要測行為。 焦點去哪、朗讀什麼、狀態怎麼還原，靜態標記檢查蓋不到。
邊界： 我沒有對 USWDS 元件實際跑 axe 或螢幕閱讀器；10 項分類是我的判斷；30% 的出處是轉述且基準不明；Henry 與現任團隊之間的人事時間（8 月或 9 月初）兩個來源不一致；Nextgov 說 CodeRabbit 用於自動核准，我沒在一手頁面確認；現任負責人對批評的完整回應我沒讀到。
✍️ 實踐
用 30 分鐘替自己的設計系統做一次「工具對人」的對帳，得到你自己的比例：
- 選三個互動元件。 對話框、下拉或日期選擇、有即時回饋的表單欄位，這三類最容易有狀態與朗讀問題。
- 先跑工具。 對含這三個元件的頁面跑一次 axe（瀏覽器擴充或 CLI 都可以），記下回報的問題數與類型。
- 再用鍵盤走一遍。 只用 Tab、Shift+Tab、Esc、Enter：對話框開啟時焦點是否進去、Esc 關閉後焦點是否回到觸發者、背景是否真的不可聚焦。
- 再開 10 分鐘螢幕閱讀器。 macOS 用 VoiceOver（Command+F5），逐一操作三個元件，記下有沒有重複朗讀、有沒有沒說出來的狀態變化。
- 做對帳表。 兩欄：工具找到的問題數、人工找到的問題數，標出重疊；人工獨有的那幾項各寫一行「可寫成什麼行為測試」。
- 把結果寫進團隊文件。 寫出你的版本的「工具涵蓋什麼、不涵蓋什麼」，這是 CDO Magazine 所說的文件化標準。
🔗 延伸學習
- A Trump team wants to automate U.S. Web Design System accessibility testing. Experts are worried.（FedScoop） — 爭議的主要報導，含 30% 與「約一半」兩個轉述數字的出處。
- USWDS is dead. Long live USWDS.（Matt Henry） — 前工程負責人的一手敘述與時間線，立場鮮明，需與其他來源對照閱讀。
- The WebAIM Million 2026（WebAIM） — 100 萬首頁的自動偵測失敗統計，含六大失敗類型與 ARIA 使用情況。
- USWDS 3.14.0 發行說明（GitHub） — 本篇對照表的原始材料，每項變更都標記是否為無障礙修正。
💬 問 AI
我是設計系統維護者,想評估「自動化無障礙測試能涵蓋多少」。請嚴格分成「文件明說」「你查證到的」「你的推論」三區回答,不確定就直說,不要編造連結、數字或版本號。
背景(請當待查證主張):
1. USWDS 維護者 2026-09-22 公告把「盡可能自動化無障礙測試」列為第一優先。
2. 前工程負責人 Matt Henry 被轉述說只有約 30% 能可靠自動化(基準不明)。
3. Deque 2021-03-10 研究:以問題總量計,axe 涵蓋 57%(2,000 多次稽核、1.3 萬多頁、近 30 萬個問題)。
4. WebAIM Million 2026:56.1 個錯誤每頁,95.9% 首頁有可偵測失敗。
請做:
A. 逐點用一手來源驗證 1-4,標示「成立/部分成立/查不到」並附連結;讀不到就直說。
B. 解釋 30% 與 57% 為何可能同時為真(分母差異:成功準則數 vs 問題總量),並指出哪個比較適合用來規劃團隊的人工測試預算。
C. 我的元件庫有對話框、日期選擇器、表單欄位的 aria-live 提示。請為每個元件各寫 3 條「行為測試」(開啟/關閉焦點、螢幕閱讀器朗讀、狀態還原),標明哪些能寫成自動化測試、哪些必須人工。
D. 設計一份 PR 範本裡的「無障礙人工驗證紀錄」欄位,哪些變更必須填寫。
只談設計與測試方法,不評論任何人事或政治立場。