OKLCH的L值不是WCAG对比度的直接替代，必须经sRGB转换并按WCAG公式计算相对亮度（L=0.2126×R'+0.7152×G'+0.0722×B'）才能验证是否达标，实测是唯一可靠方式。
OKLCH的L值不是WCAG对比度的直接替代
OKLCH的L（Lightness）是感知亮度坐标，不是WCAG要求的相对亮度L。WCAG对比度必须用伽马校正后的sRGB分量计算： L = 0.2126 × R' + 0.7152 × G' + 0.0722 × B'。OKLCH的L值即使设为50%，也不代表该颜色在WCAG公式下算出的相对亮度就是0.5——它只是人在标准观察条件下对明暗的主观等距判断。
OKLCH能提升色阶设计的感知一致性，但不自动达标
用oklch(40% 0.2 200)和oklch(60% 0.2 200)生成两个蓝色，它们的视觉明度差接近“等距”，这对构建按钮悬停态、禁用态等系统级色阶很有用；但这两个颜色与白色背景的实际对比度仍需实测——可能分别是6.2:1和3.8:1，后者已低于AA级要求（4.5:1）。常见错误是以为“L差20%就安全”，结果小字号文本直接不合规。
为什么OKLCH比HSL更适合做无障碍配色基础
-
hsl()中lightness是sRGB立方体的几何中点，hsl(0, 100%, 50%)（纯红）相对亮度仅约0.21，而hsl(120, 100%, 50%)（纯绿）高达0.72——同l值，对比度能差三倍 -
oklch()把明度映射到人眼感知域，同一L下不同色相的相对亮度更收敛（尤其在L=20%–80%区间），降低因色相切换导致对比度突变的风险 - OKLCH支持宽色域（P3/Rec.2020），
@media (color-gamut: p3)可渐进增强饱和度，而HSL始终被锁死在sRGB立方体内
实测才是唯一验证方式，OKLCH只是起点
Chrome DevTools「Accessibility」面板显示的对比度数值，永远基于真实渲染后的像素——它会把oklch(32% 0.03 210)先转成sRGB再套WCAG公式。CI/CD中用contrast-ratio扫描CSS变量时，也必须走这一步转换。最容易被忽略的是：禁用态、焦点态、高对比模式（@media (forced-colors: active)）下的颜色会被系统强制重映射，此时OKLCH定义的原始L完全失效，必须用CanvasText这类系统关键词兜底。
