無障礙設計 WCAG 是什麼？
WCAG 是網站無障礙設計與檢測的國際標準，用來判斷網頁內容是否能被不同能力、裝置與輔助科技順利使用。
WCAG 全名是 Web Content Accessibility Guidelines，由 W3C WAI 制定。它處理的不是單純的視覺美化，而是網站內容、互動流程與程式結構是否讓更多人可以讀取、理解並完成任務。
WCAG 是網站無障礙的國際標準
依照 W3C WAI 的說明，WCAG 2 涵蓋 WCAG 2.0、2.1 與 2.2，目標是提供一套跨國可引用的網站無障礙標準。2026 年撰寫網站規格時，實務上應優先參照 WCAG 2.2。
它可以用在三個地方：設計階段確認元件是否容易使用，開發階段確認語意與互動是否正確，驗收階段確認頁面是否達到可測試的成功準則。
它不是單一檢查項目，而是一套設計與驗收框架
很多網站把無障礙設計當成上線前跑一次工具分數，這是常見誤判。WCAG 標準本身是一套框架，包含原則、指引、成功準則與符合等級。
好的專案會把 WCAG 放進設計系統、前端元件、內容編輯與 QA 流程，而不只是在最後補 alt text 或修幾個顏色對比。
POUR 四大原則：可感知、可操作、可理解、穩健
POUR 是理解 WCAG 的四大原則，分別是可感知、可操作、可理解與穩健，用來檢查使用者能不能接收資訊、操作介面、理解流程，並透過不同工具正確使用網站。
| POUR 原則 | 白話意思 | 常見檢查方向 |
|---|---|---|
| 可感知 | 資訊要能被看見、聽見或用輔助科技讀到 | 替代文字、字幕、對比度、文字結構 |
| 可操作 | 主要功能不能只依賴滑鼠或單一手勢 | 鍵盤操作、焦點順序、點擊範圍、拖曳替代 |
| 可理解 | 介面文字、流程與錯誤提示要清楚 | 表單標籤、錯誤訊息、一致導覽、按鈕命名 |
| 穩健 | 不同瀏覽器、裝置與輔助科技都能解析 | 語意 HTML、ARIA 使用、元件狀態、程式結構 |
可感知：資訊不能只靠顏色、圖片或聲音傳達
如果錯誤欄位只用紅框標示，色弱使用者可能看不出差異；如果促銷資訊只放在圖片裡，螢幕閱讀器也無法讀到。可感知要求資訊要有可替代的接收方式。
可操作：不用滑鼠也能完成主要流程
網站無障礙最容易被忽略的問題，常出現在選單、彈窗、輪播與表單。使用者應該可以只用鍵盤完成搜尋、填寫、送出與關閉視窗等主要流程。
可理解：介面、文字與錯誤提示要讓人看得懂
「格式錯誤」不是好的表單回饋。比較好的寫法是直接指出問題，例如「手機號碼需為 10 碼，開頭為 09」。可理解不只看文案，也看流程是否可預期。
穩健：不同裝置與輔助科技都能正確讀取
穩健通常牽涉前端結構。按鈕就用 button，連結就用 a，標題依照內容層級排列。ARIA 可以補強語意，但不應取代原生 HTML。
WCAG A、AA、AAA 等級差在哪？台灣網站通常該做到哪一級？
WCAG 有 A、AA、AAA 三個符合等級。台灣企業網站若要兼顧可行性與品質，通常應以 WCAG AA 作為主要目標，新建或改版網站則建議用 WCAG 2.2 AA 思維規劃。
| 等級 | 定位 | 適合情境 | 實務判斷 |
|---|---|---|---|
| A | 最低可用門檻 | 避免最基本阻礙 | 只能當起點，不適合當成熟網站的最終目標 |
| AA | 多數網站的務實目標 | 企業官網、電商、會員系統、公共資訊頁 | 最適合放進改版規格與專案驗收 |
| AAA | 更高標準 | 特定內容、重要流程、教育或公共服務重點頁 | 可選擇性追求，不宜要求全站每種內容全面達成 |
A：最低可用門檻
A 等級處理最基本的阻礙，例如圖片替代文字、鍵盤可操作、頁面標題與表單標籤。若 A 都沒達到，部分使用者可能根本無法完成任務。
AA：多數網站最實務的目標
AA 會要求更好的對比、焦點、錯誤提示與一致性。以台灣企業網站來看，AA 最適合成為設計規格、前端開發與專案驗收的共同語言。
AAA：高標準，但不一定適合所有內容全面達成
AAA 對內容、互動與呈現要求更高。有些項目可以用在重點頁面，例如關鍵服務流程或長者常用功能，但全面要求 AAA 可能造成成本與內容限制不成比例。
2026 年建議：新建或改版網站優先以 WCAG 2.2 AA 思維規劃
W3C 鼓勵使用最新版 WCAG。WCAG 3.0 在 2026 年仍屬 Working Draft，適合作為未來趨勢觀察，不適合作為現階段驗收依據。
WCAG 2.2 對 UI 設計多了哪些實務提醒？
WCAG 2.2 新增的成功準則更貼近現代介面，特別提醒焦點可見、拖曳替代、觸控目標、重複輸入與登入驗證流程。
W3C WAI 說明 WCAG 2.2 新增 9 項成功準則。對設計師來說，這些更新不只是規範名詞，而是直接影響 sticky header、Cookie banner、拖曳排序、手機按鈕與會員登入。
焦點不能被浮層、固定導覽或 Cookie banner 擋住
鍵盤焦點移到某個元件時，使用者至少要看得到焦點所在。固定底部橫幅、聊天泡泡或 Cookie banner 若遮住焦點，就會讓鍵盤使用者失去方向。
拖曳操作要有替代方式
如果介面需要拖曳排序、拖放檔案或移動卡片，應提供按鈕、選單或鍵盤可操作的替代方法。只靠拖曳會排除無法精準操作滑鼠或觸控的人。
觸控目標不能小到難以點選
手機版常見問題是文字連結太密、icon 太小、關閉按鈕靠得太近。觸控目標要讓手指、觸控筆與動作不穩的使用者都能順利操作。
登入與驗證流程不能只靠高記憶負擔
要求使用者記住複雜字串、解謎或只靠視覺辨識，會增加可近用風險。較好的做法是允許密碼管理工具、一次性連結、可讀的錯誤提示與替代驗證方式。
WCAG 實務檢查重點：表單、按鈕、圖片、選單與影音
WCAG 實務檢查要從使用者真正會操作的元件開始，包括表單、按鈕、連結、圖片、導覽選單、影音與動畫。
| 元件 | 常見問題 | 檢查方向 |
|---|---|---|
| 表單 | 沒有 label，錯誤訊息不清楚 | 欄位名稱、必填提示、錯誤說明、aria-describedby |
| 按鈕與連結 | 文字只寫更多、送出、點我 | 動作明確、範圍足夠、狀態可辨識 |
| 圖片 | 裝飾圖與資訊圖都亂填 alt | 依內容用途決定替代文字 |
| 選單 | 鍵盤進得去但出不來 | 焦點順序、開關狀態、Esc 關閉 |
| 影音 | 只有聲音或只有畫面提示 | 字幕、逐字稿、非聲音提示 |
| 動畫 | 自動播放、閃爍、無法降低動態 | 暫停控制、reduced motion、避免閃爍 |
表單：label、必填提示、錯誤訊息與 aria-describedby
表單是無障礙網頁最容易出錯的地方。before：欄位 placeholder 寫「請輸入」，錯誤只顯示紅框。after：label 寫「電子信箱」，錯誤訊息寫「請輸入有效的電子信箱格式」，並讓輔助科技能讀到錯誤說明。
按鈕與連結：文字要說明動作，點擊範圍要足夠
按鈕文字要讓人知道按下後會發生什麼事。before：「了解更多」。after：「查看無障礙檢查項目」。如果同頁有多個相同文字連結，螢幕閱讀器使用者很難判斷差異。
圖片：裝飾圖與資訊圖的 alt 寫法不同
裝飾圖可以留空替代文字，避免干擾閱讀。資訊圖則要說出圖中重點，例如「WCAG 分為 A、AA、AAA 三個符合等級」。不要把 alt 寫成檔名或關鍵字堆疊。
導覽選單：鍵盤焦點順序要合理
選單要能用 Tab 進入，用方向鍵或 Tab 移動，用 Enter 或 Space 開啟，必要時用 Esc 關閉。焦點順序應符合畫面與內容邏輯。
影音內容：字幕、逐字稿與聲音之外的提示
有口白的影片應提供字幕或逐字稿；只有聲音提示的互動，例如成功音效，也要有畫面文字或狀態訊息。這對聽障使用者、靜音環境與吵雜環境都重要。
動畫與閃爍：支援 prefers-reduced-motion
動畫可以保留，但重要資訊不能只靠動態傳達。對容易暈眩或需要降低動態的人，網站應尊重 prefers-reduced-motion，減少大幅度位移與連續閃爍。
無障礙設計不是犧牲美感，而是降低使用阻力
無障礙設計的核心是降低使用阻力，讓更多人能看清楚、找得到、點得到、讀得懂，並完成原本就該完成的任務。
我看過不少介面失敗不是因為不漂亮，而是太依賴低對比灰字、隱形焦點、過小 icon 與只有顏色的狀態提示。這些設計在提案頁看起來乾淨，上線後卻讓使用者卡住。
好看的介面也可以有清楚焦點與足夠對比
焦點樣式不必做成粗糙外框，可以用明確邊線、底色變化、陰影與狀態文字處理。重點是使用者一眼看得出目前在哪裡，而不是讓焦點在視覺稿裡消失。
色彩、動畫、微互動都要留下替代線索
錯誤狀態除了紅色，也應有文字；成功狀態除了綠色，也應有訊息；動畫除了移動，也應有靜態結果。成熟的 UI 設計會讓視覺語言服務可用性。
台灣企業導入 WCAG 的流程：從盤點到驗收
台灣企業導入 WCAG 應從高流量、高轉換與高風險頁面開始，先訂等級，再把設計、開發、內容與測試納入同一套驗收流程。
Step 1：先盤點高流量、高轉換、高風險頁面
優先處理首頁、服務頁、聯絡表單、會員登入、購物車、結帳、搜尋結果與重要文章。預算有限時，先修真正影響任務完成的頁面。
Step 2：決定目標等級與驗收標準
多數企業網站可把 WCAG AA 作為主目標，並明確寫進設計規格、開發票卡與 QA 清單。只寫「符合無障礙」太模糊，驗收時容易各說各話。
Step 3：設計階段先處理色彩、焦點、表單與元件規格
設計系統應定義文字對比、按鈕狀態、錯誤訊息、焦點樣式、表單輔助文字與元件尺寸。這些越早決定，後面越少返工。
Step 4：前端開發用語意 HTML 優先，ARIA 輔助
原生 HTML 能解決的事，通常不需要先加 ARIA。工程師應確保標題、按鈕、表單、狀態訊息與彈窗都有正確語意與鍵盤行為。
Step 5：用自動工具加人工測試驗收
Lighthouse、WAVE、axe 可以抓出部分問題，但無法完整判斷文案是否清楚、流程是否合理、螢幕閱讀器讀起來是否自然。驗收一定要包含人工情境測試。
Step 6：上線後把無障礙納入維護流程
每次新增頁面、調整元件、放上影片或改表單，都可能產生新的無障礙問題。無障礙不是一次性專案，應進入內容發布與版本回歸測試。
設計師、工程師、內容編輯、PM / QA 各自要負責什麼？
WCAG 導入需要團隊分工。設計師負責元件與狀態，工程師負責語意與操作，內容編輯負責資訊結構，PM 與 QA 負責優先順序與驗收。
| 角色 | 主要責任 | 交付物 |
|---|---|---|
| UI/UX 設計師 | 對比、焦點、狀態、表單、錯誤提示 | 設計系統與元件規格 |
| 前端工程師 | 語意 HTML、鍵盤操作、ARIA、狀態管理 | 可操作元件與可測試頁面 |
| 內容編輯 | 標題層級、連結文字、alt text、字幕 | 清楚可讀的內容結構 |
| PM / QA | 範圍排序、驗收案例、回歸測試 | 測試清單與修正追蹤 |
UI/UX 設計師：元件狀態、對比、焦點、錯誤訊息
設計師要把 hover、focus、disabled、error、success 等狀態畫完整。只交靜態畫面，前端通常會自行補狀態，品質就會不穩。
前端工程師：語意標籤、鍵盤操作、ARIA、狀態管理
工程師要確認元件可以被鍵盤操作，狀態改變能被輔助科技理解。ARIA 的價值在補足語意，不在把所有 div 包成假按鈕。
內容編輯：標題層級、連結文字、alt text、字幕
內容編輯決定使用者是否能快速理解頁面。H2、H3 應反映內容層級，連結文字應說明目的，替代文字應描述資訊價值。
PM / QA：優先順序、驗收案例、回歸測試
PM 與 QA 要把無障礙轉成可執行案例，例如「使用鍵盤完成聯絡表單送出」或「錯誤訊息可被螢幕閱讀器讀出」。這比口頭要求更可靠。
Lighthouse / WAVE 通過，不代表真的符合 WCAG
Lighthouse、WAVE、axe 通過只能代表部分可程式化問題被檢查過，不能代表網站真的符合 WCAG 或對使用者完整可用。
| 測試方式 | 能檢查 | 不能取代 |
|---|---|---|
| 自動化工具 | 缺少 alt、低對比、表單標籤、部分 ARIA 錯誤 | 情境理解、流程順暢度、文案品質 |
| 鍵盤測試 | 焦點順序、選單、彈窗、表單操作 | 螢幕閱讀器朗讀品質 |
| 螢幕閱讀器測試 | 語意、標題、狀態訊息、互動元件名稱 | 所有使用者情境 |
| 行動裝置測試 | 觸控目標、縮放、方向切換、輸入流程 | 桌機鍵盤操作 |
自動化工具能找出哪些問題？
工具適合抓明確可判斷的問題，例如圖片缺少替代文字、表單沒有 label、文字對比不足、ARIA 屬性錯誤。這些問題應該在開發過程就被攔下。
自動化工具找不出哪些問題？
工具無法完整判斷「更多」這個連結在情境中是否清楚，也很難知道表單錯誤提示是否真的能幫助使用者修正。這些需要人工測試。
基本人工測試流程：鍵盤、螢幕閱讀器、表單錯誤、行動裝置
基本流程可從四件事開始：只用鍵盤走完主要任務，用螢幕閱讀器讀標題與表單，故意輸入錯誤資料看提示是否清楚，再用手機檢查觸控與縮放。
無障礙設計和 SEO 有什麼關係？
無障礙設計不保證 SEO 排名，但會透過語意 HTML、標題層級、alt text、可讀內容與穩定互動，間接支援搜尋引擎理解與使用者體驗。
| 無障礙做法 | 對使用者的好處 | 對 SEO 的間接幫助 |
|---|---|---|
| 語意 HTML | 輔助科技更容易理解結構 | 搜尋引擎更容易解析內容關係 |
| 清楚標題層級 | 快速掃描頁面重點 | 強化內容主題與段落結構 |
| alt text | 圖片資訊可被讀取 | 補足圖片與頁面語意 |
| 明確連結文字 | 知道點擊後會去哪裡 | 改善內部連結脈絡 |
| 可操作表單 | 降低任務失敗率 | 改善互動品質與轉換路徑 |
語意 HTML 讓輔助科技與搜尋引擎都更容易理解內容
正確的 heading、nav、main、button、form 能讓頁面結構更清楚。這對螢幕閱讀器有幫助，也讓搜尋引擎更容易判斷內容重點。
alt text、標題層級與連結文字能改善資訊結構
alt text 不應塞關鍵字，應描述圖片承載的資訊。標題層級也不該只為了字體大小調整，應反映內容關係。這些細節會讓網站無障礙與 SEO 同時受益。
不要把無障礙寫成保證排名的 SEO 祕技
把 WCAG 包裝成排名保證，會誤導決策。比較務實的說法是：無障礙設計能改善資訊品質、可讀性與互動穩定度，這些都是好網站應該具備的基礎。
WCAG 是什麼？和無障礙設計有什麼關係？
WCAG 是網站無障礙的國際標準，提供設計、開發、內容與檢測可共同依循的成功準則。無障礙設計是目標，WCAG 標準則是判斷網站是否接近這個目標的框架。
WCAG A、AA、AAA 差在哪？
A 是最低可用門檻，AA 是多數網站最實務的符合等級，AAA 則是更高標準。台灣企業網站若要放進改版與驗收，通常以 WCAG AA 較可執行。
台灣網站一定要做到 WCAG AA 嗎？
不應用一句話概括所有網站。公共服務、金融、教育、醫療與高流量服務頁通常更需要高標準；一般企業網站也建議用 AA 作為規劃目標，至少先處理主要流程。
WCAG 2.1 和 WCAG 2.2 有什麼差別？
WCAG 2.2 延續 2.1 的成功準則，並新增 9 項成功準則，重點包含焦點遮蔽、拖曳替代、目標尺寸、一致協助、重複輸入與可近用驗證。2026 年新專案建議優先參照 WCAG 2.2。
Lighthouse 分數通過，就代表符合 WCAG 嗎？
不代表。Lighthouse 只能檢查部分自動化可判斷的問題，例如對比、標籤與部分 ARIA 錯誤。WCAG 驗收仍需要鍵盤、螢幕閱讀器、表單錯誤與真實流程測試。
ARIA 是不是越多越好？
不是。ARIA 應用來補強語意，不應取代原生 HTML。能用 button、a、label、fieldset 解決的地方，通常先用原生元素會更穩定，也更容易被輔助科技正確讀取。
無障礙設計會不會讓畫面變醜？
不會。問題通常不在無障礙，而在設計系統沒有把對比、焦點、狀態與可讀性一起納入。好的無障礙設計可以維持品牌感，同時讓介面更穩、更清楚。
舊網站要怎麼分階段改善無障礙？
先盤點高流量、高轉換與高風險頁面，再處理表單、導覽、登入、搜尋、結帳與重要內容頁。舊網站不一定要一次全站重做，但每次修正都要留下可回歸測試的清單。
表單為什麼是無障礙最容易出錯的地方？
表單同時牽涉 label、必填提示、格式說明、錯誤訊息、鍵盤操作、狀態更新與送出結果。任何一環不清楚，使用者就可能無法完成註冊、詢價或結帳。
無障礙設計對 SEO 有幫助嗎？
有間接幫助，但不是排名保證。語意 HTML、清楚標題、替代文字、明確連結與可讀內容，都能改善資訊結構與使用體驗，這些也是 SEO 長期需要的基礎。