应在ci/cd或本地开发流程中集成axe-core+jest或cypress组合：ci中用jest-axe扫描渲染dom，本地用cypress-axe在交互测试中触发检测，避免静态分析遗漏动态属性，并需禁用lighthouse因规则少且无法捕获js运行时状态问题。
怎么在构建流程里加可访问性检测
直接在 CI/CD 或本地开发流程中集成检测工具，比靠人肉检查靠谱得多。核心是让问题暴露在代码提交前，而不是等测试阶段才发现 aria-label 缺失或 role="tab" 没配 aria-controls。
推荐用 axe-core + jest 或 cypress 组合：
- CI 中跑
jest时引入jest-axe，对渲染后的 DOM 做快照级扫描 - 本地开发用
cypress配cypress-axe，写交互测试的同时触发检测（比如点击 tab 后检查aria-selected是否同步更新） - 避免只跑静态 HTML 分析——
axe-cli对未 hydrate 的 SSR 页面容易漏掉动态属性，必须测真实 DOM 状态
为什么不能只依赖 Lighthouse
Lighthouse 的可访问性审计项只有 18 条左右，且默认不运行全部规则（比如 aria-required-children 这类嵌套角色校验就常被跳过）。更关键的是，它只抓页面加载瞬间的状态，对以下情况完全无感：
- JS 动态插入的
dialog没设aria-modal="true" - 分页控件切换后，新页码没加
aria-current="page" - 表单提交失败后，错误提示没同步
aria-invalid="true"和aria-describedby
这些都得靠运行时检测才能捕获。
如何避免检测误报和漏报
误报常见于自定义组件封装过度——比如 React 里一个 TabButton 组件返回 <div></div>，即使内部逻辑正确，axe 也会报 “element has no role”。这时要：
- 用
aria-hidden="true"主动屏蔽装饰性元素（如图标字体、分割线），别指望工具自动识别 - 对已知合规但工具无法理解的模式，加
/* axe-ignore */注释，但必须附带 Jira 链接说明原因 - 禁用
color-contrast规则？不行——它检测的是实际渲染色值，不是 CSS 变量名；改用postcss-accessibility在构建时做色值校验更准
检测结果怎么落地成开发动作
检测本身不解决问题，关键是把报告映射到具体代码行和修复路径。例如：
- 报错
ARIA input has no label→ 定位到<input id="search">→ 补<label for="search">搜索</label>或加aria-label="站内搜索" - 报错
Elements must have sufficient color contrast→ 查color: var(--text-secondary)→ 追溯到_variables.css里该变量的实际 HEX 值，再用对比度工具验证 - 报错
aria-* attribute is invalid for the given element→ 很可能是给<button></button>加了role="button"，删掉就行（原生 button 已隐含该 role）
真正难的不是发现 ARIA 错误，而是判断某个 aria-live 区域该用 polite 还是 assertive——这得看内容更新是否中断用户当前操作，没法靠工具自动决策。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
