對比度是黑白研究唯一有法規效力的部分。WCAG 把它寫成一條兩行的公式，而全世界的設計工具都在用那條公式產生綠色勾勾。問題是那條公式建立在 1990 年代的簡化模型上，它看不見字級、看不見字重、看不見深色模式的非對稱性——而這些正好是 對比敏感度函數 告訴我們最重要的變數。
📖 學
一、WCAG 2.x 的公式
對比度 = (L1 + 0.05) ÷ (L2 + 0.05)
L1 = 較亮色的相對亮度，L2 = 較暗色的相對亮度
相對亮度範圍：0（黑）到 1（白）
相對亮度由 sRGB 值先做 gamma 解碼（轉回線性光），再用 Rec. 709 係數加權：0.2126 R + 0.7152 G + 0.0722 B。
最大值是純黑對純白的 21:1（代入 (1+0.05)/(0+0.05)）。
門檻值：
| 層級 | 一般文字 | 大型／粗體文字 |
|---|---|---|
| AA | 4.5:1 | 3:1 |
| AAA | 7:1 | 4.5:1 |
那個 +0.05 是什麼？ 它模擬環境光在螢幕表面造成的反射（flare）。沒有它，純黑的 L2 = 0 會讓比值變成無限大。這個常數是一個對典型觀看環境的假設，而不同環境（強光下的手機 vs 暗房裡的顯示器）的實際 flare 差很多——這是公式第一個隱藏的簡化。
二、四個已知盲點
盲點一：完全忽略字級與字重。
一個 12px 的細體灰字與一個 32px 的粗體字，只要顏色相同，WCAG 給的分數完全一樣。但 CSF 明確告訴我們：空間頻率是對比知覺的主要驅動因素之一。細小的字是高空間頻率刺激，需要更高的對比才能被偵測。
WCAG 有「大型文字門檻降到 3:1」這條規則，算是粗糙地承認了這件事，但它是一個二分的門檻而不是連續的函數。
盲點二：在深色區段系統性高估對比。
公式在兩色都偏暗時給出的數字，明顯高於實際可讀性。一個算出 4.5:1 的深灰配近黑，在實際使用中可能相當難讀。這直接導致 WCAG 2.x 對深色模式無法給出可靠指引——而深色模式在 2020 年代已經是主流需求，這一點讓它的實用性大打折扣。相關的實作討論見 Dark Theme 最佳實踐。
盲點三：對調前景與背景得到相同分數。
公式是對稱的——黑字白底與白字黑底算出來一模一樣。但這兩者的知覺性質不同：白字黑底會因為光暈（halation／irradiation）顯得字更粗、筆劃更容易糊在一起，在細字重上尤其明顯。極性（polarity）是真實變數，公式看不見它。
盲點四：對色相不敏感。
人眼對藍的敏感度遠低於綠與紅，但公式用固定的加權處理所有色相組合。某些在數值上達標的組合（特別是涉及飽和藍或飽和黃的）實際表現與分數不符。
三、APCA：提議中的替代方案
APCA（Accessible Perceptual Contrast Algorithm） 是為 WCAG 3.0 提議的替代算法，針對上述盲點做了結構性的改變：
- 分別建模背景亮度與文字亮度，而不是取一個對稱的比值。
- 把字級與字重納入，輸出的門檻隨字體參數變動。
- 處理極性，light-on-dark 與 dark-on-light 給出不同結果。
APCA 的輸出是一個帶正負號的 Lc（lightness contrast）值，常被引用的門檻大致是：Lc 90 以上對應內文（大致相當於 WCAG AA 在淺底上的 4.5:1），Lc 75 以上對應大型／粗體文字。
但必須講清楚現狀：WCAG 3.0 仍在草案階段，APCA 的門檻值可能再調整，而目前絕大多數法規合規要求引用的仍是 WCAG 2.x。
實務立場：用 WCAG 2.x 做合規底線（因為那是法律要求的），用 APCA 或實際測試做品質判斷（因為它更貼近知覺）。兩者衝突時——通常發生在深色模式與細字上——相信眼睛與使用者測試。
四、黑白極端值的實務問題
純黑字配純白底（21:1）在長文閱讀上通常不是最佳選擇。 常見的理由是高對比在明亮環境下造成光暈與眼睛疲勞，許多閱讀介面因此選擇略低的對比（例如 #1a1a1a 配 #fafafa，約 17–18:1）。
這個「高對比反而不好」的說法需要小心處理。 它在設計圈廣泛流傳，但可引用的對照研究很有限，而且對視力不佳或低視力使用者而言，更高的對比通常確實更好。把「我覺得刺眼」推廣成「所有人都不該用純黑白」是過度推論，列在 主張 vs 可佐證。
純黑背景（#000000）在 OLED 上有實際的技術後果：像素完全關閉，與相鄰亮像素的切換會產生較明顯的拖影（smearing），而且極端對比在暗環境下的光暈更強。這是為什麼許多深色模式用的是 #121212 這類深灰而非純黑——Material Design 明確建議深色介面用深灰而非純黑，理由同時包含表達層級（純黑之下沒有更暗的層可用）與視覺舒適。
五、非文字元素的對比
常被忽略的一塊：WCAG 2.1 對非文字元素也有 3:1 的要求——UI 控制項的邊界、圖示、圖表中用來區分資料的元素。
這一條是最常被違反的，因為淺灰的細邊框在視覺上很討喜，而設計稿在高品質螢幕上看起來總是沒問題。典型的受害者是：輸入框的邊框、停用狀態的按鈕、圖表的格線與資料系列。
圖表有一個額外的硬要求：不能只靠顏色區分資料。 因為 明度軸 那篇講的——色相不同但明度接近的兩個顏色，在灰階下與對多數色覺異常者而言是同一個。對策是同時給出明度差、形狀差或圖案差，而驗收方法極簡單：把圖表轉成灰階，如果還分得出來就過關。
🧠 記
WCAG 公式的 +0.05 是對環境反射的假設，不同觀看環境下並不準確。
四個盲點：忽略字級字重、深色區段高估、極性對稱、色相不敏感——每一個都對應 CSF 已知的事實。
WCAG 2.x 是法規底線，APCA 是品質判斷；衝突時（深色模式、細字）相信測試。
「高對比傷眼」是流傳廣但證據薄的主張，對低視力使用者通常相反。
深色模式用深灰而非純黑，理由同時是層級表達與視覺舒適。
圖表驗收法：轉成灰階還分得出來就過關。
✍️ 實踐
對自己的介面做一次灰階與極性檢查，30 分鐘：
第一步：灰階測試（最快找出色相依賴）
/* 暫時套用到整個頁面 */
html { filter: grayscale(100%); }逐頁檢視：圖表的資料系列還分得出來嗎？狀態色（成功／警告／錯誤）還分得出來嗎？連結還看得出是連結嗎？任何在灰階下消失的區分，都是只靠色相在工作的設計。
第二步：對比實測，不要只信設計稿
用瀏覽器開發者工具的對比度檢查（Chrome DevTools 的 Inspect 面板會直接顯示），特別查這四類最常出問題的元素：輸入框邊框、停用狀態、佔位文字（placeholder）、圖表格線。
第三步：極性對照
把同一段內文做成「深底淺字」與「淺底深字」兩版，用相同的字重，在明亮環境與昏暗環境各看一次。多數人會發現深底淺字在細字重下明顯較糊——那就是 WCAG 公式看不見的那個變數。
第四步：縮小測試
把介面縮到 50%，看哪些細線與小字消失了。這直接對應 CSF 的高頻截止。
🔗 延伸學習
- W3C — Understanding Success Criterion 1.4.3: Contrast (Minimum)——門檻值的官方說明與其理由，含大型文字的定義。
- APCA — The Easy Intro to the APCA Contrast Method——APCA 作者方的入門說明，解釋它為何與 WCAG 2.x 得出不同結論。
- Material Design — Dark theme——深色介面用深灰而非純黑的理由與建議值。
相關
- 黑白研究——黑與白的著迷、互補，與顏色學（hub）
- 感知與錯覺：CSF 與空間頻率
- 明度軸
- Dark Theme 最佳實踐 — 前端實作的完整展開