一句话概括
色彩对比度，就是一个通过数学方法衡量两种颜色“看起来”亮度差多少的指标，目的是确保不同视力的人都能看清文字。
它解决了什么问题
有没有试过在太阳底下眯着眼看手机，就为了看清屏幕上的字？或者有没有在心里吐槽过哪个设计师，把浅灰色文字放在一个没那么浅的浅灰色背景上？恭喜你，你遇到了对比度问题。
几十年来，为了让屏幕上的东西“看起来很酷”，往往牺牲了可读性。随着互联网成为我们生活中不可或缺的一部分——银行、医疗、教育、社交——人们越来越清楚地认识到，这不仅仅是品味问题，更是个访问权的问题。
于是，Web 无障碍倡议 (WAI) 闪亮登场。这项目就是由那帮制定 Web 标准的大佬们 (W3C) 搞的。他们创建了《Web 内容无障碍指南》（简称 WCAG），这是一套技术标准，旨在让每个人，无论能力如何，都能使用网络。这可不是什么“锦上添花”的东西；在许多国家，这对公共和商业网站来说是一项法律要求。
从根本上说，问题在于人类的视觉千差万别。有些人有色觉缺陷（通常说的“色盲”这个词往往不准确），有些人视力不佳，而且每个人的视力都会随着年龄增长，甚至只是盯着屏幕一整天而变化。对比度检查提供了一个通用的、客观的衡量标准。它将对话从“我觉得这个能看清”转变为“这个在数学上被证明，在大多数情况下对绝大多数用户都是可读的”。这关乎创建一个在真实世界中为真实人类服务的网络，而不仅仅是为待在小黑屋里用着完美校准的 4K 显示器的设计师服务。
底层工作原理
你可能觉得凭“肉眼”就能判断对比度，但我们的大脑是出了名的容易被骗。WCAG 标准使用一个精确的、基于感知的公式来得出一个客观的分数。来，咱们掀开引擎盖瞅瞅。
### 从十六进制码到光
网页上的一个颜色，比如 #FFD700 (金色) 或 rgb(255, 215, 0)，其实就是给你屏幕的一组指令，告诉像素要发出多少红、绿、蓝光。第一步是把这些 0-255 的值转换成一个标准化的线性尺度。
但坑爹的是，我们对亮度的感知并不是线性的。像素值从 10 跳到 20 的感觉，要比从 240 跳到 250 的感觉大得多。为了解决这个问题，公式首先将 RGB 值归一化到 0-1 的范围，然后对其进行调整以更好地匹配人类的感知。这个过程的简化版是 C_linear = (C_sRGB / 255) ^ 2.2。这个过程实际上“撤销”了大多数图像和显示格式中内置的伽马校正。
### 相对亮度的数学
一旦我们有了线性的 RGB 值，我们就可以计算一个颜色的“相对亮度”(Y)。这玩意儿就是秘方。它是一个数字，代表了一个颜色在人眼看来有多亮。
你可能会觉得我们只要把 R、G、B 的值取个平均就行了，但我们的眼睛很奇特。我们对绿色的敏感度远超蓝色。这个公式就反映了这种生理现实：
Y = (0.2126 * R_linear) + (0.7152 * G_linear) + (0.0722 * B_linear)
注意看这些系数：绿色占的比重最大 (0.7152)，而蓝色则很小 (0.0722)。这简直就是个“为你眼球准备的 API”，把一个数字信号转换成一个近似于人类生物反应的值。
### 对比度公式
现在到了简单的部分。一旦你有了两种颜色的相对亮度——我们把亮的那个叫 Y1，暗的那个叫 Y2——对比度公式就非常直观了：
Contrast Ratio = (Y1 + 0.05) / (Y2 + 0.05)
这个小小的 + 0.05 常数是个聪明的调整。如果你要跟纯黑（亮度为 0）比较，它能防止除以零的错误，同时也有助于解决渲染中的一些复杂情况。最终结果是一个从 1:1（白底白字）到 21:1（白底黑字）的数字。
### AA 和 AAA 是啥？
一个比率只是个数字。WCAG 给了我们一个门槛，用来判断什么才算“无障碍”。它们被分为两个主要的“一致性级别”。
| 等级 | 普通文本 (~16px) | 大号文本 (>24px 或 18.5px 粗体) | 描述 |
|---|---|---|---|
| AA | 4.5:1 | 3:1 | 行业标准。对大多数内容来说都不错。 |
| AAA | 7:1 | 4.5:1 | “黄金标准”。为了达到最佳可读性，通常用于特殊场景。 |
关键是，“大号文本”的门槛更低，因为它的尺寸本身就让阅读变得更容易。另外，这些规则不适用于纯装饰性的文本或 logo，因为在那些地方，可读性不是主要功能。
真实世界的“翻车”故事
### 时髦创业公司的上线日噩梦
一家新的 SaaS 创业公司在品牌上砸了一大笔钱。他们的网站是个极简主义的杰作：微妙的米白色背景，炭灰色正文，链接是时髦的低饱和度灰蓝色。他们自己很喜欢。他们的投资人也很喜欢。但在上线那天，Twitter 上的用户可不买账。反馈如潮水般涌来：“找不到定价在哪儿”、“你们的注册按钮是禁用的吗？”、“我真的看不清你们的功能列表”。那个在 Figma 里看起来如此高大上的设计，在现实世界中却是一场可用性灾难。一个抓狂的开发者最后把颜色扔进对比度检查工具，发现网站上到处都是 2.2:1 和 1.8:1 这样的比率。他们花了整个上线夜，给 CSS 打补丁，换上更深的文本颜色和更醒目的蓝色。
**教训：**让用户没法给你钱的“时髦”设计，就是烂设计。永远在上线前测试你核心品牌色的无障碍性。
### 消失的结算按钮奇案
一家电商网站很困惑。分析数据显示，大量用户在手机上把商品加入了购物车，但在最后的结算页面放弃了购买。他们做了各种 A/B 测试：按钮文案（“确认购买” vs “立即购买”）、位置、周围的文字。啥用都没有。最后，一个暑期实习生建议检查一下颜色对比度。那个按钮是可爱的薄荷绿色，配上白色文字。它的对比度？惨不忍睹的 1.9:1。在户外明亮的手机屏幕上，文字基本上是隐形的。他们把文字颜色改成了深海军蓝，对比度达到了 6.5:1。一周之内，那个页面的转化率大幅飙升。
**教训：**你最关键的行动号召（call-to-action）必须是“防弹”级别的。要假设用户会在阳光直射下，用一个满是污迹的手机屏幕来看它，并为这种现实情况做设计。
### 计划外的“擦屁股”项目
一所大型大学推出了一个全新的学生门户网站。六个月后，大学的法务部门收到了一家残障权利组织的正式投诉，指控其不符合无障碍法律。一个主要的争议点就是门户网站的配色方案。显示课程表和成绩的数据表格，行与行之间交替使用浅蓝色和白色，文字是标准的黑色。蓝色背景配黑色文字，未能通过 AA 对比度标准，这让低视力学生很难解析这些密集的信息。大学不得不从新功能开发中抽调资源，投入到一个昂贵且紧急的“无障碍修复”项目中。
**教训：**无障碍性不仅仅是个好主意，它通常是法律。主动检查比被动地应付法律和技术修复要便宜无数倍，压力也小得多。
常见错误和陷阱
- **在截图上用取色器。**这绝对会不准。截图可能有不同的颜色配置文件，而且取色器可能会吸到文本和背景之间的抗锯齿像素。一定要用你 CSS 里的确切十六进制或 RGB 值。
- **忘记交互状态。**你默认的链接颜色可能没问题，但它的
:hover、:focus或:visited状态呢？一个低对比度的焦点轮廓（focus outline）对键盘用户来说是个大问题，让他们根本看不清自己在哪儿。 - **忽略图片上的文字。**把文字直接放在背景图上，简直是颜色对比度的终极 Boss。图片的某一部分可能提供了足够的对比度，但另一部分可能就不够了。标准的修复方法是在图片上加一个半透明的覆盖层（或叫“纱罩”，scrim），或者给文字加上实色的文本阴影，来确保文字有一个可以稳定检查的背景。
- **把对比度比率当成一个非黑即白的及格线。**一个颜色组合就算以 4.51:1 的比率通过了测试，也不意味着它就是个好选择。比如，非常细的字体即使分数及格了也可能很难读。要把 WCAG 标准当作一个基线，而不是常识的替代品。
- **觉得“这不归我管”。**设计师选颜色，开发者实现，QA 测试。产品团队里的每个人都对无障碍性负有责任。一个能在设计稿里发现低对比度颜色，并在写代码之前就指出来的开发者，简直是英雄。
为什么你应该关注它
这可不是什么一年用一次的冷门工具。你应该时时刻刻都想着颜色对比度：
- **设计交接时：**拿到新的 UI 设计稿，花 30 秒对颜色做个“理智检查”。
- **写 CSS 时：**每当你敲下
color和background-color，你都在做一个关于无障碍性的决定。 - **在组件库里：**把无障碍的颜色组合构建到你的核心
Button、Tag和Input组件中，这样每个使用它们的开发者都能“免费”获得无障碍性。 - **代码审查（Code Review）时：**对比度问题的 Lint 检查可以自动化。这是一个简单、高回报的检查项，你可以加到团队的流程里。
归根结底，检查对比度是能对你的产品可用性产生巨大积极影响的最快、最简单的方法之一。这一个十秒钟的检查，可能就是用户成功完成任务和在一肚子火中放弃之间的区别。
深入探索
- WCAG 2.2：对比度（最低要求） — W3C 的官方规范。这就是“真理之源”。
- MDN：颜色与无障碍性 — Mozilla 出品的优秀开发者指南，教你理解并满足对比度要求。
- Can't Unsee：Alex Holachek 的博客 — 一篇极好的深度好文，探讨了为什么数学公式是现在这样，以及感知对比度的重要性。
- WhoCanUse — 一个实用的工具，可以展示你的颜色组合对不同类型视觉缺陷的人有何影响，提供的背景信息远不止一个比率。
- 维基百科：sRGB — 献给那些想深入了解几乎所有网络显示内容底层颜色空间的人。