Day 06 · W1 · 無障礙線 · 難度 ★★☆☆☆

本系列由 AI 協作撰寫。 內容、技術判斷、程式碼由 light-design 數位顧問團隊與 Claude 共同產出，最終由作者驗證後 publish。完整協作模式與把關方式見 Day 01。

Day 5 結尾我說：算出來要補 109 條，後來發現這個數字是錯的。

今天講錯在哪。

台灣的網站無障礙規範要換版了，2026 年 11 月 30 日起實施新版。舊版對齊 WCAG 2.1，新版對齊 2.2。我要把工具接上新碼表，第一件事是估工作量，於是我列了「新碼表有、我們沒有」的清單：

115.11 碼表        246 碼
a11y-moda 規則     146 條
它有、我們沒有的     109 條   ← 我一開始以為這是遷移量

109 這個數字沒有算錯，但它回答的不是我問的問題。

一句話主軸：換版的成本是「新增的」，不是「還沒做的」。 那份清單裡混著你本來就欠的債，兩者算在一起，會把十五倍的工作量報給老闆。

先講最多人想問的：我的標章會不會作廢

不會。

2026 年 11 月 29 日（含）以前取得的無障礙標章，三年效期照算。 同一天起停止受理舊版申請，新案改用新版檢測。

所以這篇談的是「工具跟規範怎麼接軌」，不是「大家要重新送件」。先把這句放在前面，免得後面的數字被誤讀成災難。

兩版的骨架差異：

表面上只多 6 碼。 實際結構是 222 條沿用、24 條新增、18 條移除或改名。

碼號怎麼讀，換版時特別有用

碼長這樣：HM1130103C。這串東西在規範裡叫檢測碼，在我們工具的輸出裡是 rule_id 那一欄，同一個東西。

HM        主題碼   HM / GN / CS / AR / FA / SC / ME
1130103   序號     中間帶著對應的 WCAG 成功準則（1.3.1）
C         後綴     C = 機器可檢 · E = 需人工判斷

以現行版 240 碼來說，GN 130 條最多，其次 HM 55、CS 34、FA 14，AR／SC／ME 加起來 7 條。

實際讀一次比較快。HM1130103C 是「HM 主題、對應 1.3.1、機器可檢」，內容是表單控制元件要有標籤；GN1210100E 是「GN 主題、對應 2.1.1、需人工判斷」，內容是滑鼠事件要有鍵盤等效。代號本身就是一句摘要，看到編號就知道它在管哪個準則、機器判不判得了。

重點在中間那串數字帶著 WCAG 準則編號。 這代表：只要那條檢查在 WCAG 換了準則，它的代號就會跟著變。 後面所有的位移都是這一條規則造成的。

至於「WCAG 條文 → MODA 碼表 → 工具自己的門檻」這三層的關係，Day 5 講過了，這裡不重講。

我算錯的那個數字

回到 109。

我原本以為那是遷移量，實際拆開才發現不是：

那 102 條在換版之前就欠著了。新規範上路不上路，它們都在那裡。把它們算進「換版成本」，等於把整個 backlog 掛在一件跟它無關的事情上。

為什麼會欠這麼多？因為這套工具從一開始就沒打算做完整份碼表。碼表裡有很多條要看畫面、聽報讀、或者實際把一整段流程走一遍才有答案，那不是機器判得了的。我們挑的是機器判得準、而且判錯代價低的那些先做。所以 102 這個數字與其說是欠債，不如說是設計上就沒有納入的部分，只是它在那份清單裡看起來跟真正的待辦長得一模一樣。

新增的 24 碼裡，有 2 碼是碼表自己的格式說明列（不是可檢測規則），扣掉之後真規則 22 條，我們已經完成 15、剩 7。

驗算：22 新增 − 15 已完成 = 7
      102 舊債 + 7 新工作 = 109

同一個 109，拆開之後意義完全不同。左邊那塊不該進換版預算。

教訓濃縮成一句：算遷移量要問「這條是因為換版才出現的嗎」，不是「我有沒有做」。

18 條被移除的碼，我一條一條追完了

這是最花時間的部分，也是最不能偷懶的部分。

我第一個念頭是自動配對：舊碼跟新碼如果對到同一個 WCAG 準則，就當成同一條。這個方法不可靠。

反例就在手上：GN1210101E 跟 FA1210102E 同屬 2.1.1，但一條查的是「tabindex=-1 把元件移出 Tab 序」，另一條查的是「指標專屬事件導致鍵盤失效」。同一個準則，兩件完全不同的事。準則相同不等於檢查相同，只能逐條讀規則邏輯。

讀完之後，18 條分成三種下場：

三種下場的判定全部靠讀規則邏輯，不是靠準則編號比對。

留下來當 legacy 的那 4 條是 GN1210101E、GN1240301E、HM1110108E、HM1130108E。新碼表沒有它們的位置，但檢查本身還有效 —— 刪掉等於自己把覆蓋率砍一塊。

那 11 條「從未實作」也不是白撿的好消息。它們之所以沒被實作，多半跟前面那 102 條同一個原因：判不準，或者判錯的代價太高。換版把它們從碼表上拿掉，只是讓帳面乾淨了一點，不代表那些檢查的需求消失了。碼表移除一條，不等於那件事不用做。

這裡要講清楚：以上分類是我們讀規則邏輯得出的判斷，不是官方判定。 官方沒有逐條對照表，我們的結論可能有錯。

拿一個已知答案回頭驗自己的方法

11 條「從未實作」裡有一條 HM1410100C，我判它是真的廢掉了，不是搬到別的地方。

驗證方式不是再讀一次規則，是去查它對應的 WCAG 準則：4.1.1 Parsing 在 WCAG 2.2 被正式移除，W3C 文件裡寫得明明白白。

我們的對帳結論跟 W3C 的公告對上了。

這件事的價值不在那一條規則，在於它證明整套 diff 流程是可信的。我原本擔心逐條讀邏輯會不會讀出一堆自以為是的判斷，直到這一條對上才安心 —— 這是唯一一條有外部答案可以核對的，而它核對成功。

比喻一下：這像在算一長串帳的時候，發現其中一筆剛好有銀行對帳單。那一筆對得上，不代表整串都對，但至少代表你的加法沒有系統性偏差。

改名不只是換代號

3 條改名裡，有一條要特別講：

GN2141100E  →  GN3241302E
準則 1.4.11 → 2.4.13
等級   AA   →   AAA

看起來像「這條要求放寬了」。不是。

WCAG 2.2 把「焦點」這件事拆成四條：

「必須有可見的焦點指示」從來沒有變成選配 —— 那是 2.4.7，WCAG 2.1 和 2.2 都是 AA。我們那條規則只是被碼表挪到了 2.4.13 這個更嚴格的位置，跟著變成 AAA。

AA 的覆蓋也沒有掉，CS2240700E 跟 FA2240701E（都是 2.4.7、都是 AA）接住了。

實際影響只有兩個：跑 --level AA 時那條不再執行；拿舊報告去搜舊代號會找不到，但檢查本身還在跑。

這是碼表位移，不是義務降級。兩件事差很多，寫報告的時候不能混。

剩下那 7 條為什麼慢

不是因為難懂，是因為要動探測器。

CS3241300E  FA1210401E  FA2250700E  GN1320600E
GN1330700E  GN3210301E  GN3330900E

多數卡在同一個地方：現在的焦點探測只拿得到「有沒有可見框線」這一個布林值，拿不到框線的幾何與顏色，所以算不出面積跟對比。焦點外觀那幾條要等這個補完。另外兩條要新的探測器（畫面重排、拖曳替代），也不是順手能做的。

慢的原因寫出來，是因為進度表上的「未完成」如果不附理由，看起來就只是沒做。

今天的重點

• 「還沒做的」不等於「換版要做的」。 109 條裡有 102 條是舊債，真正因換版而生的只有 7 條
• 準則相同不等於檢查相同，自動配對會出錯，只能逐條讀邏輯
• 拿一個有外部答案的項目回頭驗方法，比宣稱自己很仔細有用
• 改名可能同時換準則與等級，但那是碼表位移，不是義務放寬
• 既有標章三年效期不受換版影響，11/29 前拿到的照算

明天 Day 7：碼表是別人定的，但工具裡那些魔術數字是我拍板的 —— 我抽了六個出來，順便講為什麼這種工具要開源。