真实产品设计中的 WCAG 对比度——案例与陷阱

对比度其实在量什么

WCAG 对比度比较两个颜色——文字与其背景——的相对亮度（relative luminance），尺度从 1:1（相同）到 21:1（纯黑配纯白）。公式是 (L1 + 0.05) / (L2 + 0.05)，其中 L1 是较亮颜色的亮度、L2 是较暗的。关键词是亮度，不是色相：对比讲的是颜色有多亮或多暗，而非它们看起来有多不同。

这就是为何两个鲜明、明显不同的颜色仍可能失败。一个中红和一个中绿可以落在几乎相同的亮度，得出接近 1:1 的比值——一个的文字配另一个的背景几乎无法阅读，即使它们是“不同颜色”。对比和色彩鲜艳度并非同一回事。

精确的门槛

WCAG 2 的 AA 等级要求普通文字 4.5:1、大型文字 3:1。大型定义为至少 24px（18pt），或粗体时 18.66px（14pt）——更小的像素尺寸只有在粗体时才算“大型”。AAA 等级把这提高到普通 7:1、大型 4.5:1。

有一条人们会忘的独立规则：成功准则 1.4.11（非文字对比）要求用户界面组件与有意义的图形——按钮边框、输入框外框、图标、焦点指示——对其相邻颜色达 3:1。被禁用的控件免除对比下限，但这个豁免常被滥用，用来合理化难以看见的非激活状态。

真实设计在哪里失败

最常见的失败是以“优雅”之名在白底上用浅灰正文。像 #999999 这样的中灰配白只有约 2.8:1——直接不过 AA。占位文字通常更浅、几乎从不通过，团队却经常把真正的指示放进去。

品牌色是另一个陷阱：大量中间调的品牌色板，按钮标签配白底时无法过 AA，所以标签得变深、或按钮得变深。配在主视觉图片或渐变上的文字是最微妙的情况——对比度逐像素变化，所以一段说明文字可能在照片的暗部通过、在亮部失败。深色模式也常被忘记：低对比的深灰配黑，和它的浅色模式表亲一样不及格。

检测器抓不到的陷阱

对比检测器比较两个纯色，但真实文字不是纯色。一个用普通字重通过的比值，在发丝或细字体里可能读起来很差，因为数学忽略了笔画宽度——细字形在屏幕上的墨量比比值所暗示的少。小的抗锯齿文字在边缘也实质降低了对比。

还有两个陷阱：把大型文字豁免套用到粗体但仍很小的文字（它必须达到尺寸门槛），以及把通过的比值当成完整的无障碍。对比（1.4.3）与不单靠颜色（1.4.1）是分开的要求——一个对比通过、却只靠颜色和正文区分的链接仍然失败。永远在最坏情况的像素上测试配在图片和渐变上的文字，而非平均。

今天用 WCAG 2，明天看 APCA

WCAG 2 的比值有用但不完美。因为它不建模字体大小、字重，或人眼实际如何感知亮配暗对暗配亮，它对某些亮色文字组合可能太严、对某些暗色组合太宽。设计师在一个配对“看起来没问题”却失败、或“看起来太细”却通过时，就会感受到这点。

提议的替代是 APCA（Accessible Perceptual Contrast Algorithm，无障碍感知对比算法），为未来的 WCAG 3 而探索。APCA 把文字大小、字重和对比极性纳入权重，力求更贴近感知。它尚未具规范性——你不能依它主张符合性。务实的立场是：今天交付到 WCAG 2 AA，并留意 APCA 标准的走向。

要点

记住两个数字：正文 4.5:1、大型文字与 UI 组件 3:1。 多数决定都回到这两个。

别相信灰配白的“优雅”——#999 配白不过 AA；交付前先检查。

在最坏的像素上测试配在图片和渐变上的文字，而非平均，因为比值会在区域内变化。

用发丝字体通过的比值对真实读者仍然失败——要考虑字重和大小，而非只看数字。

对比与颜色独立性是分开的要求——永远别把颜色当成唯一信号。本站的色彩对比检测器会为任何配对计算 WCAG 2 比值与 AA/AAA 结果。