axe devtools插件可快速扫描页面无障碍问题，安装后在开发者工具axe标签页点击analyze即可，需确保页面加载完成且js交互就绪，否则动态组件可能漏检。
用 axe 浏览器插件快速跑一次无障碍扫描
绝大多数前端开发人员第一次接触可访问性评估，应该从 axe DevTools（Chrome / Firefox 插件）开始——它不依赖构建流程、不改代码就能暴露 80% 的常见问题，比如缺失 alt、label 未绑定、对比度不足、焦点顺序错乱等。
安装后打开开发者工具 → 切到 axe 标签页 → 点击 Analyze。注意：必须在页面完成加载、JS 交互就绪后再运行，否则动态渲染的组件（如 Modal、Tab 面板）可能被漏检。
常见误操作：
- 在未登录态或 mock 数据下测试，导致部分区域未渲染，
axe报告“无问题”，实则隐藏了真实缺陷 - 忽略
Partial Matches分类——这里常藏有需要人工验证的问题，比如aria-label是否语义准确、图片是否真为装饰性 - 直接信任“Passed”数量，但没点开每个失败项看具体 DOM 节点和修复建议
WCAG 2.1 级别 A/AA 对应哪些硬性检查项
无障碍不是“尽量友好”，而是有明确合规边界。A 级是强制底线，AA 是多数政务、金融类站点的上线门槛。关键区别不在“多或少”，而在“能否被替代”：
-
A 级：缺失alt属性、表单控件无label、键盘无法跳过导航栏、视频无字幕（若含对白） -
AA 级：文本与背景对比度 ≥ 4.5:1（小字号）、链接需有非颜色区分（如下划线）、所有功能支持键盘操作且焦点可见、aria-live区域更新不打断屏幕阅读器朗读
注意：axe 默认按 AA 检查，但会把 A 级问题标为 critical，AA 级标为 serious。别只修 critical——AA 项被监管抽查时一样算违规。
为什么 Lighthouse 的无障碍分数经常虚高
Lighthouse 的 Accessibility 分数基于自动化检测，覆盖约 30–40% 的 WCAG 条款，且默认忽略大量需上下文判断的问题。它给 92 分，不代表能过等保或残联验收。
典型失真场景：
- 自动跳过 JS 渲染内容（如 React.lazy + Suspense 加载的区块），报告里“没检测到问题”，实际该区域完全不可读
- 把
role="button"+onclick当作合法按钮，却不校验是否支持Enter/Space键触发——这是手动测试必查项 - 对比度检测仅针对静态 computed 样式，若通过
filter: brightness()或 CSS 变量动态调色，Lighthouse 无法识别真实值
结论：Lighthouse 适合做 CI 中的 baseline 快筛，但不能替代 axe + 手动键盘+屏幕阅读器验证。
读无障碍报告时重点盯哪三类节点
一份有效报告的价值不在总分，而在能否准确定位“谁、在哪、为什么错”。打开 axe 或 WAVE 输出后，优先过滤并逐条确认以下三类：
-
input、select、textarea元素：检查是否有label[for]或aria-labelledby，且关联 ID 真实存在；禁用placeholder替代label -
img和svg：区分alt=""（装饰性）和alt="描述"（信息性）；svg必须带role="img"+aria-label或<title></title> - 自定义交互组件（如
div[role="tablist"]）：验证tabindex、aria-selected、键盘行为（→ ← 切换，Enter 激活）是否全链路闭环
最容易被忽略的是：同一份报告中，多个错误可能根源于同一个底层模式（比如全局封装的 Button 组件忘了透传 aria-* props），修复时要回溯组件库，而不是逐个 patch DOM。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
