网页文字对比度怎么才算够？读懂 WCAG 的 4.5:1 与 3:1

浅灰色文字配白色背景，看起来轻盈、干净。但如果用户要眯着眼睛才能读清一段说明，这份「干净」就把阅读成本转嫁给了用户。网页对比度要解决的，正是文字和背景能否被足够清楚地区分。

先认识两个缩写：W3C 是万维网联盟（World Wide Web Consortium），负责推动 Web 标准；WCAG 是《Web 内容无障碍指南》（Web Content Accessibility Guidelines），由 W3C 的 Web 无障碍倡议相关工作组制定，为网页内容能否被更多人使用提供可检验的标准。简单说，W3C 是制定标准的组织，WCAG 是其中一套无障碍标准。

WCAG 2.2 成功标准 1.4.3「对比度（最低）」给出了一个可检验的底线：普通文字及文字图片至少 4.5:1，大字号文字至少 3:1。它属于 AA 级标准。下面把这两个数字拆开，看看实际做页面时该怎么用。

4.5:1 究竟在比什么？

这里比较的是文字与其背景的相对亮度，不是 RGB 数值相差多少，也不是颜色看上去有多「鲜艳」。按 WCAG 的计算公式，对比度比值的范围是 1:1 到 21:1：

• 最小值 1:1：两种颜色的相对亮度相同，例如白字放在白底上。即便色相不同，只要相对亮度相同，比值仍是 1:1；仅靠亮度无法把它们区分开。
• 最大值 21:1：一方是相对亮度为 1 的纯白，另一方是相对亮度为 0 的纯黑。黑字白底和白字黑底的计算结果相同，都是 21:1。

比值越大，两种颜色的亮度差越大，但并不是所有文字都必须追求 21:1。普通文字达到 4.5:1、大字号文字达到 3:1，才是这条 AA 级标准规定的最低门槛。

计算时，先分别求两种颜色的相对亮度，再把较亮的记作 L1，较暗的记作 L2：

对比度 = (L1 + 0.05) / (L2 + 0.05)，其中 L1 ≥ L2

相对亮度的范围是 0 到 1。对于网页常用的 sRGB 颜色，先把每个 8 位通道值除以 255，得到 c；再将红、绿、蓝三个通道分别按下式转换为线性值 R、G、B：

若 c ≤ 0.04045：线性值 = c / 12.92
若 c > 0.04045：线性值 = ((c + 0.055) / 1.055) ^ 2.4

相对亮度 L = 0.2126 × R + 0.7152 × G + 0.0722 × B

绿通道的权重最高，因此只看十六进制色值，甚至只看颜色的色相，都无法可靠判断文字是否达标。实际工作中可以交给工具计算，但知道这几步，才能看懂工具为什么给出这个结果。

算一个具体例子。 白色背景 #FFFFFF 的相对亮度是 1。灰色文字 #777777 的三个通道都是十进制 119，归一化后约为 119 / 255 = 0.46667；经过线性化，各通道约为 0.184475。三个通道的权重之和为 1，所以这块灰色的相对亮度也是 0.184475。代入公式：

(1 + 0.05) / (0.184475 + 0.05) ≈ 4.478:1

这组颜色没有达到普通文字所需的 4.5:1，但超过了大字号文字的 3:1。把文字稍微加深为 #767676，对白色的对比度约为 4.542:1，普通文字就过线了。若用 #595959，结果约为 7.005:1，也达到普通文字的 AAA 增强对比度门槛。这里的结果按未四舍五入的计算值判断。

这也是为什么「我觉得能看清」不能代替测量：不同人的视力、对比敏感度和阅读环境并不一样。WCAG 设置 4.5:1 的目的，是让中度低视力或对比敏感度下降的人，在不依赖增强对比度的辅助技术时，也更容易读到文字。4.5:1 是门槛，不是保证每个人在每种环境中都读得舒服的上限。

哪些文字可以用 3:1？

大字号文字的笔画通常更容易辨认，因此标准把它的最低比值降到 3:1。WCAG 所说的「大字号」是至少 18pt 的常规文字，或至少 14pt 的粗体文字。按 CSS 单位换算，分别约为 24px 和 18.5px。对于中文等 CJK 字体，标准使用与这些尺寸相当的字号判断；极细或造型特殊的字体，即便名义尺寸够大，也可能难读。

不要把「这是标题」直接等同于大字号。一行 18px 的普通字重标题，不能因为语义是标题，就按 3:1 验收。反过来，字号达标的真实大标题可以使用 3:1，但如果笔画很细，选择更高对比度通常更稳妥。

还有一个容易忽略的细节：阈值不能四舍五入。计算结果为 4.499:1，仍未达到 4.5:1。设计颜色时留一点余量，也能减少字体抗锯齿带来的实际观感差异。

例外不等于「浅色文字都可以」

1.4.3 对几类内容没有文字对比度要求：不可操作的禁用组件中的文字、纯装饰文字、所有人都看不到的文字、作为其他视觉内容一部分的偶然文字，以及 logo 或品牌名称中的文字。

但占位符、鼠标悬停提示、键盘聚焦时出现的文字仍在适用范围内。真正承担说明作用的图片文字，也要按文字检查。把一句关键信息烘焙进图片，不会让它自动变成例外。W3C 同时建议尽量使用真实文字，因为图片文字不方便缩放，也更难由用户调整颜色。

按钮的图标、输入框边框、图表中的关键线条则属于另一条规则：WCAG 1.4.11「非文本对比度」。需要识别控件、状态或理解图形的视觉信息，通常至少要与相邻颜色达到 3:1。不要把这条规则的 3:1 直接套到按钮上的小字：按钮文字仍按文字标准检查。

一个前端验收流程

先列出页面真正出现的文字组合，而不是只检查设计稿里的两枚色块。正文、辅助说明、链接、按钮、表单占位符、错误消息，以及 hover、focus、选中等状态都值得走一遍；浅色和深色主题要分别检查。

然后用浏览器开发者工具或对比度检查工具，读取最终显示在文字后面的背景色，测量文字与背景的比值。半透明文字要先与背景合成；背景是图片或渐变时，要检查文字所在区域可能遇到的低对比度位置。只有 color、没有明确 background-color，或反过来，也容易因用户默认颜色不同而出问题。

最后按文字大小选择门槛：普通文字 4.5:1，大字号文字 3:1。若目标是更高的 WCAG AAA 级「增强对比度」，普通文字的门槛提高到 7:1，大字号文字提高到 4.5:1。自动化扫描可以帮忙发现问题，但图片背景、透明叠加和状态切换仍需要人工核对实际画面。

最实用的做法，是在设计系统里为正文、次要文字、链接和状态文字预先定好能过线的前景与背景组合，再检查每个组件实际落在哪种背景上。这样，对比度才不会变成页面做完后逐个修补的颜色问题。

参考资料

• W3C WAI：Understanding SC 1.4.3 Contrast (Minimum)
• W3C WAI：Understanding SC 1.4.11 Non-text Contrast
• W3C WAI：Understanding SC 1.4.6 Contrast (Enhanced)