網頁應用程式的無障礙化已成為企業無法再忽視的課題。實踐包容性的道德責任，加上無障礙相關法規帶來的法律風險，意味著懂得如何打造並測試具無障礙性的產品，已是任何前端開發者必備的重要知識。

網頁內容無障礙指引（WCAG）制定了確保網站無論使用者有何種障礙都能使用的標準。大多數法規都以達到 AA 等級為目標，而這必須有意識地去理解這些標準並驗證其確實被落實，才有可能達成。

在開發流程的各個環節，都可以融入無障礙的考量：

• 做法：規劃與開發的方式
• 自動化：將檢測整合至自動化測試中
• 手動測試：稽核你的應用程式
• 超越工程範疇：正視程式碼以外的問題

做法

培養無障礙思維

第一步就是開始思考無障礙。透過閱讀 WCAG 文件來了解許多網頁常見的無障礙問題，成為推動無障礙議題的倡議者。當你開始深入了解，就會很快發現，原來有這麼多問題是你過去有幸從未需要面對的。

目標是確保無障礙在最早的階段就被納入考量。在規劃與需求梳理會議中提出無障礙相關的疑慮，並確保從一開始就將無障礙融入你的做法中。對於會讓整體無障礙性變差、增加無障礙技術債的變更，要勇於提出反對。僅僅依靠自動化測試來發現問題是遠遠不夠的。

重用現成解決方案

善用現成的公開或內部函式庫，是避免重複造輪子、從零開始解決常見無障礙問題的好方法。使用像 MUI 或 Chakra 這類元件框架，就能獲得已內建無障礙考量的常用元件。透過設計系統函式庫來共享內部元件，也能有效散播這些無障礙最佳實踐，讓你只需解決一次無障礙問題，就能在各團隊間共享成果。

只要可行，就盡量使用瀏覽器原生的元素，因為它們在實作時已針對廣泛的使用情境考量了無障礙性。你真的需要自己打造一個客製化的 <select> 或 <input type="date" /> 嗎？

如果你必須自行打造客製化元件，react-aria 提供了一組 React hooks，能為大多數常見元件加上無障礙支援與互動行為。

Storybook

Storybook 是用來獨立開發、撰寫文件與測試前端元件的絕佳工具。它也提供了幾個對於無障礙測試非常有用的功能。

透過 無障礙外掛，每個 story 都會由 axe 進行掃描，並在面板中顯示偵測到的問題。這能在開發元件時，針對潛在的無障礙問題提供即時回饋。

這個外掛還提供多種色彩濾鏡，可模擬介面在不同類型色盲使用者眼中的樣貌。你可以藉此輕鬆測試介面對於色盲使用者是否依然可用。

自動化

使用無障礙 Lint 規則

靜態分析可以捕捉到一些無障礙問題。透過像 eslint-plugin-jsx-a11y 這樣的套件來擴充你的 eslint 設定，就能偵測諸如 img 標籤缺少 alt 屬性，或是無效的 aria 屬性等問題。

這能在你撰寫 JSX 時，直接在 IDE 中提供即時回饋。

使用 Testing Library 撰寫單元測試

Testing Library 鼓勵開發者撰寫更不容易脆斷、對重構更具韌性的測試。與其使用類似 XPath 的選擇器，不如用與使用者相同的方式在頁面上尋找元素，這樣的查詢更不容易因設計變更或重構而失效。舉例來說，透過標籤為 Password 來尋找密碼輸入欄位，即使整個頁面設計大幅翻新，測試依然能正常運作；相較之下，若是透過 .password-input 這類 class 名稱來查詢，測試就很容易失效。

這種做法還有一個好處，就是能促使你打造更具無障礙性的元件。標籤與 aria 屬性讓你更容易撰寫出以語意化標籤為基礎、更具韌性的測試，同時也讓使用螢幕閱讀器的使用者更容易找到相同的元素。如果你發現很難使用 Testing Library 內建的選擇器來撰寫查詢，那很可能就是因為你的 UI 沒有遵循無障礙標準。

Testing Library 支援多種框架，包含 React、Angular、Svelte 以及 原生 DOM。

在單元與整合測試中使用 axe

axe 是一款用於網頁自動化無障礙測試的強大工具。它可以掃描頁面中的無障礙問題，並能與你已在自動化測試流程中使用的多種測試工具整合。

你可以將 axe 與 Playwright 和 Puppeteer 等自動化瀏覽器測試工具搭配使用。透過測試應用程式的每個頁面，你能在問題釋出給使用者前就及早發現無障礙缺陷。如果是將其導入既有專案，你也可以利用快照測試來建立現有無障礙問題的基準線，確保在新增功能時不會讓情況惡化。

透過 jest-axe，你可以在 JSDOM 環境中使用 axe 來撰寫偵測無障礙問題的單元測試。這對於提早取得回饋、而不需要等待完整整合測試的結果非常有幫助。

手動測試

平均而言，像 axe 這類自動化測試工具只能捕捉約 60% 的無障礙問題。舉例來說，自動化工具可以偵測 <img /> 元素上是否有 alt 屬性，卻無法判斷其中的文字是否真的是對圖片有意義的描述。正因如此，手動測試也應該納入你的無障礙策略中。

像 VPAT 這類文件可用來指引你的手動測試，並可與外部使用者分享，以證明你的應用程式符合無障礙標準。定期手動評估與檢視無障礙性，有助於發現問題、長期追蹤無障礙狀況，同時也能讓使用者安心，知道你正將無障礙列為優先要務。

讓真正有障礙的使用者來測試你的網站，是了解系統實際無障礙程度的最佳方式。試著使用螢幕閱讀器或在不使用滑鼠的情況下操作你的網站，來感受它真正的可用性如何。

超越工程範疇

僅靠工程上的最佳實踐無法解決所有的無障礙問題——整個組織都必須共同參與。

設計師需要從最初的 UX 與 UI 設計階段就將無障礙納入考量。像 Figma 這樣的工具就提供了無障礙相關外掛整合，能幫助確保設計稿在製作時就已考慮到無障礙性。

任何產製網頁內容的人都需要意識到無障礙及其重要性。你的 CMS 或許會要求為圖片提供 alt 文字，但每個人都了解這個欄位的重要性，以及如何為使用螢幕閱讀器的人撰寫實用的說明文字嗎？所有製作的影片內容是否都包含了字幕？

透過像是 員工資源團體（ERGs）或跨職能工作小組等形式，可以幫助在整個組織中推動並宣導無障礙的重要性。從辦公環境的配置、內部系統到對外的網頁應用程式，無障礙都需要被納入考量，而要建立一種將這些需求視為優先的文化，就需要有人挺身倡議、積極推動。