chrome devtools color picker是最直接的对比度检测方式，但仅适用于纯色背景和已渲染文本；其他情况需手动合成颜色或用axe-core等工具兜底。
Chrome DevTools 的 Color Picker 是最直接、最可靠的对比度检测方式，但只对纯色背景 + 已渲染文本有效；其他情况必须手动补测或用 axe-core 等工具兜底。
Chrome DevTools 怎么查单个元素的对比度
右键目标文本 →「检查」→ 在 Styles 面板找到生效的 color 和 background-color（注意看 computed 值，不是声明值）→ 点击颜色值右侧的小色块图标 → 弹出调色器后，底部会显示 Contrast ratio: X.XX 和是否通过 AA/AAA。
常见错误现象：
-
background-image或linear-gradient背景下，DevTools 显示的对比度是错的，它只读取background-color声明，不合成图像像素 -
opacity: 0.9或filter: brightness(1.1)会让实际渲染变亮/变暗，但 DevTools 仍用原始色值计算，结果虚高 -
::before/::after中含文本（如content: "必填"）不会被自动纳入检测，得单独选中伪元素节点再点色块
JS 扫描页面找低对比度节点要避开哪些坑
别自己写正则解析 getComputedStyle(el).color 返回的字符串——Chrome 返回 rgb(51 51 51)，Firefox 是 rgb(51, 51, 51)，IE 可能是 #333，还可能遇到 currentcolor、transparent、hsl(200, 100%, 50%) 等非标准格式。
实操建议：
- 用
tinycolor2统一处理：new tinycolor(color).toRgb()直接转成{ r: 51, g: 51, b: 51 }对象，省去 gamma 反变换和格式兼容问题 - 重点扫描
p、span、label、button、a这几类承载可读文本的元素，它们一旦设了color或background-color就必须验 - 别漏掉伪元素：用
document.querySelectorAll('p::before, button::after')单独抓取，再读getComputedStyle(el, '::before').content判断是否含文本 - 禁用态按钮（
button[disabled]）常设为#aaa配#f5f5f5，实测对比度仅 ~2.1，必须单独加规则校验
axe-core 和 pa11y 自动化检测怎么选
axe-core 更适合集成进前端构建流程或 Cypress 测试，API 稳定、支持 Shadow DOM、规则可配；pa11y 基于 Puppeteer，更适合全站巡检和生成 HTML 报告，但对动态内容容易漏判。
使用场景与参数差异：
- CI/CD 中跑单元级检测：用
@axe-core/webdriverjs或直接调axe.run()，过滤只报color-contrast规则，避免噪声干扰 - 跑全站时用
pa11y --standard wcag2aa --reporter html --out report.html https://example.com，但务必加--wait-for-url和--timeout 10000，否则 SPA 页面路由切换后没等 JS 渲染完就退出 - 两者都跳过
aria-hidden="true"元素，但不会忽略display: none的伪元素（如::before { content: "⚠" }），这类需人工复查
深灰文字配浅灰背景为什么总不达标
#333 和 #eee 看着有层次，但算出来对比度只有 ~2.1，远低于 AA 要求的 4.5。这不是设计品味问题，是亮度计算逻辑决定的：每个通道要先归一化，再做 gamma 反变换——值 ≤ 0.03928 的直接 ÷12.92，否则用 ((val + 0.055) / 1.055) ** 2.4。这个步骤不能跳，浏览器不帮你做。
更麻烦的是，font-weight 未显式声明时，某些字体在小字号下被浏览器降级为细体，进一步拉低实测对比度；系统字体栈（如 system-ui）在不同 OS 上渲染的字形灰度也不同，影响最终可读性。
验证方法：打开 Chrome DevTools → Elements 面板 → 右键元素 →「Show accessibility info」，直接读取 computed contrast ratio，而不是依赖设计稿标注值。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
