对比度检查
检查文字、图标、按钮、输入框边框和界面状态在背景上是否足够清晰。输入前景色和背景色后，工具会给出 WCAG 对比度、普通文本和大号文本的 AA / AAA 结果、UI 组件 AA、透明色合成后的计算结果、推荐前景色、修正候选色，以及可复制的 CSS 或审计备注。所有计算都在浏览器本地完成，未发布的品牌色和保密设计文件不会离开你的设备。适合设计评审、组件 QA、暗色模式调色、品牌色落地和无障碍问题修复。
- 同时展示普通文本 AA、AAA、大号文本和 UI 组件结果，避免只看一个分数就误判使用场景
- 支持 HEX、RGB、HSL、HWB、Lab、LCH、OKLab 和 OKLCH 输入，可直接检查设计文件或 DevTools 里的颜色值
- 会先合成半透明的前景色或背景色，再计算对比度，让结果更接近用户实际看到的效果
- 当颜色组合不合格时，会给出推荐基础色，并生成满足 AA 和 AAA 的前景色候选
- 可一键复制颜色声明和完整审计报告，方便放进 PR、设计评审和无障碍修复工单
color: #111827; background-color: #ffffff;
功能简介
从一组颜色到可以带回代码库的判断，整个流程都在一个面板里完成。每次检查都会覆盖多个 WCAG 维度，并提供可执行的修正建议，避免一个分数掩盖真实使用场景。
- 01
WCAG AA / AAA 结果矩阵
普通文本 AA、AAA、大号文本和 UI 组件结果并排展示，避免因为只看单个数字而把颜色组合批准到错误场景里。
- 02
支持多种颜色格式输入
可以直接粘贴 HEX、RGB、HSL、HWB、Lab、LCH、OKLab 或 OKLCH，不必先手动统一语法。
- 03
自动合成透明色
当颜色带有 alpha 时，工具会先把它合成到实际背景上，再计算比例，更接近浮层、半透明按钮和玻璃质感卡片的真实显示效果。
- 04
推荐文本色
工具会比较黑色和白色在当前背景上的表现，给出更安全的基础前景色，适合快速判断或紧急修复。
- 05
生成合规候选色
如果当前组合不合格，工具会沿着明度方向寻找最近的 AA 和 AAA 前景色，尽量保留品牌色相，同时提升可读性。
- 06
可复制的 CSS 和报告
可以复制用于实现的 color / background-color 声明，也可以复制完整对比度报告，用于 PR 描述、QA 工单和无障碍修复记录。
- 07
常见界面组合预设
内置正文、弱化文本、主按钮、成功按钮、危险按钮、警告徽标、链接和暗色模式文本等常见组合，方便快速参考。
- 08
按场景选择检查对象
可在普通文本、大号文本和 UI 组件之间切换，套用正确阈值。结果会立即更新，避免把 4.5:1 的文本规则误用到按钮边框上。
如何使用
流程刻意保持简短，方便放进设计走查、组件 QA、工单修复或浏览器里的快速排查中，结果也能直接带回项目。
- 01
把文本、图标或控件的颜色填到前景色，把周围表面的颜色填到背景色。
- 02
选择检查对象：正文用普通文本，大标签和标题用大号文本，边框、图标或控件状态用 UI 组件。
- 03
查看对比度和 WCAG 结果矩阵，确认这组颜色满足哪些 AA 和 AAA 目标。
- 04
如果未通过，可以先试试推荐前景色；如果想保留品牌色相，则生成 AA 或 AAA 候选色。
- 05
把 CSS 复制到样式表里，或把完整对比度报告粘贴到 PR 描述、设计评审、QA 备注或无障碍修复记录中。
功能说明
输出结果不是只给你看一个分数，而是方便团队讨论、复现，并最终沉淀进设计系统。
- 同时展示普通文本 AA、AAA、大号文本 AA、AAA 和 UI 组件 AA，让颜色组合按实际场景判断
- 为半透明覆盖层、玻璃质感卡片、半透明按钮和暗色模式层显示合成后的计算颜色
- 一键交换前景色和背景色，方便检查反色按钮、选中状态、反向标签和暗色模式变体
- 报告包含前景色、背景色、对比度和所有 WCAG 结果，可直接用于文档和团队协作
- 内置界面预设，为正文、弱化文本、链接、按钮、徽标和暗色模式文本提供快速参考
- 当前检查对象会实时影响通过 / 未通过状态，避免给小号正文套用错误阈值
- 可自然搭配颜色转换和调色板生成，从规范化颜色值推进到稳定、可访问的色阶
- 解析、合成和对比度计算全部在本地运行，适合未发布的品牌色和保密设计文件
- 结果提示会区分适合正文仅适合大号文本仅适合 UI 组件和不推荐，避免误用
- AA 和 AAA 候选色会沿明度方向微调并尽量保留品牌色相，比直接换成黑白更适合沉淀为 token
适合哪些场景
对比度检查越早发生，价值越大。最好在颜色组合被写死进 CSS 之前完成，这样沟通成本更低，也更不容易在上线后反复出现无障碍问题。
-
设计交接前检查
在视觉稿进入实现前，检查正文、标题、按钮、链接和状态标签，避免工程团队接手隐藏的无障碍负债。
-
组件库 QA
审查 Button、Input、Badge、Alert、Tabs 等组件在 default、hover、focus、disabled、selected、error 状态下的可读性，并把要求写进组件规范。
-
暗色模式调色
检查暗色表面上的正文、辅助标签、边框和图标，确认明度阶梯足够拉开，强调色也能保持可读。
-
品牌色落地
在把品牌色用于按钮、链接或强调内容前，先确认它是否满足对比度要求，并判断是否需要围绕它准备一组色阶。
-
无障碍问题修复
复现 Lighthouse、axe、手动 QA 或用户反馈中的低对比度问题，并记录最终修复方案，避免只是临时改色。
-
阅读量较大的内容页
提升博客、文档、帮助中心、商品页和长表单的可读性，这些页面的主要交互就是持续阅读。
-
落地页和活动页检查
检查首屏文案、CTA 按钮、价格标签和促销横幅，避免视觉效果在不知不觉中降低文字可读性。
-
后台主题维护
让表格、筛选器、状态标识、侧边栏和分析卡片都遵循同一套对比度基线，而不是每个模块各自漂移。
-
数据可视化调色板对齐
为图表系列色、状态色和辅助标签共享一套对比度基线，让图例和数据点保持同样清晰。
-
邮件和导出素材验证
邮件模板、PDF 报告和印刷物会经过不同渲染链路。先验证对比度，可以减少颜色下游落地后的返工。
对比度术语说明
这些术语经常出现在无障碍审计、设计系统文档和前端评审中。统一定义后，团队讨论的重点就不再是我看着还行，而是能说明为什么某组颜色不合格。
-
对比度
WCAG 使用 1:1 到 21:1 表示对比度。1:1 几乎没有差异，21:1 是最高对比度，通常对应纯黑和纯白。
-
相对亮度
对比度不是直接比较 RGB 数字。WCAG 会先把 sRGB 转换为相对亮度，再计算较亮颜色和较暗颜色之间的比例。
-
WCAG AA
大多数网站和 Web 应用常用的无障碍基线目标。普通文本至少需要 4.5:1，大号文本和 UI 组件通常需要 3:1。
-
WCAG AAA
更严格的目标。普通文本需要 7:1，更适合长篇阅读、公共服务、教育内容、文档和阅读量较大的界面。
-
普通文本与大号文本
普通文本包括正文、标签和辅助说明。大号文本通常指 18pt 及以上的常规字体，或 14pt 及以上的粗体，因为更容易识别，所以阈值较低。
-
UI 组件对比度
按钮边框、输入框轮廓、图标、选中状态和错误提示即使不是文字，也需要让用户能清楚识别。
-
透明色合成
rgba、hsla、OKLCH alpha 等带透明度的颜色，会受到下方表面的影响。先合成再计算，结果更接近页面真实渲染。
-
OKLCH 与感知亮度
OKLCH 的 lightness 比 HSL 更接近人眼感知，因此很适合用来构建可访问的色阶、暗色模式调色板和品牌色系统。
使用建议
对比度检查越是成为设计和开发流程的一部分，收益越明显，而不是等到最后才补救。下面这些做法适用于很多产品形态，可以先挑适合你们团队的部分落地。
- 正文、标签、辅助说明和错误信息建议以普通文本 AA 为基线，阅读量大的区域可以酌情向 AAA 靠拢
- 不要只靠低对比度表示禁用状态，应结合透明度、图标、文案或交互行为一起表达
- 暗色模式下，先调整明度阶梯，再提高饱和度；单纯加饱和度通常很难真正改善可读性
- 按钮、链接和状态标识要检查 default、hover、focus、selected、error、disabled 状态，不要只看一张静态截图
- 半透明覆盖层、玻璃质感卡片和浮层面板，要基于真实页面背景验证，而不是套用一个通用表面色
- 通过验证的组合建议提升为 text-primary、text-muted、surface-card、border-subtle 等设计 token，减少一次性判断
- 当品牌色不合格时，优先建立满足要求的色阶，而不是在不同页面随意挑近似替代色
- 把对比度检查加入设计评审、PR 检查清单和发布 QA，让问题更早暴露，修复成本更低
边界与注意事项
颜色对比度很重要，但它只是界面无障碍的一部分。请把结果当作强信号，而不是最终结论，并结合真实页面、真实设备和完整无障碍评审一起判断。
- 通过 WCAG 对比度不代表整体无障碍一定合格；语义结构、键盘访问、焦点可见性、错误处理和屏幕阅读器表现仍需要检查
- 图片、视频、复杂纹理或渐变上的文字，应从真实页面区域取样；单一背景色只能作为近似
- 生成的 AA 和 AAA 候选色适合快速探索，但最终颜色仍要结合品牌规则、主题色阶和视觉层级评审
- 不同显示器、浏览器、色彩管理设置和环境光都会影响可读性感知，重要页面建议在真实设备上复核
- 工具只评估你输入的颜色，不会自动扫描 CSS 变量、Tailwind 配置或设计 token 源文件
- APCA 和 WCAG 2.x 使用不同的对比度模型。本工具当前展示的是 WCAG 2.x 对比度
- 动态背景、动画背景和视频上的文字需要在播放过程中观察；静态比例无法完整覆盖这类体验
常见问题
这些是在日常工作、无障碍合规和跨职能协作中使用对比度检查时最常见的问题，涵盖入门、阈值、修复策略和限制。
颜色对比度检查器解决什么问题？
它用于确认文字、图标和控件在背景上是否保持可读。设计评审、前端实现和无障碍修复时，它能帮助你判断是否存在问题，并给出清晰的修正方向。
为什么普通文本 AA 需要 4.5:1？
WCAG 2.x 将 4.5:1 定义为普通正文的最低对比度要求。它基于相对亮度计算，而不是主观感受，因此适合作为团队共享的稳定标准。
什么时候应该目标定到 AAA？
长篇阅读、公共服务、教育内容、文档，以及特别重视可读性的产品区域更适合追求 AAA。大多数界面可以先以 AA 作为基线。
为什么大号文本 3:1 就能通过？
大号或粗体文字更容易识别，所以 WCAG 允许较低阈值。不过细字体、复杂背景或小屏幕场景，可能仍然需要更强对比度。
UI 组件 AA 检查的是什么？
它适用于按钮边框、输入框轮廓、图标、选中状态和错误提示等非文本元素。很多表单和后台界面的问题其实都出在这里。
透明色会影响结果吗？
会。半透明前景色或背景色取决于下方表面。本工具会先合成颜色，再基于实际结果计算对比度。
为什么设计看起来能读，却没有通过对比度？
字体、字重、周围元素、亮度和设计工具渲染都会影响感知。对比度提供的是团队可以复现和讨论的稳定标准。
OKLCH 对无障碍配色有什么帮助？
OKLCH 的 lightness 更接近人眼感知，因此更容易为主题、暗色模式和品牌系统建立可访问的色阶。
只推荐黑色或白色会不会太有限？
黑白推荐适合快速基线判断。成熟 UI 中，更建议把生成的 AA 或 AAA 候选色作为起点，再整合进品牌色阶。
报告可以用于团队协作吗？
可以。报告包含前景色、背景色、对比度，以及每个检查项的通过 / 未通过结果，适合用于 PR 描述、QA 备注、设计评审和无障碍追踪。
颜色数据会被上传吗？
不会。解析、合成和对比度计算都在浏览器本地运行，未发布的品牌色和保密设计文件不会离开你的设备。
对比度通过后还应该检查什么？
还需要检查焦点可见性、键盘导航、表单错误提示、ARIA 与语义 HTML、动态状态反馈和屏幕阅读器表现。对比度只是整体无障碍的一部分。
这个工具支持 APCA 吗？
目前展示的是 WCAG 2.x 对比度。如果你的项目需要 APCA，可以把这个工具作为基线检查，再使用专门的 APCA 工具做二次确认。
渐变或图片背景上的文字怎么处理？
分别取背景最亮和最暗区域的颜色，并逐一检查组合。如果两端都略低于阈值，可以考虑加一层更暗的遮罩，或把文字移动到更平静的背景区域。
更多相关工具
把对比度检查器与颜色转换、调色板生成和渐变生成器串起来，就能从选了一组颜色推进到作为可访问设计 token 落地，让可读性留在代码库里，而不只是停留在评审评论中。