css色差算法与色彩对比度_提高设计的可读性与易用性

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) 会改变渲染结果，但不会改变你写的原始颜色值——需按滤镜生效后的像素值重算

真正卡住可访问性的，往往不是算法本身，而是把“颜色值输入正确”等同于“用户看得清”。