WCAG 對比度檢查

對比度是什麼？為什麼用眼睛看不準

WCAG 的對比度是一個數字，描述兩個顏色在「亮度」上差多遠：兩個一模一樣的顏色是 1:1，純黑配純白是 21:1。本頁收前景色與背景色兩個色碼，算出比值，再告訴你它過得了 WCAG 2.1 的哪幾條門檻。

算式本身很短：

ratio = (L1 + 0.05) / (L2 + 0.05)
L = 0.2126 × R + 0.7152 × G + 0.0722 × B（sRGB 線性化後）

那組權重就是「用眼睛看」會失準的原因。綠色佔了七成多的亮度、藍色不到十五分之一，所以一個飽和的藍看起來很亮很有精神，對亮度卻幾乎沒有貢獻。品牌色的藍、紫、紅放在白底上，常常就落在 3:1 到 4.5:1 之間，剛好是「挑色的人覺得沒問題、其他人看得很吃力」的那一段。公式裡兩邊各加的 0.05 是在模擬螢幕反射的環境光，也是比值最高只到 21 的原因。

另外，這個數字完全不管色相。兩個亮度相同的顏色，不管看起來差多少，算出來都是 1:1；而過了 4.5:1 的配色也可能刺眼到看不下去。對比度是及格線，不是設計審查。

如果你手邊只有 HEX，想轉成 RGB、HSL 或反推同色相不同明度的相近色，可搭配 色碼轉換工具 一起調，直接把調整後的色碼貼回本工具驗證 AA / AAA。

哪一條門檻對應介面的哪一塊

• AA 一般文字（4.5:1）：可讀性基本門檻，多數設計系統最低標
• AA 大字（3:1）：≥ 18pt 或 ≥ 14pt 粗體
• AAA 一般文字（7:1）：高可讀性、銀髮族與弱視友善
• AAA 大字（4.5:1）
• 圖示、控制項邊框、焦點框、圖表線條（3:1）：WCAG 2.1 的 1.4.11 非文字對比（AA 級），管的是「辨識元件與其狀態所需的視覺資訊」。淡淡的 1px 輸入框邊線最常在這一條陣亡。
• 商標與停用中的元件：WCAG 明文豁免商標、品牌名稱、停用中的介面元件與純裝飾。豁免不等於好讀，停用狀態的文字還是留一點可讀性比較好。
• 深色模式：門檻一樣，但要分開量。白底過了不代表深色底也過，而且卡片只要比頁面淺一階，上面每一組比值都會跟著變。

「大字」在 WCAG 2.1 的定義是 18 點以上，或 14 點以上的粗體；換算成 CSS 大約是 24px，粗體大約 18.66px（CSS 的 1 點是 1/72 英吋）。中文字在同樣點數下看起來比英文密，所以標題靠大字門檻放行時，實際排出來再看一眼比較保險。

實戰教學：檢查一組配色

1. 前景色填文字的顏色，背景色填文字後面那一層的顏色。三位數簡寫（例如 #fff）可以用，旁邊的色彩選擇器也能直接點。
2. 看那個大數字。下面四格會分別告訴你 AA 一般文字、AA 大字、AAA 一般文字、AAA 大字過不過。
3. 順便看上面的即時預覽。它用你的兩個顏色畫標題、內文與小字；剛好壓線過 4.5:1 的配色，落到小字往往還是很虛，這就是「看」比「算」多出來的資訊。
4. 要量圖示或邊框，就把圖示的顏色填前景、它正後方那一層填背景，改看 3:1 那一格。
5. 每個會換顏色的狀態都要各量一次：hover、focus、已瀏覽過的連結、錯誤訊息。

這個檢查最常出現在這些場合：

• UI 元件審查：按鈕、表單、連結對比是否足夠
• 品牌主色 vs 背景色驗證
• 無障礙檢測（a11y audit）必跑
• 銀髮族、教育、醫療類產品優先採用 AAA

實戰教學：品牌色過不了 AA 怎麼救

前景色沒過 AA 一般文字時，本頁會直接給一個建議色：保留色相與飽和度、只動明度，停在剛好到 4.5:1 的最小幅度，所以看起來還是同一個顏色。按「套用建議色」就換過去，或者換個方式解：

1. 改背景，不要改品牌色。品牌色通常動不了，底色可以：在白底上不及格的黃，放到接近黑的底色上就過得很輕鬆。
2. 把按鈕反過來做。淺的品牌色當文字很糟、當底色很好。底色用品牌色、文字用白或接近黑，改量那一組，再確認按鈕跟頁面背景之間有沒有 3:1。
3. 把文字升級成大字。18 點、或 14 點以上的粗體，門檻降到 3:1。標題這樣做沒問題，整段內文這樣做就是自欺欺人。
4. 品牌色準備兩個版本。很多設計系統會有一個給大面積用的行銷色，再加一個只給文字與圖示用的加深或提亮版本，這是「品牌當初沒為螢幕設計」的標準解法。

色碼怎麼取得、結論怎麼交出去

這件事最花時間的其實是拿到正確的色碼。用眼睛從截圖上判讀出來的顏色，跟樣式表裡的值往往不一樣，廣色域螢幕還會再偏一點。

• 從線上的頁面取：開 devtools 選到元素，複製 computed 的 color 與 background-color。computed 值已經把繼承與疊色算進去了，那才是你要的那個。
• 從設計稿取：直接複製填色的色碼，不要用滴管在畫布上吸，那會吸到反鋸齒的邊緣像素。
• macOS、Windows：macOS 的「數位色彩計」（在工具程式裡）可以讀螢幕上任一個像素，記得切成 sRGB 顯示，不然數字跟 CSS 對不起來；Windows 用 PowerToys 的 Color Picker。
• 把結論交出去：把比值與四格過關表截一張圖丟進 PR 或聊天室最快。順手把條款編號寫上（1.4.3 或 1.4.11），對方要查有得查。

別的工具怎麼算、哪裡會對不起來

符合規範的檢查器用的都是同一條公式，所以兩邊算出來不一樣，幾乎都是「餵進去的顏色不同」。用 JavaScript 寫出來就十來行：

const lin = c => {
  const s = c / 255
  return s <= 0.03928 ? s / 12.92 : ((s + 0.055) / 1.055) ** 2.4
}
const luminance = ([r, g, b]) =>
  0.2126 * lin(r) + 0.7152 * lin(g) + 0.0722 * lin(b)

const ratio = (a, b) => {
  const [hi, lo] = [luminance(a), luminance(b)].sort((x, y) => y - x)
  return (hi + 0.05) / (lo + 0.05)
}

ratio([26, 26, 26], [255, 255, 255]) // 17.4

• 瀏覽器 devtools：Chrome 的 Styles 面板點色塊會顯示對比度與 AA / AAA 標記，還能在選色器上畫一條門檻線；Firefox 在無障礙檢測器裡顯示，文字壓在圖片上時給的是一個範圍而不是單一數字；Safari 的選色器也會顯示比值。確切位置每個版本都在搬，這裡寫的是目前的情況。
• 自動化檢測：Lighthouse 與 axe 都會報文字對比不足，但兩者都會跳過它們算不出來的情況，包括壓在圖片或漸層上的文字、以及畫進 canvas 的文字。報告全綠不等於這頁過了 1.4.3。
• 設計工具外掛：對比外掛通常拿選取的圖層跟它正後方那一層比，中間夾了半透明遮罩時就會算錯。
• 廣色域色彩：WCAG 的公式定義在 sRGB 上，寫成 color(display-p3 ...) 或 oklch() 的顏色要先轉回 sRGB；超出 sRGB 色域的顏色沒有精確答案。
• 作業系統可以蓋過你：Windows 的高對比佈景會整組換掉你的配色，CSS 端看到的是 forced-colors；Windows 與 macOS 也都有「提高對比」的設定，對應 prefers-contrast。這兩種模式也要測。

台灣這邊，公部門網站與政府標案採用的「網站無障礙規範」是依 WCAG 訂的，驗收時看的通常是 AA 級；實際要對到哪一版、哪幾條，以該案的招標與驗收文件寫的為準。民間產品沒有法定門檻，但 AA 已經是多數設計系統的最低標。

限制與隱私

什麼都不會離開你的瀏覽器。兩個色碼都是在你的裝置上解析與相除，不上傳、不儲存、不寫進紀錄，載入之後斷網也照樣能用。

只吃兩個不透明的純色。工具讀的是 hex，並假設兩個顏色都完全不透明。有半透明就自己先疊好、把疊完的顏色貼進來。它也看不到你的頁面，不知道文字後面實際上是什麼。

2.x 的公式有已知的盲點。普遍認為它對「淺色文字壓在中深色背景上」過於嚴格、對很暗的配色又過於寬鬆，這也是 APCA 與 WCAG 3.0 在處理的事。在那之前，會被拿來驗收的還是 4.5:1 與 3:1。

對比只是其中一條。過了不代表字級、行長、細字重沒問題，也不代表你沒有犯「只用顏色區分狀態」（那是另外一條）。它更沒有考慮色覺辨認障礙，因為公式從頭到尾不看色相。

四捨五入。比值顯示到小數點後兩位。顯示 4.49 是不及格、4.50 是及格，不同工具在邊界上的進位方式不同就會吵起來。差這麼一點的配色，直接改掉比較快。