我的知識庫

UIUX · 2026-08-16

閱讀時間約 14 分鐘

顏色對比不是一個「過或不過」的門檻,而是一個和字級、字重、明暗方向綁在一起的連續量,而現行 WCAG 2.2 用一個固定比值假裝它是單一門檻。昨天談 design token 支援 Oklch、Display P3 這些現代色彩空間時,順帶提過一句:Oklch 的感知均勻特性讓你做無障礙對比時比 hex/HSL 可靠。今天把鏡頭轉到那個「對比」本身——它正在從一條算式(WCAG 2.x 的對比比值)換成另一條(APCA),而 2026 年最務實的姿態,是同時懂這兩套、知道各自該用在哪。

📖 學

現行規則:一個比值走天下,以及它為什麼不太準

先講你現在一定要達標的東西。WCAG 2.2 Level AA 對文字對比的要求很單純:一般文字前景與背景的對比比值(contrast ratio)要 ≥ 4.5:1,大字(約 18px 以上,或 14px 以上的粗體)放寬到 3:1。這個比值的算法是把兩個顏色各自算出相對亮度(relative luminance),較亮的加 0.05、較暗的加 0.05,兩者相除。數字大於等於門檻就過,小於就不過——乾淨、二元、好稽核。

但這條算式有個從第一天就被詬病的結構性問題:它對「亮底黑字」和「暗底白字」一視同仁,只要兩色的亮度比一樣就給同一個分數。問題是人眼不是這樣運作的。同一組亮度差,深色背景配淺色字的實際可讀性,和淺色背景配深色字並不相等;而且這條算式在中間調(mid-tones)特別失準——很多在 4.5:1 剛好過關的灰字,實際讀起來吃力得要命,反過來也有些明明讀得很清楚的組合卻算不過。換句話說,WCAG 2.x 的對比比值是一個能通過稽核、卻不總是反映真實閱讀體驗的指標。這不是它壞掉了,而是它 2008 年設計時的簡化,在 2026 年的高解析螢幕與廣色域下,精度已經不夠用。

還有一個 2026 年不能忽略的外部壓力:美國司法部 2024 年 4 月更新了 ADA Title II,要求州與地方政府的網站、App、資訊站台符合 WCAG 2.1 A/AA,服務超過五萬人的單位合規期限就落在 2026 年。也就是說,WCAG 2.2 AA 這條線在今天不只是「最佳實務」,對很多機構是法遵底線。這件事不會因為有更好的演算法出現而消失。

下一代:APCA 把「對比」還原成它本來的樣子

WCAG 3.0(還在草案階段)預計引入的新演算法叫 APCA(Advanced Perceptual Contrast Algorithm,進階感知對比演算法)。它和舊比值最根本的差別,是它把對比理解成一個受字級、字重、明暗方向共同影響的感知量,而不是兩個亮度相除的純比值。

APCA 的輸出不是「4.5:1」這種比值,而是一個叫 Lc(lightness contrast,明度對比) 的分數,範圍大約 Lc 0 到 ±106。你把這個值當絕對數字來讀——數字愈大代表感知對比愈強;前面的正負號只表示極性(暗字亮底 vs 亮字暗底),不影響大小判讀。關鍵在於:同一個 Lc 60,不論你的顏色偏亮或偏暗,代表的「被感知到的可讀性」是一致的。這正是舊比值做不到的——它把感知交還給了感知。

於是使用門檻也從「一個數字打天下」變成依閱讀情境分級,這幾個數字值得記住:

  • Lc 90:流暢閱讀的正文首選,用在較小或較細的字(約 14px、400 字重的正文段落)。
  • Lc 75:一般正文的最低標準,適用於不小於 18px、400 字重的段落文字。
  • Lc 60:大字或粗體的最低標準,例如標題、明顯的 UI 標籤這類「非正文區塊」的文字。

這個分級的哲學很重要:它承認「該有多少對比」本來就取決於你要讀者花多少力氣、這段字有多重要——正文要讀很久,所以要求高;一個大標題掃一眼就懂,可以低一點。這比「所有文字一律 4.5:1」細緻得多,也更接近設計師實際在做的判斷。

一個殘酷但必要的認知:兩套算式不相容

這裡有個最容易踩的坑,務必記牢:APCA 的分數和 WCAG 2.x 的比值不能互換、也不能互相換算。一組今天用 4.5:1 剛好過關的顏色,拿去跑 APCA 可能不及格;反過來,一組 WCAG 2.x 算不過、你卻覺得明明讀得很清楚的組合,在 APCA 可能是達標的。它們是兩條建立在不同模型上的算式,沒有一個乘法係數能把 Lc 75 翻成「幾比幾」。

所以你不能「用 APCA 重新驗一次舊調色盤,然後宣稱通過 WCAG」——那在合規上完全不成立。正確的做法是把它們當成兩個不同用途的工具並用:用 WCAG 2.2 AA 通過稽核與滿足法遵,用 APCA 來設計真正讀起來舒服的畫面。前者是今天的合格線,後者是你面向未來、也面向真實使用者的品質線。

2026 年的務實工作流

把上面接起來,一個成熟團隊今天處理對比的方式大致是這樣。第一,調色盤與 design token 的每一組「前景/背景」語意配對(例如 text/on-surface 對 surface/default),先確保它們過 WCAG 2.2 AA——這步不能省,是稽核與法遵的底。第二,同一批配對再跑一次 APCA,對正文要求 Lc 75 以上、小字追 Lc 90,把那些「勉強過 4.5:1 但 Lc 偏低」的中間調灰字揪出來調亮或調重,因為那批正是使用者真正讀得辛苦的。第三,把這兩個檢查做進 token pipeline 或 CI,讓對比不是設計交付後才手動抽驗,而是每次改色值都自動被擋一次。

工具面也成熟了:APCA 已經內建在 Chrome DevTools(實驗性),官方也有 APCA 對比計算器可直接輸入兩色看 Lc 值。它目前還不是法律要求,但走在前面的團隊現在就拿它驗調色盤,為的是避免 WCAG 3.0 正式化那天要大規模返工的成本。這件事和昨天的 token 主題是同一個道理:對比規則本身也該有單一真實來源,寫進 token 與 build,而不是散在每個設計師的記憶裡。

🧠 記

  • 對比不是二元門檻,是連續量:它和字級、字重、明暗方向綁在一起。WCAG 2.x 用一個固定比值把它簡化成「過/不過」,方便稽核但不總是反映真實可讀性。
  • WCAG 2.2 AA 是今天的底線:一般文字對比比值 ≥ 4.5:1、大字 ≥ 3:1。2024 年 ADA Title II 更新讓它對很多機構是法遵要求(部分單位期限 2026)。
  • 舊比值的結構缺陷:對亮底暗字/暗底亮字一視同仁、在中間調特別失準,因為它只是兩個亮度相除。
  • APCA(WCAG 3.0 預計採用) 輸出 Lc 明度對比分數(約 0～±106),當絕對值讀、正負號只表極性;依情境分級:Lc 90(小字正文)、Lc 75(一般正文最低)、Lc 60(大字/標題最低)。
  • 兩套不相容、不可互換:過 4.5:1 的組合可能 APCA 不及格,反之亦然。沒有換算係數。
  • 務實分工:用 WCAG 2.2 AA 過稽核與法遵,用 APCA 設計真正好讀的畫面;把兩者都做進 token pipeline / CI。

✍️ 實踐

挑你手上調色盤裡三組真的會出現在正文的「前景/背景」配對(例如次要文字灰配白底、暗色模式的正文、卡片上的說明文字),做三件事:

  1. 先跑 WCAG 2.2,記下比值。 用任一對比檢查器算出每組的比值,標明過不過 4.5:1(正文)或 3:1(大字)。這是你的法遵底線,先確定沒破。
  2. 同一批再跑一次 APCA,看 Lc。 用 Chrome DevTools 的 APCA 或官方計算器,把每組的 Lc 值記下來,對正文用 Lc 75、小字用 Lc 90 當標準。特別留意那種「WCAG 剛好過、Lc 卻明顯偏低」的中間調灰字——那就是使用者讀起來最累的一批,把它調亮或加粗到 Lc 達標。
  3. 寫下你的兩層標準並收進 token。 用一兩句話定義團隊規則:「WCAG 2.2 AA 為合規門檻,APCA Lc 75/90 為正文品質門檻」,並把它掛到對應的語意 token(如 text/secondary 對 surface/default)註解上,讓下一個改色值的人一眼看到這組配對該同時滿足哪兩條線。

🔗 延伸學習

💬 問 AI

我是 UIUX 設計師,想把顏色對比同時對齊「今天的法遵」與「未來的感知品質」。請幫我:
1. 用白話解釋 WCAG 2.2 對比比值(4.5:1 / 3:1)和 APCA 的 Lc 分數在模型上有何根本差異,為什麼一組顏色過了 4.5:1 卻可能 APCA 不及格,兩者為何不能互相換算。
2. 給我一份可執行的雙層檢查流程:先用 WCAG 2.2 AA 過合規、再用 APCA(Lc 75 正文 / Lc 90 小字 / Lc 60 大字)驗閱讀品質,並示範如何把這兩層標準寫進 design token 的語意配對(如 text/secondary 對 surface/default)與 CI。
3. 針對我常用的中間調灰字(例如 #767676 配白底),說明它在兩套算式下各是什麼結果,若 APCA 偏低該往哪個方向(調亮/加粗/加大)修才最有效。
請用繁體中文(台灣用語)、能實際照做的方式回答。

反向連結