对比度检测
按 WCAG 2.x 计算前景色与背景色的对比度：给出 4.5:1 / 3:1 / 7:1 的 AA、AAA 与 UI 组件判定，并在不达标时给出保持色相、明度调整最小的修复色值。
浏览器本地运行所有计算都在你的浏览器里完成，数据不会离开本机。
颜色设置
支持 #rgb、#rrggbb、rgb()、hsl() 写法，直接输入或点取色器都可以。
检测结果
公式来自 WCAG 2.2：相对亮度 L = 0.2126R + 0.7152G + 0.0722B（sRGB 通道先线性化），对比度 = (L亮 + 0.05) / (L暗 + 0.05)。
示例文字 Sample text
大字（≥18.66px 粗体或 ≥24px）
- AAA 正文（≥7:1）未通过
- AA 正文（≥4.5:1）未通过
- AAA 大字（≥4.5:1）未通过
- AA 大字（≥3:1）通过
- UI 组件 / 图形（≥3:1）通过
#777777 · 0°, 0%, 46.67%#FFFFFF · 0°, 0%, 100%0.1845 / 1.0000纯白与纯黑两种文字色中，对比度更高的那个更稳妥。
1.00:121.00:1保持色相与饱和度不变，只调明度到刚好达标的最小值。
#767676目标 4.50:1 → 4.54:1压暗前景色明度 · 调整后明度 46.47% · 明度变化 0.2#595959目标 7.00:1 → 7.00:1压暗前景色明度 · 调整后明度 35.1% · 明度变化 11.57这个工具能做什么
- 做配色时先过一遍无障碍：正文文字要 4.5:1、大字要 3:1，这里能直接看到当前组合差多少。
- 设计稿里灰色文字「看着还行」但实际不达标很常见，输入 #777777 配白底会看到只有 4.48:1。
- 不达标时不用自己一点点试色：工具给出保持色相与饱和度、明度调整最小的修复色值，直接复制就能用。
- 检查按钮、图标、边框这类非文本元素是否满足 WCAG 2.2 §1.4.11 的 3:1 要求。
示例
输入
前景色 #777777，背景色 #FFFFFF，目标 4.5:1
输出
对比度 4.48:1，等级「仅大字 / UI 通过」，AA 正文未通过；修复建议：目标 4.5:1 → #767676（4.54:1），目标 7:1 → #595959（7.00:1），均为压暗前景色明度。
中灰是最尴尬的一段：白底上 4.48 与 4.54 只差一档灰阶，肉眼几乎分不出来，但决定是否通过 WCAG AA。
常见问题
对比度是怎么算出来的？
先用 WCAG 2.x 的公式把每个 sRGB 通道线性化（c ≤ 0.03928 时除以 12.92，否则取 ((c+0.055)/1.055)^2.4），再加权得到相对亮度 L = 0.2126R + 0.7152G + 0.0722B，最后算 (L亮 + 0.05) / (L暗 + 0.05)，所以纯黑配纯白正好是 21:1。
AA 和 AAA、正文和大字分别是什么阈值？
AA 正文 4.5:1、AA 大字 3:1；AAA 正文 7:1、AAA 大字 4.5:1；UI 组件与图形按 WCAG 2.2 §1.4.11 要 3:1。大字指 24px 以上，或 18.66px（14pt）以上的粗体。
修复建议为什么只改明度？
改色相或饱和度会换掉颜色本身，设计上通常不能接受。工具把前景色转到 HSL，只朝「更暗」或「更亮」一个方向二分搜索，找到刚好达标的明度，所以给出的色值看起来还是同一个颜色。
什么情况下会给不出建议？
当前景与背景亮度非常接近、且朝一个方向调到底（纯黑或纯白）仍达不到目标时，说明这组颜色本身不可救，工具会提示需要同时改背景色。比如中灰背景上再放中灰文字想凑到 7:1 就是这种情况。
颜色会被上传吗？
不会。所有计算都在浏览器里完成，页面不发任何请求，输入的颜色也不会被保存。
关键词：contrast ratiowcag contrastaccessibility checkeraa aaa contrastrelative luminance对比度检测无障碍对比度WCAG 2.2颜色对比度修复建议