一個「完成」的網站，如何通過 AA 等級的無障礙修正

最近面對一個已經上線運作多年的官網系統。從使用者的角度來看，它其實沒有什麼明顯問題：功能齊全、畫面穩定，也一直有人在使用。但在實際維護、加功能，以及開始正式面對無障礙規範後，前端結構和一些互動細節，慢慢開始顯露出限制。

這次我們並不是重新設計網站，而是面對一個更現實的問題：在既有系統、既有設計語言都已經確定的情況下，怎麼把網站修到符合台灣 AA 等級無障礙標章（對應 WCAG 2.0）。

無障礙不單只是為了「給視障者用的網站」。在實務上，它處理的是很多人都可能遇到、但平常不一定會特別意識到的使用情境。有人只能用鍵盤操作，沒辦法精準使用滑鼠；有人把螢幕或字體放大到 200% 以上來閱讀；也有人使用讀報軟體，需要清楚的結構、標題層級和狀態提示。甚至只是年紀大了、眼睛容易疲勞、操作速度慢一點，這些都會直接影響使用網站的體驗。

無障礙真正要做的事情，是讓網站在這些情況下，依然看得懂、用得了、不會卡住。換個角度看，它其實是一種讓網站變得更穩定、更可靠，也更像是「真的給人用的系統」的方法。

✦ 從結構開始，而不是從檢測條文開始

原本的系統是 Servlet 架構，前後端綁得很緊。在這樣的基礎上，只要動到互動或操作方式，很容易牽一髮動全身。所以一開始，我們沒有急著對照檢測條文逐條修，而是先做了一個選擇：把結構整理清楚再說。

前端調整為 Vite + Vue + 原生 JavaScript，目的不是追求新技術，而是讓狀態、互動和事件來源可以被清楚掌握。後台資料則整理成 Headless CMS，讓前台顯示與資料管理分離，少一點為了資料結構而硬寫互動邏輯的情況。這些調整，表面上看不太出來「無障礙」，但它們是讓後續每一個修正能穩定進行的前提。

✦ 在既有設計語言下做無障礙，是另一種難度

如果是在新案階段，很多無障礙問題其實可以在設計時就先避開；但這次不是。這是一套已經被使用者習慣的設計語言，不論是視覺風格、配色層級，還是互動節奏，都不適合被大幅修改。

因此，很多時候我們面對的不是「怎麼寫程式」，而是先搞清楚哪些東西不能動。一旦決定設計語言必須完整保留，工程能走的路就會變得很窄，剩下的就是在那條路裡，一次一次嘗試。

以色彩對比為例，看起來只是數值調整，但每動一次，就會影響整體視覺層次。為了在安全的對比值與原本的設計感之間取得平衡，只能反覆測試不同組合，慢慢找到雙方都能接受的解法。

✦ 無障礙檢測，實際上是一段過程

真正進到人工檢測後，很快會發現一件事：無障礙並不是一次修完就結束。有些問題會在第一輪就被看到，例如鍵盤能不能操作、焦點是否清楚可辨；有些則是在後續抽測中才浮現，例如動態元件的狀態提示，或是在高倍率放大時的流動排版（Reflow）問題。

這些狀況通常不是單一頁面出錯，而是反映出整個系統在互動或結構上的不一致。所以每一次修正，我們都盡量避免只補一個洞，而是回頭確認，能不能形成整站一致、可預期的行為。

✦ 修完之後，留下的是什麼

修正完成後，網站沒有變得更華麗。比較明顯的改變是操作變得更直覺，互動行為更一致，也比較不容易讓人迷路。對鍵盤使用者與讀報工具來說，整體體驗也更穩定。

無障礙在這個階段，不再只是為了通過檢測，而是一個讓系統本身變得更成熟的過程。老實說，這次的難度真的不低，但在所有限制下把事情完成的那一刻，對執行者來說有一種很單純的爽快感。

網站得到的回報更甚於「通過檢測」本身，更好的介面，更好的瀏覽體驗，和更清楚的管理後台，我們不只是讓網站通過檢測，而是在尊重原始設計的前提下，把系統推到更成熟的狀態。