昨天我們用真實流量、隨機分流與統計推論,回答了「哪個版本真的更好」;今天要追問的是那句話裡藏著的一個盲點——「更好」,是對誰更好?A/B 測試的多數樣本裡,用鍵盤操作、靠螢幕報讀器讀頁面、色弱、會被動效誘發暈眩的人,人數往往少到根本擠不進你的顯著性門檻,於是他們的體驗被系統性地「優化」掉而沒人察覺。無障礙設計(Accessibility,常簡寫 a11y)要處理的,正是這條被量化指標默默忽略的長尾:讓「所有人」——包含障礙者、老年人、暫時性受限者、以及情境受限的一般人——都能感知、操作並理解你的介面。這不是量化實驗之外的加分題,而是決定「你的產品到底服務多廣」的品質底線。
📖 學
無障礙不是慈善,是設計品質的底線
先破除最根本的迷思:「無障礙只服務少數人」。實務上受益的族群遠比想像廣。障礙不只是永久性的(全盲、聾、肢體障礙),還包括暫時性的(手臂骨折只能單手操作、眼睛剛做完手術)與情境性的(大太陽下看不清螢幕、抱著小孩只有一隻手、在吵雜捷運上聽不到影片聲音)。當你把這三種情境加起來,幾乎每個人一生中都會在某些時刻「暫時成為障礙者」。
最經典的說明是 curb-cut effect(路緣斜坡效應):人行道轉角那個原本為輪椅設計的斜坡,最後嘉惠了推嬰兒車的父母、拉行李箱的旅客、送貨的推車。介面世界一樣:字幕原本為聽障設計,現在人人在無聲環境滑手機都靠它;高對比與大字級服務低視力者,也讓所有人在陽光下看得更清楚;清楚的鍵盤操作服務行動不便者,也讓進階使用者用得更快。無障礙做得好,是把「為邊緣情境設計」的紅利回饋給每一個人——它幾乎從不只服務少數人。
還有一層是現實壓力:無障礙在越來越多市場是法律要求而非選配。歐盟的《歐洲無障礙法案》(EAA)已於 2025 年 6 月 28 日正式生效,要求許多對歐洲消費者銷售數位產品或服務的企業符合 WCAG;美國有 ADA 與 Section 508;台灣公部門網站也長年要求無障礙標章。把它當成「有空再做的善事」,遲早會變成「上線前才發現過不了」的合規債。
WCAG 與 POUR 四原則
談無障礙繞不開 WCAG(Web Content Accessibility Guidelines),它是 W3C 底下 WAI 制定的國際標準,現行主線是 2023 年 10 月發布的 WCAG 2.2,並已於 2025 年被採納為 ISO/IEC 40500 國際標準。整套標準的骨架是四個原則,首字母縮寫為 POUR:
- 可感知(Perceivable):資訊與介面元件必須能被使用者的某種感官接收到。文字要有替代形式(圖片要有 alt、影片要有字幕與口述影像)、色彩對比要足夠、不能只用顏色傳達意義(例如「紅色欄位代表錯誤」對色盲者就失效,要同時加圖示或文字)。
- 可操作(Operable):所有功能都要能被操作,而且不只靠滑鼠。核心是完整的鍵盤可操作性、合理且可見的焦點順序、足夠的時間限制彈性、不使用會誘發癲癇的閃爍(每秒閃三次以下),以及夠大的點擊目標。
- 可理解(Understandable):內容與操作要可預期、可理解。語言標示正確、行為一致(導覽列不會每頁亂跳)、表單有清楚標籤與錯誤提示,並在使用者出錯時給出可修正的引導,而不是冷冰冰的「輸入錯誤」。
- 穩健(Robust):內容要夠健壯,能被各種使用者代理(瀏覽器)與輔助技術(螢幕報讀器等)可靠地解讀。這條最直接的實作就是用正確、語意化、合乎規範的 HTML,讓程式與輔具都能正確辨識每個元件的角色與狀態。
記住 POUR 的價值在於:當你面對一個新元件不知從何檢查時,依序問「它可感知嗎?可操作嗎?可理解嗎?夠穩健嗎?」——四個問題就能覆蓋絕大多數常見缺陷。
A、AA、AAA 三個等級怎麼選
WCAG 把每條「成功準則(success criteria)」分成三個符合等級。A 是最低門檻,不做到會讓部分使用者完全無法使用(例如影片完全沒有替代方案、鍵盤根本無法操作)。AA 是業界與多數法規實際採用的目標等級,涵蓋大部分關鍵體驗,例如正常文字對比至少 4.5:1、大字與圖形介面元件至少 3:1、頁面可縮放到 200% 不破版。AAA 是最高標準(例如對比拉高到 7:1、提供手語翻譯),通常無法對整站全面達成,W3C 自己也說明不建議把 AAA 當作全站的一般政策目標。
實務建議很明確:以 WCAG 2.2 AA 為預設目標,它是「合規、可達成、覆蓋主要族群」三者的最佳平衡點;再針對特別關鍵的流程(如登入、結帳、緊急求助)選擇性地把某些準則做到 AAA。不要一開始就喊「我們要做到 AAA」——那多半會變成做不完、於是什麼都沒交付的空話。
螢幕報讀器怎麼「讀」你的頁面
要做好無障礙,得先想像失去視覺後你的頁面聽起來是什麼樣子。螢幕報讀器(screen reader)(如 NVDA、JAWS、macOS/iOS 的 VoiceOver、Android 的 TalkBack)不是「唸出畫面上的像素」,而是讀取瀏覽器建立的 無障礙樹(accessibility tree)——這棵樹由你的 HTML 語意推導而來。使用者不是從上到下線性地聽完整頁,而是像用目錄跳讀:用「下一個標題」在 h1/h2/h3 之間跳、用「下一個地標」在 header/nav/main/footer 之間切、叫出頁面所有連結或表單欄位的清單快速掃描。
這帶出兩個關鍵實作。其一,語意化 HTML 決定了這棵樹好不好用:如果你的標題其實是加粗的 <div>、按鈕其實是綁了 onclick 的 <span>,報讀器就讀不出「這是標題」「這是按鈕」,跳讀與操作全部失靈。其二,焦點順序(focus order)必須符合邏輯:視障或行動不便者用 Tab 鍵在可互動元件間移動,順序若和視覺閱讀順序脫節(常見於用 CSS 硬把元素搬位置、或彈窗開啟後焦點沒被關進 modal 裡),使用者會像被蒙眼在房間裡亂撞。順帶一提,焦點必須「看得見」——別為了美觀用 outline: none 把焦點框拿掉,那等於把鍵盤使用者的游標藏起來。
三個最常見、也最好修的洞
如果時間有限,先修這三個,投報率最高。
色彩對比比值。 文字與背景的亮度差要達標:AA 對正常文字要求 4.5:1、大字(約 18px 粗體或 24px 一般)與圖形/介面元件要求 3:1。這是最容易量化、也最容易被設計稿的「淺灰配白」踩雷的一項。用 WebAIM Contrast Checker 貼上前景與背景的 hex 值,幾秒就知道過不過,還能微調到剛好達標。
鍵盤可操作與焦點順序。 拔掉滑鼠,只用 Tab、Shift+Tab、Enter、空白鍵、方向鍵,試著走完你最重要的流程。若有任何按鈕點不到、下拉選單打不開、彈窗關不掉、或焦點跑到看不見的地方(鍵盤陷阱),就是明確的缺陷。這也是為什麼原生 <button>、<a>、<input> 這麼重要——它們內建了鍵盤可操作性,你用 <div> 自造就得自己補齊 tabindex、鍵盤事件與焦點管理,通常補得不完整。
替代文字(alt)。 有意義的圖片要寫能傳達「這張圖在說什麼」的 alt(不是檔名、不是「圖片」二字);純裝飾圖片則給空的 alt="",讓報讀器直接略過,避免噪音。判準是:如果把圖拿掉換成這段文字,資訊有沒有斷掉?有,就要寫;沒有,就留空。
替代文字、ARIA 與語意化 HTML:別把 ARIA 當萬靈丹
這裡要破除第二個大迷思:「加了 ARIA 就無障礙」。ARIA(Accessible Rich Internet Applications) 是一組屬性,用來在原生 HTML 語意不足時補上角色(role)、狀態(如 aria-expanded)與名稱(如 aria-label)。它很有用,但有個關鍵事實常被忽略:ARIA 只提供語意,不提供任何行為。你在 <div> 上加 role="button",報讀器會唸出「按鈕」,但這個 div 依然不能用鍵盤按下、不會有 hover/focus 狀態——那些行為原生 <button> 免費附贈,加 ARIA 卻一點都不會補。
因此 ARIA 的第一條規則就是:能用原生 HTML 元素表達語意時,就別用 ARIA。優先序永遠是「先挑對的語意化標籤(button/nav/main/label/…),原生做不到時才動用 ARIA」。濫用 ARIA 甚至會幫倒忙——錯誤的 role 會覆蓋掉原生語意,讓報讀器讀出比沒加還糟的結果(研究常引用「錯的 ARIA 比沒有 ARIA 更糟」)。
表單是語意化的重災區,值得單獨提。每個輸入欄位都要有真正關聯的 <label for="...">(或用 aria-label/aria-labelledby),否則報讀器唸到欄位時只會說「編輯框」,使用者根本不知道要填什麼。用 placeholder 當標籤是常見錯誤:placeholder 一旦開始輸入就消失、對比通常不足、也不被所有輔具當成名稱。錯誤訊息也要透過語意(如 aria-describedby、role=“alert”)即時、明確地傳達給報讀器,而不只是把文字變紅。
動效、prefers-reduced-motion,與「無障礙會犧牲美感」的迷思
華麗的視差滾動、彈跳轉場、自動輪播,對前庭功能敏感的使用者可能誘發頭暈、噁心甚至偏頭痛。CSS 的 prefers-reduced-motion 媒體查詢讓你能偵測到使用者在系統層級開了「減少動態效果」,並據此提供收斂版的動畫(縮短、改為淡入淡出、或直接停用)。做法很單純:預設寫剋制的動效,再在 @media (prefers-reduced-motion: no-preference) 裡加上比較豐富的動畫;或反過來在 reduce 時把 transition/animation 關掉。此外,任何會自動播放且超過五秒的動態內容,都要提供暫停/停止的控制。
這正好帶到第三個迷思:「無障礙會犧牲美感」。恰恰相反,無障礙的約束多半會逼出更好的設計——足夠的對比讓畫面在各種光線下都清晰、清楚的層級與焦點狀態讓介面更好懂、克制的動效讓體驗更沉穩不廉價。真正的高手是在「所有人都能用」的前提下把美感做出來,而不是用犧牲可用性換取小圈子覺得酷的視覺。無障礙與美感不是零和,它是一種更成熟的設計品味。
測試:自動化、人工、真實輔具三層並用
最後破除第四個、也是最危險的迷思:「自動掃描器綠燈就過關」。自動化工具(如 axe、Lighthouse、WAVE)確實該用,它能秒抓對比不足、缺 alt、缺 label、標題階層錯亂等機械性問題,適合放進 CI 當守門員。但業界的共識是:自動掃描器大約只能偵測到全部無障礙問題的三成上下,剩下七成——例如 alt 文字寫得對不對、焦點順序合不合邏輯、鍵盤能不能真的走完流程、錯誤訊息說不說得清楚——這些「品質」層面的判斷,機器測不出來。
所以要三層並用:第一層,自動化掃描抓低垂的果實、防止退步;第二層,人工測試,像前面說的拔掉滑鼠用鍵盤走一遍、用縮放到 200% 檢查、對照 WCAG AA 逐條檢核;第三層,也是最關鍵的,用真實輔具與真實使用者測——親自打開 VoiceOver 或 NVDA 聽你的頁面被怎麼唸出來,最好邀請真正的障礙者參與測試。這一步會讓你發現所有掃描器與想像都抓不到的問題,也呼應昨天的主軸:量化能告訴你「多少人受影響」,但要真正理解「他們卡在哪、為什麼卡」,終究得回到質性、回到真人。
🧠 記
- 無障礙不只服務少數人:障礙分永久/暫時/情境三種,curb-cut effect 讓「為邊緣設計」的紅利回饋給所有人;在 EAA、ADA 等法規下它已是合規要求。
- WCAG 用 POUR 四原則收束一切:可感知、可操作、可理解、穩健;遇到新元件就依序拿這四問去檢查。
- 符合等級選 AA 當預設目標(對比 4.5:1、可縮放、鍵盤可操作),關鍵流程再選擇性做到 AAA;別喊全站 AAA。
- 語意化 HTML 是地基:螢幕報讀器讀的是由 HTML 語意推導的無障礙樹,標題、按鈕、地標用對標籤才跳讀得動;焦點順序要合邏輯且看得見。
- ARIA 只給語意、不給行為,第一規則是「原生能做就別用 ARIA」;表單一定要有真正關聯的 label,別拿 placeholder 當標籤。
- 動效尊重 prefers-reduced-motion;無障礙不犧牲美感,反而逼出更好的設計。測試要自動掃描+人工+真實輔具三層並用——掃描器綠燈只覆蓋約三成問題。
✍️ 實踐
挑你手上一個真實、重要的頁面(登入、結帳、或首頁主流程),用約 40 分鐘做一次「三層快檢」,把發現逐條記下來:
- (5 分)自動掃描:在 Chrome DevTools 打開 Lighthouse 的 Accessibility 稽核,或裝 axe DevTools / WAVE 擴充套件跑一次,截圖記下所有紅點。
- (10 分)對比與色彩:把頁面主要的文字/背景、按鈕/背景 hex 值貼進 WebAIM Contrast Checker,確認正常文字 ≥ 4.5:1、大字與介面元件 ≥ 3:1;同時檢查有沒有「只靠顏色」傳達的狀態,補上圖示或文字。
- (10 分)鍵盤走一遍:雙手離開滑鼠,只用 Tab / Shift+Tab / Enter / 空白 / 方向鍵走完整個流程,記下任何點不到、焦點看不見、彈窗關不掉、或焦點被困住的地方。
- (10 分)聽一遍:打開 VoiceOver(mac:Cmd+F5)或 NVDA(Windows),閉上眼睛用「下一個標題」「下一個表單欄位」跳讀,記下唸出來讓你困惑的地方——尤其是圖片 alt、按鈕名稱、表單 label。
- (5 分)排優先序:把所有發現按「影響大小 × 修復成本」排序,先修「阻斷型」缺陷(鍵盤走不完、對比不足、缺 label),把它們變成明確的修復任務。
做完你會很直觀地體會到:掃描器綠燈的那幾項,和你用鍵盤、用耳朵親自撞到的那些,根本是兩個世界。
🔗 延伸學習
- WCAG 2 Overview — W3C WAI:官方對 WCAG、POUR 四原則與 A/AA/AAA 等級的權威總覽,入門必讀。
- Web Content Accessibility Guidelines (WCAG) 2.2 — W3C:現行標準原文,可逐條查每個成功準則的定義與符合等級,做 AA 檢核時的第一手依據。
- ARIA — MDN Web Docs:把「先用語意化 HTML、ARIA 只給語意不給行為、能不用就不用」講得最清楚的實作指南。
- WebAIM: Contrast Checker:最常用的色彩對比工具,貼上 hex 立刻知道 AA/AAA 過不過,還能微調到達標。
💬 問 AI
想把今天的檢核變成可重複的習慣,可以請 AI 當你的「無障礙稽核陪練」,幫你把一個真實頁面拆成可執行的檢查清單與修復建議。試試以下提示詞:
你是資深無障礙(a11y)顧問,精通 WCAG 2.2 AA 與螢幕報讀器實務。我要稽核以下頁面/元件:
- 頁面/流程:〔描述,例如結帳頁〕
- 使用的技術:〔HTML/React/…〕
- 我在意的關鍵操作:〔例如填表送出、開關彈窗〕
- (可選)我目前的自動掃描結果:〔貼上 axe/Lighthouse 的紅點〕
請依序協助我:
1. 用 POUR 四原則,各列出這類頁面最常見的 3 個缺陷與具體症狀。
2. 給我一份「鍵盤走查」與「螢幕報讀器聽查」的逐步檢核清單,標明每步對應的 WCAG AA 準則。
3. 針對色彩對比、alt 文字、表單 label、焦點順序、prefers-reduced-motion 各給一段「正確 vs 錯誤」的程式碼對照範例。
4. 明確指出:哪些問題自動掃描器測得到、哪些一定要人工或真實輔具才能發現。
5. 最後幫我把所有發現按「影響大小 × 修復成本」排序,先修哪些阻斷型缺陷。