AIColors

免费工具 · 无需注册

颜色对比度检测器 — WCAG 2.2 与 APCA

一处同时检测 WCAG 2.2 与 APCA，提供四种字号的实时预览，模拟三种常见色盲，并给出保持品牌色相的修复建议。

实时预览

12px · 小号正文 — 敏捷的棕色狐狸跃过了懒狗。

16px · 正文 — 敏捷的棕色狐狸跃过了懒狗。

24px bold · 副标题

主标题

WCAG 2.2 对比度

14.06:1
AA · 正文通过
AA · 大号文字通过
AAA · 正文通过
AAA · 大号文字通过
AA · 界面控件 / 图形通过

APCA（WCAG 3 草案）

98.5Lc
APCA 评分AAA · any size
  • Lc 90+AAA / any size
  • Lc 75+Body text · 14–18px
  • Lc 60+Large or bold body
  • Lc 45+Headings · non-text
  • Lc 30+Minimum visibility

APCA 区分文字与背景，并把字号、字重、明暗极性纳入计算。Lc 越大越易读。不要把 APCA Lc 与 WCAG 数值直接比较。

色盲预览

Aa
正常视觉
Aa
红色盲（Protanopia）
Aa
绿色盲（Deuteranopia）
Aa
蓝色盲（Tritanopia）

近似模拟，仅用于排查明显问题，不能替代真实用户测试。

三步得到真正可靠的对比度

1

选取两种颜色

可以输入色值、粘贴、或使用取色器，支持 #fff 这样的三位简写。预览会实时更新。

2

两个数字都要看，不要只看一个

WCAG 2.2 比率告诉你能否通过合规审计；APCA Lc 告诉你真实用户能否轻松阅读。二者作用不同，都重要。

3

应用修复建议或一键分享

若某组合未通过 AA，我们会在 OKLCH 色彩空间沿亮度轴搜索，给出保持原色相、最接近原色的合规备选。URL 会同步更新，可直接发给同事评审。

对比度速查表

每个人都会忘的最低标准。打印出来贴在墙上，下次设计评审就不用再争。

用途 WCAG AA WCAG AAA APCA（非正式）
正文（小于 18px，或小于 14px 加粗）4.5:17:1Lc 75
大号文字（≥18px，或 ≥14px 加粗）3:14.5:1Lc 60
界面控件、表单边框、焦点环3:1—Lc 45
承载语义的图标3:1—Lc 60
关键法律文本与密集数据表——Lc 90+

如何读懂这两个数字

WCAG 2.2 对比度比率

WCAG 2.2 将对比度定义为两色相对亮度之比，从 1:1（完全相同）到 21:1（纯黑与纯白）。算法本身不区分前景与背景，只看亮度差。

门槛简单粗暴：正文 4.5:1，大号文字或非文字 UI 3:1。这是大多数国家的法定底线（美国 Section 508、欧盟 EAA 等）——但仅仅压线 4.5:1 的组合，往往读起来仍然吃力。

APCA 亮度对比度

APCA 是为 WCAG 3 草案设计的新算法。它返回的不是一个比率，而是介于 -108 到 +106 之间的有符号数——绝对值（Lc）表示可用对比度，符号表示文字相对背景是更深还是更浅。

APCA 弥补了 WCAG 2.2 忽略的三件事：字号、字重、明暗极性。14px 常规字重需要 Lc 75；24px 加粗标题在 Lc 60 就足够。当 APCA 与 WCAG 给出不同结论时，请相信你的眼睛——APCA 通常更接近真实的可读性。

我们的看法

WCAG 2.2 让你通过合规审计，APCA 才告诉你用户能不能读懂

大多数对比度工具强迫你二选一。我们不这么做，因为两种算法回答的是不同问题，而你通常两个答案都要。

把 WCAG 2.2 当作合规门。无论是采购、第三方审计还是政府项目，引用的仍是 4.5:1 / 3:1，未来两年都不会变。如果配色没过 AA，那它先是个法律问题，其次才是设计问题。

把 APCA 当作设计门。WCAG 2.2 的数学源自 2008 年，有公认的盲点：高估了深色文字配高饱和中明度背景的可读性，也低估了实际易读的浅文字配深背景。APCA 正是为补这些坑而生。当 WCAG 不通过但 APCA Lc 75+ 时，文字其实读起来没问题；当 WCAG 通过但 APCA 低于 60 时，用户一定会眯眼。

结论

尽量同时通过两者。无法兼顾时，先满足 WCAG 2.2 以保合规，再用 APCA 预判用户会不会抱怨。

设计师反复掉进的四个对比度陷阱

我们在每周的设计评审中都能见到这些。每一种都能糊弄过非正式的检查，但读者会受罪。

礼貌的浅灰

#A0A0A0 on #FFFFFF

白底浅灰在 Figma 里看着很高级。压线通过 4.5:1，到手机屏幕的中午阳光下就完全消失。正文实际取至少 5.5:1，你永远不会再收到无障碍工单。

测试这组配色 →

品牌色叠品牌色

#7E57C2 on #3949AB

两个高饱和品牌色相邻时，几乎都过不了 WCAG 和 APCA。饱和度会骗设计师以为有对比，其实亮度太接近。永远让一边是中性色。

测试这组配色 →

白字配黄 / 浅橙

#FFFFFF on #FFC107

警告横幅的经典翻车。纯白配琥珀色看着醒目，对比度其实只有 1.7:1，远低于任何文字的最低标准。应改为黄底深字。

测试这组配色 →

深色模式的"中度"灰

#9E9E9E on #212121

做深色模式时，设计师常直接复用浅色模式的 #9E9E9E，丢到 #212121 上。WCAG 算 4.5:1 刚好达标。但 APCA 因极性惩罚把它压到 Lc 60 以下。深色模式的正文应该比直觉中更亮。

测试这组配色 →

常见问题

这个对比度检测器是免费的吗？
完全免费，无需注册，无广告，也不会上传任何设计稿。所有计算都在浏览器本地完成。
为什么其他工具只显示一种算法，你们要同时显示 WCAG 和 APCA？
因为它们测的不是同一件事。WCAG 2.2 是大多数国家的法律要求；APCA 更准确地预测实际阅读体验。同时展示，让你能基于完整信息判断，而不是被某个工具单方面选定的算法限制视野。
"应用修复建议"按钮到底做了什么？
它沿着前景色的 OKLCH 亮度轴搜索——保持色相和饱和度不变——直到组合通过 WCAG AA。OKLCH 是感知均匀的色彩空间，所以建议出来的颜色和你的原色看起来仍是同一色族。基于 HSL 的"修复"经常会让色相在取色器里看不出但屏幕上明显偏移。
WCAG AA 和 AAA 有什么区别？
AA 要求正文 4.5:1、大号文字 3:1，这是法律基线、也是几乎所有无障碍审计的检测标准。AAA 更严格（7:1 / 4.5:1），通常只在政府健康类信息等特殊场景才被强制要求。
WCAG 里所谓的"大号文字"到底多大？
18pt（约 24px）以上的常规字重，或 14pt（约 18.66px）以上的加粗。任何更小的字号都按正文标准走，必须达到 4.5:1。
这个工具支持半透明 / alpha 颜色吗？
暂时不支持，当前版本假设两色都不透明。如果你要检测半透明文字，先把它在实际背景上的渲染色取出来——浏览器开发者工具一般能直接给出。
色盲模拟是医学级精确的吗？
不是。我们用的是常见的 Brettel/Viénot/Mollon 矩阵近似，足够帮你发现界面里的明显问题，但不能替代真实色盲用户的测试。约 8% 的男性和 0.5% 的女性存在某种色觉障碍，为他们设计不是可选项。
能把检测结果分享给团队吗？
可以。点击"分享"按钮，当前的配色就会被编码进 URL（#fg=...&bg=...）。打开链接的人会看到同样的颜色组合，可以直接贴进 Slack 或设计工单。
为什么 WCAG 通过而 APCA 不过（或反过来）？
因为两套算法不同。WCAG 2.2 用固定的亮度比；APCA 用考虑极性、字号、字重的感知模型。它们的分歧通常很有信息量："WCAG 过 / APCA 不过"多见于浅色文字配深色背景但实际偏细弱；"WCAG 不过 / APCA 过"偶尔出现在中明度的品牌色上，眼睛读起来其实没问题。
有 API 吗？
暂时没有。两种算法的核心代码加起来不到 100 行，我们在考虑未来开源。如果你有使用场景，欢迎来信。

搭配我们的其他色彩工具

AI 调色板生成器

输入一种情绪或主题，立刻得到完整的 5 色配色方案。把任意两色再带回本工具，就能验证正文 / 标题搭配是否达标。