颜色对比度别只凭感觉：用 WCAG 把可读性检查留成报告

颜色对比度问题经常不是在设计稿里爆出来的，而是在真正使用时爆出来：投影仪一亮，浅灰字消失；暗黑模式一开， 品牌蓝压在深色背景上变得发糊；按钮边框在低亮度屏幕上看不见；客服把页面截图发给客户，客户只回一句“这行字看不清”。 这时候再争论“我觉得挺清楚”没有意义。更稳的做法是把前景色、背景色、字号场景和 WCAG 阈值放在一起检查， 用可复查的数值替代纯主观判断，再把设计取舍写进交付记录。

为什么“看着还行”不够用

颜色对比度最麻烦的一点，是它会被环境放大。你在高亮度 Mac 屏幕上看到的灰色说明文字，到了 Windows 办公屏、低亮度手机、 户外阳光、投影仪、远程会议共享画面里，可能完全是另一回事。更不用说不同用户本来就存在视力差异、色觉差异、疲劳程度和阅读距离差异。 所以我不太赞成把对比度检查当成“无障碍团队才关心的细节”。它更像最基本的阅读质量检查。

真正影响业务的往往不是正文大标题，而是那些被设计成“安静一点”的内容：价格后的补充说明、表单错误提示、禁用态按钮、侧边栏计数、 图表图例、订单状态、免责声明、优惠条件、页脚链接。它们看起来不重要，但用户做决定时经常需要它们。可读性差，轻则让用户多问一句， 重则让人误解状态、漏看限制、点错操作。

• 设计评审需要知道某组颜色能不能支撑正文、按钮和图标，而不是只看主视觉；
• 前端还原需要检查 hover、disabled、focus、dark mode 等状态，不只检查默认态；
• 上线验收需要留下具体数值和截图，避免后来只能翻聊天记录争论；
• 品牌落地需要知道主色在哪些背景上可用，哪些场景必须换深浅或加描边。

先把几个 WCAG 阈值说清楚

颜色对比度检测器会按相对亮度公式计算前景色与背景色的比值，并给出 AA、AAA、正文、大字号和界面组件判定。 对日常网页和产品界面来说，最常用的是三组数：普通正文 AA 至少 4.5:1；大字号 AA 至少 3:1；AAA 正文至少 7:1。 图标、输入框边框、按钮轮廓等非文本界面组件，通常参考 3:1 的要求。

这里有一个容易忽略的点：大字号不是“设计师觉得比较大”。WCAG 把 18pt 及以上的常规字，或 14pt 及以上的加粗字，视为大字号。 换算到网页里，大致可以理解为 24px 常规字，或约 18.66px 加粗字。低于这个范围的正文、说明、表格文字、菜单项，最好按 4.5:1 检查。

一套从设计稿到上线的检查流程

1. 1
   先列出真实颜色对

   不要只测品牌主色。把正文/背景、次要文字/背景、按钮文字/按钮底色、链接/背景、错误提示/背景、图标/背景、边框/背景都列出来。
2. 2
   在工具里输入前景色和背景色

   打开 颜色对比度检测器，填入 HEX、RGB 或常见颜色值。页面会立即显示对比度、AA / AAA 判定和可读性预览。
3. 3
   把字号场景一起记录

   同一个颜色对用于 32px 标题和 14px 注释，要求不一样。检查结果旁边要写清楚它用于正文、大字号、按钮、图标还是边框。
4. 4
   批量检测调色板

   把主色、辅助色、灰阶和状态色逐行贴进调色板区域，统一检查它们在浅色底或深色底上的表现。不要等开发逐个页面发现问题。
5. 5
   未达标时先找最小改动

   工具会给出保持色相与饱和度、沿明度方向调整的建议色。先看最小改动是否能保住品牌感，再决定是否换背景、加粗字号或改变组件结构。
6. 6
   交付前导出报告

   正式评审、客户验收或团队复盘时，Pro PDF 报告能把颜色样本、数值、判定结果、建议色和检测日期放在同一份文件里，后续更容易追溯。

最该检查的不是主按钮，而是边缘状态

很多页面的主按钮其实问题不大，因为它通常用深色底加白字，天然容易达标。真正危险的是“弱化信息”：灰色说明、占位符、禁用按钮、二级标签、 表格辅助列、卡片角标、浅色状态徽章。这些地方一旦对比度不足，用户不是觉得页面更高级，而是觉得信息在躲着自己。

表单：占位符不能替代标签

很多表单只把字段名放在 placeholder 里，颜色又设得很淡。用户一输入，提示就消失；对比度不够时，没输入前也看不清。 更稳的方式是保留独立 label，placeholder 只做示例，错误提示用足够清楚的颜色和文字说明，不要只靠红色边框。

数据表：灰色不是层级的唯一手段

表格里的辅助信息喜欢用浅灰色：单位、更新时间、来源、备注、空值说明。这里如果只靠降低明度来表达层级，很容易掉到 4.5:1 以下。 可以改用字号、字重、间距和列位置做层级，把颜色留在可读范围内。

暗黑模式：浅色主题的主色不一定能直接搬过去

很多品牌色在白底上看起来很好，到了深色背景上反而发虚，尤其是中等亮度的蓝、紫、绿。暗黑模式不是把背景改黑、文字改白就完事， 需要重新检查链接、按钮、分割线、hover、focus、图标和状态色。

图表和图标：非文本也要能被看见

图表线条、图例色块、趋势箭头、输入框边框、开关轨道、焦点轮廓，虽然不是文字，但它们承担信息和交互含义。只要用户需要靠它理解状态或完成操作， 就应该检查它和相邻背景之间是否足够清楚。

免费检查和 Pro 报告怎么分工

免费版已经能解决大多数即时判断：输入前景色和背景色，查看对比度，复制结论，下载 TXT，生成分享链接；也可以把最多 30 个调色板颜色放进来， 快速看哪些颜色在当前背景上达到 AA 正文。它适合个人自查、开发临时排错、设计评审前快速扫一轮。

Pro 的价值在于“留档”。只要这次检查要交给客户、产品、设计、前端、测试或管理者看，纯复制一段文本就容易丢上下文。 PDF 报告会把当前配色样本、对比度数值、5 项 WCAG 判定、建议色、调色板批量检测结果和检测日期放在同一份 A4 文件里。 它不是为了显得正式，而是为了让后来的人知道：当时到底测了什么，依据什么阈值，结论是什么。

品牌色不达标时，先别急着换色

品牌色很少是为了所有阅读场景设计的。一个漂亮的主色，可能适合 Logo、插画和大面积背景，却不适合直接作为 14px 正文链接； 一个轻盈的浅绿，可能适合成功状态背景，却不适合作为按钮文字。发现不达标时，不要第一反应就是“品牌色不行”。更成熟的做法是先判断这个颜色承担什么角色。

• 用于文字：优先调整明度，让它在目标背景上达到正文 AA；
• 用于背景：可以保留品牌色背景，但文字换成更深或更浅的中性色；
• 用于图标：如果图标承担状态含义，至少让它和背景、相邻颜色拉开；
• 用于装饰：装饰色可以更自由，但不要让用户误以为它是可点击或状态提示；
• 用于暗黑模式：单独建立 dark token，不要机械反转 light token。

分享链接适合讨论，PDF 适合定稿

工具支持生成带参数的分享链接，适合在评审中快速让同事打开同一组前景色和背景色。这个链接回答的是“你现在看到的这组颜色是什么”。 但如果要作为交付物，分享链接还不够，因为它不天然包含检测日期、批量结果、建议色和当时的结论。定稿阶段最好导出 PDF，把报告附在 PR、验收单或客户邮件里。

我的习惯是：讨论中发分享链接，方便大家改色；定稿时导出 PDF，避免改来改去之后没人知道最后通过的是哪一版。 如果后续还要检查页面 SEO、分享卡或响应头，可以接着用 网页 SEO 分析做页面级检查； 如果只是需要把颜色值转换成 RGB、HSL 或 CSS 变量，可以用 颜色格式转换整理交付格式。

几个常见误区，最好一开始就避开

误区一：只测白底，不测深色底

现在很多产品都有暗黑模式、深色侧边栏、图片蒙层和品牌色横幅。只测白底等于只测了一半。尤其是 hover、active、selected、disabled 这些状态， 往往会因为颜色变浅或透明度变化而掉线。

误区二：把 alpha 颜色直接当最终颜色测

对比度基于最终显示出来的颜色。半透明黑、半透明白、毛玻璃背景、图片遮罩都需要先和实际背景混合，再拿最终颜色检查。 工具会提示 alpha 不应直接作为最终结论使用，这一点在设计稿和代码还原之间尤其容易出错。

误区三：认为 AAA 才算“合格”

AAA 更严格，但不是所有界面都必须追求 AAA。长文阅读、教育、政务、医疗、老年用户占比高的页面，可以更接近 AAA； 高密度工作台、品牌视觉页和临时活动页，则需要在信息层级、品牌表达和可读性之间取舍。关键是把取舍写清楚，而不是假装没有取舍。

误区四：只改颜色，不改结构

有些问题不是换个颜色就能解决。比如按钮太小、错误提示离输入框太远、图标没有文字标签、卡片层级靠浅灰线硬撑。 对比度能帮你发现问题，但修复可能需要字号、字重、间距、布局、图标和文案一起调整。

一份可复制的颜色对比度验收清单

• 普通正文、表格文字、表单标签至少按 4.5:1 检查；
• 大标题、粗体大字和主按钮文案确认是否满足大字号条件；
• 图标、输入框边框、按钮轮廓、焦点环和状态标记按 3:1 检查；
• 浅色模式和暗黑模式分别检查，不共用一份结论；
• hover、disabled、selected、error、warning、success 状态都要抽样；
• 品牌主色、辅助色、灰阶和状态色放进调色板批量检测；
• 半透明颜色先和真实背景混合，再检查最终颜色；
• 分享链接用于讨论，PDF 报告用于定稿和留档；
• 结论里写清颜色用途，不要只写一个对比度数值。

常见问题