如何在不安装任何工具的情况下审计颜色对比度

颜色对比度审计常常被当作一项专业的无障碍任务：打开设计文件、安装插件、导出截图、运行报告，然后围绕品牌色争论。这些做法可能有用，但并不是大多数团队应该开始的地方。

对于生产网站，最快且可靠的审计通常可以在你已经打开的浏览器中完成。现代浏览器 DevTools 可以检查计算后的颜色、显示对比度、揭示状态样式，并帮助你测试自动化报告容易漏掉的棘手情况。

本指南假设你不安装任何东西。不使用浏览器扩展。不使用设计插件。不使用付费审计套件。只有页面、浏览器和一个简单方法。

你真正需要的对比度规则

对于大多数 Web 工作，WCAG 对比度可以归结为几个阈值：

• 普通文本：与背景的对比度至少为 4.5:1。
• 大号文本：至少为 3:1。WCAG 将其定义为约 24 CSS 像素，或在加粗时约 18.66 CSS 像素。
• UI 组件和图形对象：对于有意义的边界、图标、状态，以及理解界面所需的图表部分，至少为 3:1。
• 增强对比度：如果你的目标高于基线，普通文本为 7:1，大号文本为 4.5:1。

也有一些例外，例如非活动控件、装饰性元素和徽标。请谨慎使用这些例外。“这是品牌的一部分”不是例外；它是一个设计约束。

还要记住，对比度只是无障碍色彩使用的一部分。如果红色错误状态具有足够对比度，但没有文本、图标标签或程序化提示，它仍然可能让无法区分红色与相近颜色的用户受阻。

从渲染后的页面开始，而不是设计文件

设计文件很有用，但它们不包含所有真实世界变量：CSS 覆盖、透明度、悬停状态、浏览器字体渲染、用户缩放、深色模式、继承样式、CMS 内容和营销嵌入内容。

请审计用户实际接收到的页面。

在当前的桌面浏览器中打开页面。Chrome、Edge、Firefox 和 Safari 都有实用的检查工具。具体标签不同，但流程相同：

1. 右键单击文本或 UI 元素。
2. 选择 Inspect。
3. 找到计算后的 color 和 background-color。
4. 使用浏览器的颜色色块或无障碍面板读取对比度。
5. 记录通过、失败和不确定项。

在基于 Chromium 的浏览器中，颜色选择器通常会显示对比度以及文本的 WCAG 通过/失败指引。Firefox DevTools 也会提供无障碍信息和颜色工具。Safari’s Web Inspector 可以显示计算样式和无障碍信息，不过流程略有不同。

关键不在于具体使用哪个浏览器。关键是读取计算后的结果，而不是某人以为该组件使用的值。

先建立一份小型审计列表

不要随意检查文本直到疲惫为止。先列出一份简短的模式清单：

• 主页面背景上的正文文本。
• 弱化文本、说明文字、元数据和占位符。
• 正常、悬停、已访问和焦点状态下的链接。
• 主要、次要和破坏性按钮。
• 表单标签、帮助文本、错误和成功消息。
• 导航项、面包屑和选项卡。
• 卡片、徽章、胶囊标签和标签。
• 传达含义的图标。
• 图表、地图、进度条和状态颜色。
• 图片、视频、渐变或半透明叠加层上的文本。

这足以发现典型网站上的大多数问题。它还能让审计与组件关联起来，而不是与一次性的像素关联。

如果你的审计包含按钮，请将对比度检查与 我们的无障碍 Web 按钮清单 中的基础项配合使用。按钮对比度问题往往与缺失的焦点状态、不清晰的标签或损坏的键盘行为相邻出现。

在 DevTools 中检查文本对比度

对于纯色背景上的普通文本，浏览器通常可以为你计算对比度。

检查元素并查找 color 属性。从色块打开颜色选择器。如果浏览器可以确定背景，它会显示对比度。有些工具还会在颜色选择器中绘制一条线，显示该颜色在哪些位置可以通过 3:1、4.5:1 或 7:1。

当浏览器报告失败时，先相信它，除非你能证明并非如此。当它报告通过时，仍要使用判断力。小而细的字体、低质量显示器、较重的抗锯齿以及繁忙背景，都可能让技术上通过的文本感觉偏弱。

一个实用规则是：如果正文文本只是勉强以 4.55:1 通过，不要庆祝。给它更多余量。对比度要求是最低值，不是理想目标。

排版也很重要。更大、更清晰的字体系统可以在你调整颜色之前就减少阅读负担。如果页面尽管通过了对比度检查，读起来仍然困难，请从更广的可读性视角重新审视行长、字号、字重和间距，例如参考 这份现代 Web 可读字体实用指南。

检查真实背景，包括透明度

许多对比度错误的发生，是因为可见背景并不是声明的背景。

常见陷阱包括：

• 半透明卡片内的文本。
• 应用了 opacity 的父元素上的文本。
• 使用 rgba() 或 color-mix() 的叠加层。
• 标题背后的渐变。
• 在文本区域内变化的背景图片。
• 在深色模式下变化的主题变量。

如果 DevTools 无法可靠地计算对比度，请手动识别渲染后的前景色和背景色。使用计算样式面板，临时禁用图层，或者在浏览器支持的情况下使用内置颜色选择器采样可见颜色。

对于图片上的文本，不要采样图片中最理想的部分。采样文本背后最可能出现问题的区域。如果图片会通过 CMS 上传、轮播或响应式裁剪而变化，那么这不是一个稳定的对比度系统。请添加可靠的叠加层、文字阴影、实色容器或渐变处理，确保无论图片如何变化，文本都受到保护。

一个好的图片叠加系统应该很“无聊”：相同的叠加强度、可预测的裁剪区域，即使是明亮照片也有足够对比度。无聊没关系。用户只是想阅读。

不要忘记状态

静态截图会漏掉许多对比度失败。请直接在浏览器中审计交互状态。

在 DevTools 中，强制使用如下伪类：

• :hover
• :focus
• :focus-visible
• :active
• :visited
• :disabled
• :checked
• :invalid

然后再次检查计算后的颜色。

焦点指示器值得特别关注。WCAG 2.2 强化了对焦点外观的预期，而浅灰色卡片上的浅蓝色轮廓仍然是常见失败。焦点指示器需要与相邻颜色有足够对比度，并且有足够面积以便被注意到。

对于禁用控件，WCAG 对比度规则对非活动组件有例外。这并不意味着禁用控件默认就应该难以辨认。如果禁用状态承载有用信息，请让它可读。如果没有，请考虑它是否应该存在。

使用 Lighthouse，但不要把判断外包给它

像 Lighthouse 这样的浏览器审计可以快速捕捉一些对比度失败。如果你的浏览器提供内置审计，请运行它，然后将结果视为起点。

自动化检查擅长发现具有明显计算对比度失败的文本节点。它们较弱的地方包括：

• 嵌入图片中的文本。
• Canvas 渲染的标签。
• SVG 边缘情况。
• 仅在悬停时出现的失败。
• 焦点指示器质量。
• 颜色关系承载含义的图表。
• 隐藏在身份验证、菜单或表单步骤后面的组件。

如果报告全绿，你仍然需要检查有代表性的组件。如果报告变红，不要慌张，而应按用户影响对失败项进行分诊。这个原则同样适用于性能和无障碍报告：把工具输出当作证据，而不是裁决。我们在 如何不慌张地阅读 Lighthouse 报告指南 中使用了这种思路，它在这里同样适用。

也要审计非文本对比度

文本获得了最多关注，但 WCAG 也涵盖理解或操作界面所需的非文本内容。

至少检查这些情况：

• 输入框边框与页面背景。
• 复选框和单选框轮廓。
• 开关状态。
• 仅图标按钮。
• 错误图标和警告符号。
• 图表线条、柱形和标签。
• 进度指示器。
• 选中的选项卡或活动导航指示器。

目标通常是相对于相邻颜色达到 3:1。例如，白色背景上的浅灰色输入框边框可能几乎不可见。包含五条柔和粉彩色线条的图表可能看起来优雅，但仍然不可用。

对于图表，仅有对比度本身还不够。使用标签、图案、线型、直接标注或间距，让信息不只依赖颜色。这有助于色盲用户、低视力用户、在强光下查看的人，以及任何在文档中阅读截图的人。

用开发者可使用的格式记录发现

一份有用的对比度审计不会只写“某些灰色失败”。它会识别组件、状态、当前值、预期阈值和建议修复。

紧凑格式效果很好：

| Component | State | Foreground | Background | Ratio | Target | Result | Suggested fix | |---|---:|---:|---:|---:|---:|---|---| | 卡片元数据 | 默认 | #8A8F98 | #FFFFFF | 3.2:1 | 4.5:1 | 失败 | 使用 --color-text-muted-strong | | 主要按钮 | 悬停 | #FFFFFF | #2F6FEA | 4.8:1 | 4.5:1 | 通过 | 保持 | | 输入框边框 | 默认 | #D7DCE2 | #FFFFFF | 1.4:1 | 3:1 | 失败 | 加深边框 token |

如果网站有设计 token，请将修复与它们关联起来。如果一个薄弱 token 才是真正问题，就不要修补二十个单独组件。

让修复略强于最低要求

对比度失败往往很容易被糟糕地修复。团队把颜色轻微调整到检查器显示 4.51:1，然后继续下一项。这没有为字体渲染、透明度、浏览器差异、主题、图片变化或未来品牌编辑留下余量。

更建议使用舒适目标：

• 正文文本：在可行时接近 7:1。
• 弱化文本：如果它是真实内容，仍应高于 4.5:1。
• UI 边框和图标：明显高于 3:1。
• 图片上的文本：使用受控叠加层，而不是按图片猜测。

Web 会被人们在廉价笔记本、昏暗手机、明亮人行道、有色显示器和老化屏幕上查看。最低合规并不等于舒适阅读。

<!-- tool-cta:start -->

💡 试试这个： 检查从 DevTools 提取的对比度配对时，Color Converter 可帮助在 hex、RGB 和 HSL 之间转换，使这些值与你的审计笔记保持一致。

<!-- tool-cta:end -->

无需安装的对比度审计清单

当你需要快速但可信的审计时，使用这个顺序：

1. 在现代浏览器中打开生产页面。
2. 列出主要文本、UI 和状态模式。
3. 在 DevTools 中检查计算后的前景色和背景色。
4. 使用内置颜色选择器或无障碍面板读取对比度。
5. 强制悬停、焦点、活动、已访问和无效状态。
6. 根据最可能出问题的背景检查图片和渐变上的文本。
7. 根据 3:1 要求检查非文本 UI 部分。
8. 运行内置自动化审计作为安全网，而不是整个审计。
9. 按组件和 token 记录失败项。
10. 带余量修复，而不是刚刚跨过阈值。

这足以在不向技术栈添加另一个工具的情况下，捕捉大多数对比度问题。更高级的审计仍然有其位置，尤其适用于大型设计系统、受监管产品或复杂数据可视化。但对于许多网站，浏览器已经给出了你需要的证据。难点在于足够系统地使用它。