WCAG对比度算法基于相对亮度与Gamma校正，而非RGB差值：先将sRGB转线性光，再加权求和得L=0.2126r+0.7152g+0.0722b，最后用(L₁+0.05)/(L₂+0.05)计算。
什么是 WCAG 对比度算法（而非 RGB 差值）
直接用 math.abs(r1 - r2) + Math.abs(g1 - g2) + Math.abs(b1 - b2) 算色差，对可读性毫无意义——它完全忽略人眼对不同颜色通道的敏感度差异，也无视明度（luminance）在文字辨识中的决定性作用。WCAG 2.1 强制要求的对比度计算基于相对亮度（relative luminance），再套用对比度公式 (L1 + 0.05) / (L2 + 0.05)（L1 ≥ L2），这才是影响文字是否“看得清”的真实依据。
如何正确计算两个颜色的 WCAG 对比度（含 Gamma 校正）
关键步骤不是简单转灰度，而是先对每个通道做 sRGB → 线性光转换，再加权求和得到相对亮度。跳过 Gamma 校正会导致结果偏差高达 20%+，尤其在深色背景下极易误判为“合格”。
-
r、g、b需先归一化为 0–1 范围（如#333→r = 0.2） - 对每个通道：若 ≤ 0.03928，则除以 12.92；否则用
((val + 0.055) / 1.055) ^ 2.4 - 相对亮度
L = 0.2126 * r_linear + 0.7152 * g_linear + 0.0722 * b_linear - 对比度 =
(Math.max(L1, L2) + 0.05) / (Math.min(L1, L2) + 0.05)
function getContrastRatio(hex1, hex2) { const toLinear = (c) => { c /= 255; return c <= 0.03928 ? c / 12.92 : Math.pow((c + 0.055) / 1.055, 2.4); }; const getLuminance = (hex) => { const r = parseInt(hex.slice(1, 3), 16); const g = parseInt(hex.slice(3, 5), 16); const b = parseInt(hex.slice(5, 7), 16); return 0.2126 * toLinear(r) + 0.7152 * toLinear(g) + 0.0722 * toLinear(b); }; const L1 = getLuminance(hex1); const L2 = getLuminance(hex2); return (Math.max(L1, L2) + 0.05) / (Math.min(L1, L2) + 0.05); } // getContrastRatio('#000000', '#ffffff') → ~21.0 为什么 hsl() 或 lightness 值不能代替 WCAG 对比度
HSL 的 lightness 是视觉感知的粗略近似，但它是均匀色相环下的数学中间值，不反映真实光强度。例如 hsl(0, 100%, 50%)（纯红）与 hsl(120, 100%, 50%)（纯绿）的 lightness 相同，但前者相对亮度仅约 0.21，后者约 0.71 —— 实际对比度只有 ~3.7，远低于 AA 级要求的 4.5。浏览器 DevTools 显示的 “contrast ratio” 字样若未注明依据 WCAG，大概率是简化算法，不可信。
实际设计中容易被忽略的三个细节
字体粗细、背景透明度、抗锯齿都会实质性改变可读性，但 WCAG 计算只认最终渲染出的两个纯色像素值。这意味着：
立即学习“前端免费学习笔记（深入）”；
- 使用
rgba(0,0,0,0.8)文字叠加在#fff上，必须先混合出最终颜色再算对比度，不能只算#000和#fff - 字体
font-weight: 300在小字号下边缘发虚，等效于降低对比度，此时即使算法值达标，实测可读性也可能不足 - css
Filter: brightness(1.1)或contrast(1.2)会改变渲染结果，但不会改变你写的原始颜色值——需按滤镜生效后的像素值重算
真正卡住可访问性的，往往不是算法本身，而是把“颜色值输入正确”等同于“用户看得清”。