Day 28 · W4 · 無障礙線 · 難度 ★★☆☆☆

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

Day 02 講過第一輪 9 條的根因，七條規則檔早就存在，只是給了綠燈。今天把鏡頭拉遠，講完整的 26 天：4 月 30 日送件，中間被打回三次，5 月 26 日核發。三輪意見，工具都在收到當天先動，網站永遠是第二個改的。

一句話主軸：工具 0 fail 不等於審查 0 意見，中間的落差不是恥辱，是一份可以照著改的清單。

26 天，三輪，一張表

先把全程攤開：

5/12  收第一輪 9 條   →  同日發 0.4.0～0.4.3  →  改站 8 天  →  5/20 回函
5/21  收第二輪 2 條   →  同日發 0.4.4          →  改站 1 天  →  5/22 回函
5/25  收第三輪 1 條   →  同日發 0.4.5          →  同日改站  →  同日回函
5/26  核發 AAA 標章（代碼 20260430012703）

三輪的節奏一樣：意見進來，工具當天先動，網站接著改。改站花的時間逐輪變短，8 天、1 天、當天。

原本以為第一輪把 9 條全修完，這件事就結束了。才發現送出去的每一輪回函，換回來的不是「通過」或「不通過」兩種答案，是新的一批意見；直到第三輪只剩 1 條，才真的看到終點。

第一輪：9 條，同一天四個版本

Day 02 已經拆過根因分類，這裡只接續時間軸。5 月 12 日收到 9 條意見那天，工具連發 0.4.0、0.4.1、0.4.2、0.4.3 四個版本，不是一次補完，是修一個發現另一個：焦點探針模擬了開選單，但 getComputedStyle 第二個參數傳了一個不存在的偽類別；改對之後，換成單頁掃描指令沒把深色模式旗標接到探針層。改到 0.4.3 那一版，9 條裡工具重新掃得到 6 條。花 8 天把 9 條全部改完網站，5 月 20 日回函。

第二輪：意見寫在哪一條，跟要求來自哪裡，是兩件事

5 月 21 日收到第二輪，通知寫的是限期 45 天內改善，不是重新排隊送件，改完直接回函即可。這一輪只剩 2 條，但比第一輪難拆。

第一條是焦點可見（CS2240700E）：跳到主要內容的定位點，審查意見說看不出跳到哪。工具那時的判定只查有沒有 outline，是否存在，不查明不明顯。網站確實有框線，只是不夠醒目，這是規則寬鬆的問題，不是規則錯的問題。網站端的修法很直接：主要內容區加上 tabindex="-1"，取得焦點時套一圈更粗、對比更高的外框，肉眼一眼能看到。這個修法被接受了，第三輪意見裡沒有再提這一條。但工具的判定邏輯原地沒動，這條 0.4.4 沒有補上，量化到「框線對比夠不夠」要等到昨天發布的 0.6.0，那條規則叫 CS3241300E（Day 27 提過）。同一條意見，網站先動，工具晚了將近四個月，這正是標題的例外，寫出來比省略掉誠實。

這四個月不是空白。6 月 18 日工具發 0.5.0，一次新增 13 條規則，對齊 MODA 年底（11 月 30 日）就要生效的新規範，規則總數 133 → 146（Day 22 有整篇）。力氣先給了那一波，CS2240700E 的量化沒排上，一直放到這次系列寫作才補。今天如果重新掃描，可能會抓到新的 fail，那是規則新增後才問得到的問題（Day 22 那 33 個就是這樣來的），不是網站退步，也不是不符合送驗當時的規範。標章本身不受影響，這張是舊規範核發的，效期照舊三年。

第二條掛在「多種方式」（GN1240500E）名下，意見裡寫了三件事：提供導覽方式、提供快捷鍵、提供 Firefox 的操作說明。前一件工具早就判定通過，網站有主選單也有導覽頁，WCAG 對「多種方式」的判準本來就是任選其二即達標。後兩件要求快捷鍵跟瀏覽器層級的操作說明，工具當時完全沒有對應的檢查項。意見引用的成功準則，跟真正要求的內容，是兩件不同的事，同一條意見裡混了國際準則跟在地規範，這是送審這類流程常有的狀況，中性看待即可。

工具當天補了兩件事：一條新規則檢查快捷鍵跟對應的錨點是否有效，一條檢查導覽頁有沒有列出快捷鍵表跟瀏覽器操作說明；另外修了爬蟲，讓它會主動探測導覽頁這種不在 sitemap.xml 裡、但確實存在的頁面。原因很簡單，sitemap.xml 是給搜尋引擎看的內容清單，導覽頁是給人看的網站地圖，兩者剛好互不列對方。網站那邊，主選單觸發鈕跟主要內容區各配一組快捷鍵，導覽頁補上對照表跟三種瀏覽器的按法。發布 0.4.4，隔天改完網站、送回函。這一輪，工具補上了兩條裡的一條。

想過申訴，工具判斷「多種方式」通過的邏輯站得住腳。沒有申訴：改站一天能做完，申訴要多等一兩週，而且不一定申訴得下來，時間才是真正稀缺的資源。

第三輪：寫工具的人，也犯了工具抓得到的錯

5 月 25 日只剩 1 條。快捷鍵按下去，螢幕報讀唸出來的文字，跟導覽頁寫的說明不一樣。三組快捷鍵裡，開選單那組唸出來的字比導覽頁的說明短了一截，跳到主要內容那組元件上完全沒有可唸的文字，搜尋那組兩邊用詞不同。元件上的標籤跟導覽頁的說明各自合理，只是沒人對過兩邊是不是同一句話。

這條當天就補了：規則多讀一步，把導覽頁的對照表跟頁面上快捷鍵元件的可存取名稱抓出來，逐字比對，不一致直接判定不通過，而不是列成待人工複查的項目，因為意見講得很明確，「需要相同」不是「建議相同」。同一天發 0.4.5、改網站、送回函。5 月 26 日，核發。

這條最值得記的不是修法本身，是它多小。 三個輔助函式，不到一天，但以後任何用這個工具的人，寫元件時再也不用自己記得回頭跟導覽頁對一次文字，都不會再犯同一個錯。

我們付的，其實不是規費

規費 0，沒有請無障礙顧問，自己動手加上工具輔助。26 天裡真正花在動手上的大約 10 天，第一輪改站 8 天、第二三輪改站加起來 2 天；剩下約 16 天是等審查意見回來的時間，這段等的時候連要改什麼都不知道，Day 02 已經講過那種空等。真正付出的成本，是每次回函前那幾天，一邊拆解工具為什麼沒看到、一邊補規則。

如果你也要送這一類的檢測：送件前先拿工具自己掃一遍，能先擋掉的意見就不用等一輪；每一輪回函把改了什麼寫清楚，減少來回；意見文字進來先拆成兩層，它引的是哪一條準則、它實際要求的內容是不是真的來自那一條，兩者不一定是同一件事。改善期限內的意見不用重新排隊，照著清單改完直接回函，比爭論意見合不合理省下的時間更多。

9 → 2 → 1 → 0

每一輪先付出的都是工具的修改，抓得到的比例逐輪墊高，但從沒有哪一輪是全補上，這條線沒有終點，只有下一輪。

Day 01 答應的四樣東西裡，AAA 標章是這一樣。今天收的不是「拿到了」三個字，是拿到之前那三輪、每輪都先改工具再改網站的紀律，以及那條沒補上的例外一起收進來，不挑好看的講。

今天的重點

• 26 天，三輪，一張表：4/30 送件，5/12、5/21、5/25 三次意見，5/26 核發。工具永遠在收到意見的當天先動，網站接著改。
• 意見引的準則跟真正要求的內容，是兩件事：第二輪一條意見裡混了國際準則跟在地規範，拆開看才知道要補什麼。
• 誠實講一條沒補上的：焦點可見那條規則太寬鬆的問題，0.4.4 沒解決，量化對比要等到 0.6.0 的 CS3241300E。
• 修得最小的一條反而最徹底：第三輪三個輔助函式，把「文字要一致」從人工複查變成機器判定。
• 付出的不是規費：是 26 天裡大約 10 天的動手時間，跟每一輪回函前的那段拆解。

明天 Day 29：工具說「我不知道」的時候，你該怎麼辦。