WCAG 2.1 AA级最低要求是普通文本与背景对比度≥4.5:1，大号文本（≥18pt或≥14pt加粗）≥3:1；该值须按公式(L₁+0.05)/(L₂+0.05)计算相对亮度比，不可凭肉眼或RGB差值判断。
WCAG 2.1 对比度的最低要求是多少
文本与背景的色彩对比度必须满足 WCAG 2.1 AA 级标准：普通文本（小于 18pt 或粗体小于 14pt）需 ≥ 4.5:1；大号文本（≥ 18pt 或粗体 ≥ 14pt）只需 ≥ 3:1。不达标意味着视障用户阅读困难，且可能违反 GDPR、EN 301 549 或国内《信息技术 无障碍设计规范》（GB/T 37668-2019）。
注意：contrast ratio 不是简单算 RGB 差值，而是基于相对亮度（luminance）按公式计算：(L1 + 0.05) / (L2 + 0.05)，其中 L1 是亮色亮度，L2 是暗色亮度。浏览器 DevTools 显示的对比度值就是这个结果，但仅对静态色块有效——它不处理半透明叠加、CSS 滤镜、SVG opacity 或 backdrop-filter 后的效果。
如何用 Chrome DevTools 快速验证单个文本元素
右键检查元素 → 在 Styles 面板找到生效的 color 和 background-color（注意继承、层叠和 computed 值）→ 点击颜色值右侧的小色块图标 → 弹出调色器后，底部会实时显示对比度数值和是否通过 AA/AAA。
- 若背景是图片或渐变，DevTools 无法自动取色，需手动截图用工具测取平均亮度或关键区域色值
- 遇到
background: rgba(0,0,0,0.1)叠加在图片上？DevTools 默认只读取该声明，不会合成下层图像——必须导出渲染后像素再测 - 启用“Disable cache”和“Emulate vision deficiencies”可辅助判断弱视场景下的实际可读性
自动化检测该选 axe-core 还是 pa11y
axe-core 更适合集成到前端构建流程或 Cypress 测试中，API 稳定、规则可配、支持 Shadow DOM；pa11y 基于 Puppeteer，更适合全站巡检、生成 HTML 报告，但对动态内容（如 React 路由切换后未 re-run 检查）容易漏判。
立即学习“前端免费学习笔记（深入）”；
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
实操建议：
- CI/CD 中用
axe-core+ Jest：安装@axe-core/webdriverjs或直接调用axe.run()，过滤只报color-contrast规则 - 跑全站时用
pa11y --standard wcag2aa --reporter html --out report.html https://example.com，但务必加--wait-for-url和--timeout 10000避免 SPA 加载不全就退出 - 两者都会忽略
aria-hidden="true"元素，但不会跳过display: none的伪元素（如::before含文本）——这类需手动排查
设计师给的 HEX 色值怎么快速转成合规组合
别靠肉眼调，用工具反向推导。输入主色（如品牌蓝 #2563eb），工具会给出满足 4.5:1 的最浅/最深背景色范围。推荐 WebAIM Contrast Checker 或 VS Code 插件 Color Highlight + Accessibility Checker 实时提示。
关键细节：
- 同一 HEX 在不同显示器 Gamma 下感知亮度不同，工具默认按 sRGB 计算——确保设计稿也用 sRGB 色彩空间导出
- 禁用
prefers-reduced-motion时，不要依赖动画过渡来“缓解”低对比问题，WCAG 明确要求静态对比达标 - 按钮悬停态（
:hover）必须单独验证，很多团队只测默认态，而悬停后文字变灰、背景变浅常导致对比暴跌
真正麻烦的不是算数，是当产品经理坚持用浅灰文字配白色卡片、又拒绝改文案字号时——这时候得拿出 contrast ratio 截图和 WCAG 条款编号，而不是讨论“看起来还行”。
