專案動機
隨著資訊取得、公共服務與日常活動逐步轉移至網站及行動應用程式，數位介面是否能被順利理解與操作，開始影響每個人參與數位生活的機會。無障礙也從特定情境的補充設計，逐漸成為數位產品必須具備的基本條件。
國際間普遍採用 W3C 制定的 WCAG 作為設計與檢核依據，從資訊感知、介面操作、內容理解與技術相容等方向，定義數位內容應具備的基本條件。
無障礙設計元件庫
任何人都能快速上手，無痛使用的無障礙設計
設計目標
視覺上清楚的介面，不一定能被輔助工具正確理解。缺乏語意標註時，螢幕閱讀器可能無法說明元件用途。報讀順序與畫面結構不一致時，用戶難以建立資訊脈絡。Focus 狀態、錯誤訊息與點擊範圍缺乏規範，也會增加定位和操作的困難。
- 01
統一設計規範
建立元件互動狀態的共通原則，減少跨專案的設計差異。
- 02
強化操作辨識
規劃各式提示與狀態回饋，讓介面資訊容易理解。
- 03
提升設計與開發效率
整合無障礙規則至元件庫，降低交付與開發成本。
建立報讀架構，使資訊順序容易理解
依照畫面的資訊層級規劃報讀順序，每個頁面僅設定一個主要標題，並透過前端語意協助閱讀器辨識內容結構。
區分資訊重要性，精確報讀內容
針對重複資訊、裝飾圖片與非必要內容，另外定義省略報讀的原則，避免過多訊息干擾主要操作。彈窗開啟或後端檢核錯誤時，Focus 會移至需要優先處理的區塊，使重要訊息能被立即發現。
重複內容（如：廣告）
同一內容若已由圖片替代文字完整說明，可略過重複資訊，避免螢幕閱讀器反覆報讀。
輪播圖片或卡片
動態變化內容會影響報讀流暢度，可讓用戶略過這些區塊，進入下一區塊。
非必要動態／特效
若有自動播放的動畫或視覺效果，可提供略過或停用功能。
強化動態出現的提示訊息
針對彈窗、表單錯誤與動態更新內容，定義 Focus 的移動規則。彈窗出現時，Focus 會立即移入並報讀內容，關閉後則返回原本的操作位置，避免用戶失去操作脈絡。當頁面載入新內容或後端檢核錯誤時，Focus 也會優先移至對應區塊，讓重要訊息能被即時發現，減少反覆尋找問題位置的負擔。
動態元件
彈窗出現時，Focus 隨即移至該處報讀。
欄位檢核回饋
欄位後端檢核錯誤時，優先報讀此區塊。
集中顯示錯誤，快速找到問題欄位
後端檢核完成後，將各欄位的錯誤集中顯示於頁面上方，並提供前往對應欄位的連結，讓用戶先掌握需要修正的內容，再依序完成處理。
依介面結構報讀，建立清晰的操作脈絡
以用戶進入頁面後的理解順序為基礎，規劃介面的報讀路徑。從頁面標題與返回按鈕開始，接續重要提示與主要內容，最後再進入輔助操作及功能導覽，讓用戶能先確認所在位置，再依序掌握重點資訊與完成操作，避免報讀內容與畫面脈絡產生落差。
01－標題或頁面名稱（H1）
App Header 通常為標題或頁面名稱，標題／H1 優先報讀，方便用戶確認位置。
02－返回按鈕（Back Button）
用戶點擊返回按鈕時報讀「返回前一頁名稱」。
03－導覽頁籤（Tab）／通知或提示（Alert）
遵循左至右、上至下報讀規則。
04－主要內容（Main）
遵循左至右、上至下報讀規則。
05－輔助操作（Button、Link）
輔助操作通常與主要內容相關，接續於 Main 區塊後報讀，例如臺幣轉帳頁的「確認轉帳（下一步）」按鈕。
06－功能導覽（Navigation Bar）
底部導覽列讓用戶了解可切換的主要頁面。
定義元件狀態與語意規則
整理元件在各種操作時的呈現方式，使設計師清楚掌握製作畫面時的規範。同時提供前端語法與使用情境建議，協助工程師正確實作功能及報讀方式，減少設計規格與實際成果間的落差。
統一開發規格，提升落地準確度
以登入頁為例，依照實際操作順序為介面元素編號，並逐項定義螢幕閱讀器的報讀名稱、元件角色、狀態與觸發行為。開發人員可直接對照畫面標註與規格表，確認每個元素應如何被辨識及操作，使共用規範能正確落實於單一頁面，也為後續測試與驗收建立明確依據。
專案成果
無障礙元件庫將分散的需求整理為共用元件與頁面標註方式。設計端能依照一致的狀態建立介面，開發端也能從報讀內容、操作行為與前端語法掌握實作方式，讓規格能從設計稿延續至開發與驗收，減少重複確認及成果落差。
