昨天的 UIUX 留下兩個待辦：Figma Motion 匯出 Lottie 的實測清單，我今天仍然沒有建檔環境，原樣保留；Run 對話框那篇文章「有沒有談無障礙、有沒有提 Ctrl+Shift+Enter」，今天補查了。我重新抓了 Microsoft 開發者部落格原文，擷取結果是全文沒有出現 Ctrl+Shift+Enter、以系統管理員身分執行、Narrator、報讀器與鍵盤導覽任何一個詞，所以昨天「沒讀到」的說法成立，這一點從昨天的「工具可能漏抓」升級為「連續多次擷取都沒有」，但仍不等於產品沒做。另外昨天我說 0.0038% 的分母不明，原文那句其實寫的是「0.0038% 的使用者點過那個按鈕，樣本 3,500 萬」，分母是使用者，所以約 1,330 名使用者（35,000,000 乘以 0.000038），這一條更正。Windows 與 Surface 發表會在台北時間 10 月 8 日凌晨 1 點（舊金山 10 月 7 日上午 10 點）才開始，寫稿時還沒發生，不評論。今天換一個更基礎、會牽動所有設計系統的題目：W3C 在 2026 年 9 月 10 日發布的 WCAG 3 新版工作草案，以及它和各種二手文章說法對不上的地方。以下標明出處；只談設計與規格，不碰任何財經。
📖 學
一、先確認草案現在長什麼樣：二手文章和一手頁面打架
搜尋「WCAG 3.0」會得到一堆 2026 年的整理文，多數寫成「從 A/AA/AAA 改成青銅、白銀、黃金三級計分」。我實際打開兩份一手頁面比對：WCAG 3 的草案本文（w3.org/TR/wcag-3.0），和 W3C WAI 的〈WCAG 3 Introduction〉頁。結果如下，兩者互相吻合，但和那批文章不一致。
| 項目 | 一手頁面的內容 | 二手文章常見說法 |
|---|---|---|
| 草案日期 | 2026 年 9 月 10 日工作草案；W3C 部落格 9 月 25 日由 WAI 主任 Shawn Lawton Henry 發文說明 | 有的仍寫「2026 年 3 月更新」，已過時 |
| 一致性模型 | 單一層級的「核心要求（core requirements）」，建立在 WCAG 2.2 的 A 與 AA 之上；另有補充要求、斷言（assertions）、建議做法 | 青銅、白銀、黃金三級計分 |
| 報告層級 | 六個回報層級（reporting tiers）；第三層就是「符合」＝全部核心要求，第四到六層加上數量待定的補充要求與斷言 | 以分數決定等級 |
| 對比算法 | 草案明寫「尚未決定」，內文以 @@ 占位 | 常寫成「採用 APCA」 |
| 時程 | WAI 頁面：幾年內不會是完成的標準；WCAG 2 在 WCAG 3 定案後數年內不會被廢止 | 預期 2027 第四季進候選建議、2028 後定案 |
這裡必須講清楚我的證據強度：WebFetch 是把頁面丟給小模型做摘要，不是我逐字讀完。針對「Bronze、Silver、Gold、APCA、score 這幾個字是否出現在草案本文」，我問了一次，回答是全部不出現；WAI 介紹頁則被擷取成一句明確的話：WCAG 3 不使用 Bronze/Silver/Gold 的稱呼，而是用回報層級。兩次獨立頁面的結論一致，我認為可信，但要寫進公司規範之前，請自己在頁面按 Ctrl+F 搜尋這幾個字確認。時程那一欄的「2027 第四季」只來自二手文章，WAI 頁面只說「幾年內」，所以我只把後者當事實。另外要記得，搜尋結果裡有一篇設計系統取向的部落格把第四到六層描述成「Bronze、Silver、Gold 的餘裕」，那是作者的對應方式，不是 W3C 的用語。
二、四個標籤：把「重要程度」寫進要求本身
草案最值得設計團隊吸收的是核心要求的四個標籤，WAI 頁面逐字定義如下（我翻成中文）：
| 標籤 | 定義 |
|---|---|
| 物理傷害（Physical harm） | 沒做到會讓身心障礙者立即受到身體傷害 |
| 風險（Risk） | 沒做到會不合理地提高該使用者的財務、醫療、法律、隱私或資安風險 |
| 障礙（Barrier） | 沒做到會讓該使用者無法繼續往下走 |
| 摩擦（Friction） | 沒做到會妨礙、拖累該使用者 |
回報層級的對應是：第一層只要求物理傷害與風險；第二層加上障礙；第三層再加上摩擦，也就是全部核心要求。這等於把 WCAG 2 過去「A 比 AA 重要」那種粗略排序，換成以後果為依據的排序。WAI 頁面沒有替任何標籤舉例，哪條要求落在哪個標籤，草案本文也還在調整，所以我把具體要求歸到哪個標籤，都只是我的推論，只能當分診用，不是官方分類。
這個排序對設計實務的意義在於優先順序：同一份稽核清單裡有「閃爍頻率可能誘發癲癇」「付款確認按鈕只能用滑鼠點」「圖示按鈕沒有名稱」「焦點環顏色偏淡」，過去它們都只是「不合規」；以後果排序，第一項是物理傷害、第二項是風險或障礙、第三項是障礙、第四項是摩擦，修復順序自然不同。
三、草案的新結果（outcomes）：有哪些是 WCAG 2.2 沒有逐項寫的
草案的指引（guideline）下面是「結果」（outcome）。我讓工具列出四組與介面設計最相關的標題，下面是原文標題的中譯，編號不採用，因為擷取結果的編號看起來不可靠。
「鍵盤介面輸入」底下有九項：鍵盤可操作、鍵盤不依賴特定時間、可雙向導覽、自訂快捷鍵有文件、自訂快捷鍵不與瀏覽器或作業系統衝突、焦點會落到新出現的內容、不得鍵盤陷阱、焦點由使用者控制、焦點移動要有意義。「指標輸入」五項：指標啟動可控制、提供簡單指標輸入、一致的指標取消、不依賴壓力、不依賴速度。「文字外觀」十一項，包含最小與加強兩組的版面、樣式、對比，以及可調整的文字間距、字級（至少放大到平台預設內文字級的 200%）、顏色，和「文字自訂在匯出或儲存時保留」。「圖片替代」四項：可偵測、裝飾圖隱藏、有替代文字、替代文字等效。
我對照 WCAG 2.2 的粗略對應如下，同樣是我的推論：放大 200%、文字間距調整、鍵盤陷阱、指標取消這幾項在 2.2 已有近似條文；比較沒有一對一對應的是「自訂快捷鍵要有文件」「自訂快捷鍵不得與瀏覽器或作業系統衝突」「文字自訂要在匯出或儲存時保留」「不依賴壓力」。草案也很誠實：對比的測量方式與多數數值仍是 @@ 待定，唯一寫死的數字就是 200%。所以現階段想拿 WCAG 3 當驗收門檻是做不到的，能做的是用它的結構提前整理自己的設計系統。
四、現在仍然要驗收的是 WCAG 2.2：一個可算的例子
WCAG 3 不會取代 2.2，所以今天出貨仍看 2.2。我重新確認了三條與元件尺寸最相關的條文：2.5.8 目標尺寸（最低）為 AA 級，目標至少 24 乘 24 CSS 像素；1.4.11 非文字對比要求與相鄰顏色至少 3:1；2.4.11 焦點不被遮蔽（最低）為 AA 級，取得鍵盤焦點的元件不得被作者建立的內容整個蓋住。
2.5.8 的間距例外是最常被誤讀的。一手文件（Understanding 頁）的條文是：小於 24 乘 24 的目標，若以各自邊界框中心畫一個直徑 24 像素的圓，這些圓不得與其他目標或其他小目標的圓相交，就算通過。文件自己的例子：6 顆 20 乘 20 的圖示鈕、間距 4 像素通過，零間距就失敗；16 像素高的按鈕單排通過，上下疊兩排而間距極小就失敗。照這個規則我自己推導出可用的速算：兩個小目標之間的中心距要 24 像素以上，所以邊長 s 像素的小圖示，彼此淨間距至少 24 − s，16 像素要 8 像素、20 像素要 4 像素，和文件例子吻合；小目標旁邊若是一個 24 以上的正常按鈕，只要小目標的圓不碰到那顆按鈕本身即可，淨間距至少 12 − s/2，16 像素是 4 像素、20 像素是 2 像素。這條推導的前提是目標中心對齊、不是膨脹熱區；若你用透明內距把可點區擴到 24 像素，直接算作一個 24 像素目標更單純。
🧠 記
- 一手與二手要分開。 青銅、白銀、黃金與「採用 APCA」在我讀到的一手頁面都找不到；現行的是核心要求加六個回報層級，對比算法明寫未決。
- 四個標籤是分診工具。 物理傷害、風險、障礙、摩擦依後果排序修復，我的歸類是推論，不是官方清單。
- 今天的驗收仍是 2.2。 24 乘 24 像素（AA）、非文字對比 3:1、焦點不被遮蔽（AA）。
- 小目標用圓規則算。 淨間距至少 24 − s，與 24 以上目標相鄰則至少 12 − s/2。
- 草案裡真正的新題目。 自訂快捷鍵要文件化且不衝突、文字自訂要能保留，這兩類在設計系統裡通常沒人負責。
- 昨天兩個更正。 Run 對話框原文確實沒談無障礙與 Ctrl+Shift+Enter；0.0038% 的分母是使用者，約 1,330 名。
邊界： 這些結論依賴 2026 年 9 月 10 日這一版草案；W3C 明說最終要求會被新增、合併與刪除，所以標籤歸類、層級定義都可能改。我對頁面的讀取經過摘要工具，字詞是否出現請自行搜尋確認。24 像素規則只涵蓋指標目標尺寸，不保證可用性：24 像素對手部顫抖或使用觸控的人仍然偏小，行動端的建議尺寸要另外依各平台指引評估，這一點我今天沒有查證各平台的現行數字，不寫死。法規面現在引用的仍是 WCAG 2.x，採不採用 WCAG 3 要看各地主管機關，我沒有查到任何已指定的日期。
✍️ 實踐
用 30 分鐘對自己產品的一個元件庫畫面做「後果分診」，不需要任何工具授權：
- 選一個畫面。 例如帶工具列的列表頁，圖示按鈕越多越好。
- 量尺寸與間距。 開瀏覽器開發者工具，逐顆量圖示按鈕的實際可點區（含 padding），低於 24 乘 24 的，量中心距，套用 24 − s 公式，不足者記成失敗。
- 量非文字對比。 取輸入框邊框、圖示、焦點環與背景的顏色，算對比，低於 3:1 的記下來。
- 測焦點遮蔽。 用 Tab 鍵走過整頁，看有沒有任何元件取得焦點時被固定頂欄、底部 Cookie 橫幅或聊天氣泡整個蓋住。
- 快捷鍵清查。 列出頁面上所有自訂快捷鍵，檢查是否有文件、是否與瀏覽器常用組合衝突。這是 WCAG 3 草案新增關心的項目。
- 貼標籤。 把前面五步所有失敗項各貼一個標籤：物理傷害、風險、障礙、摩擦，並依序排修復順序。
- 可證偽預測。 我預測：這個草案在今年底以前仍不會有確定的對比測量方式。驗證方法是打開 w3.org/TR/wcag-3.0 搜尋「contrast measure to be determined」，仍然出現就代表預測成立；若已換成具體算法名稱，我就是錯的，需要更正。
🔗 延伸學習
- WCAG 3 Introduction（W3C WAI） — 一手說明：核心要求、四個標籤的逐字定義、六個回報層級，以及明確表示不使用 Bronze/Silver/Gold。
- W3C Accessibility Guidelines (WCAG) 3.0 工作草案 — 2026 年 9 月 10 日版本全文，包含各指引的結果清單與
@@待定值。 - Crafting WCAG 3 for more accessible user experiences（W3C 部落格） — 9 月 25 日 WAI 主任說明新一致性模型的取向，並強調只達到 WCAG 2 的 A 與 AA 並不足夠。
- Understanding SC 2.5.8: Target Size (Minimum) — 圓規則的原文與 20 像素、16 像素的通過與失敗範例。
💬 問 AI
我在研究 W3C 2026-09-10 發布的 WCAG 3 工作草案,想把它用在設計系統稽核。請嚴格分成三區回答:「文件明說」「你查證到的」「你的推論」,三區不能混;不確定就直說,不要編造條文編號、連結或數字。
我已看到的主張(請當成待查證):
1. W3C WAI 的 WCAG 3 Introduction 說 WCAG 3 不使用 Bronze/Silver/Gold,而是核心要求加六個回報層級:第一層為物理傷害與風險,第二層加障礙,第三層加摩擦(=全部核心要求=符合),第四到六層加上數量待定的補充要求與斷言(第六層另含組織層面的斷言)。
2. 草案的對比測量方式尚未決定,內文以 @@ 占位;文字可放大到至少平台預設內文字級的 200% 是少數寫死的數字。
3. WCAG 2.2 的 2.5.8 目標尺寸(最低)為 AA、24×24 CSS 像素,間距例外是以 24 像素直徑圓不得相交判定;1.4.11 非文字對比 3:1;2.4.11 焦點不被遮蔽(最低)為 AA。
請做:
A. 逐點用 W3C 原文驗證 1–3,標示「查證成立／部分成立／查不到」並附連結。
B. 草案裡有哪些結果(outcome)在 WCAG 2.2 沒有近似條文?請列出你有根據的,並標明哪些只是推論。
C. 針對「自訂快捷鍵有文件且不衝突」與「文字自訂在匯出或儲存時保留」兩項,給我設計系統層級可執行的檢查方式。
D. 給我一份 8 項以內的「元件稽核後果分診表」,每項標明對應的標籤(物理傷害／風險／障礙／摩擦)與判準,並註明哪些歸類是你的推論。
不要給法律合規意見,僅限設計與規格層面的說明。