Chrome DevTools Accessibility面板必须先选中存在于无障碍树中的元素才有效，否则Computed Role、Name、States三列为空；常见失效原因包括display:none、aria-hidden="true"或无语义的div/span未加role和tabindex。
Chrome DevTools Accessibility 面板怎么用才不白开
它不是点开就出数据的“万能仪表盘”，必须先选中一个真实存在于无障碍树中的元素，否则面板里三列（Computed Role、Name、States）全是空的或灰色提示。
常见失效场景：
-
display: none、visibility: hidden、aria-hidden="true"的元素，直接被排除在无障碍树外，点了也看不到任何信息 - 纯
<div>或<span>没加role、没可聚焦属性、没语义内容，DevTools 默认跳过，不会纳入检查范围 - 没手动用吸管（
Cmd+Shift+C/Ctrl+Shift+C）点选目标，只靠 Elements 面板点击可能选中的是父容器，而真正要测的子元素根本没被激活
正确流程只有两步：先确保目标元素可见且未被 aria-hidden 排除 → 再点选它 → 最后切到 Accessibility 标签页。看到 generic 就等于失败，不是“还没配好”，是基础语义已经断了。
axe DevTools 插件和 CLI 工具的分工边界
axe DevTools 是浏览器内实时调试用的，适合改一行代码立刻验证；而 CLI 工具（如 axe-core + jest-axe 或 gemini-cli-extensions/web-accessibility）才是构建阶段该引入的主力。
立即学习“前端免费学习笔记（深入）”；
关键区别：
- DevTools 插件跑在已加载的页面上，依赖当前 JS 执行状态，对动态渲染（如 React useEffect 后挂载的弹窗）容易漏检
- CLI 工具能集成进
npm run build或 CI 流水线，用静态 HTML 或 Puppeteer 渲染快照做批量扫描，报错带行号，可设为exit code !== 0强制阻断发布 -
axe-core的规则集默认比 DevTools 更全（比如含landmark-is-unique、region缺失检测），但需手动配置 ignore 列表，否则会因第三方组件报一堆误报
不要试图用 DevTools 替代构建检查——它查不到未挂载的组件，也留不下可追踪的报告。
如何让无障碍检测不拖慢构建速度
全量扫描整个打包后的 HTML 会显著增加构建耗时，尤其含大量路由或复杂交互的 SPA。实际落地时得做取舍。
推荐做法：
- 只对核心路径做扫描：比如生成
index.html和几个关键 landing page（/login、/dashboard）的快照，而非全部200+路由 - 用
axe.run()的include选项限定 DOM 范围，例如只测#app内容区，跳过 header/footer 等复用模块（前提是它们已单独验证过） - CI 中启用缓存：把
node_modules/axe-core和扫描结果缓存起来，避免每次重装+重跑 - 开发机本地构建可关掉扫描，只在 PR 提交或 nightly 构建时启用——毕竟人眼扫一遍
main、lang、label是否缺失，比机器跑 3 秒快得多
工具是辅助，不是枷锁。构建阶段卡住 15 秒只为发现一个 alt=""，不如把时间花在写对第一个 <label for="id"> 上。
tota11y 这类可视化工具为什么不适合构建流程
tota11y 是运行时浮层，本质是前端 JS 库，必须页面加载后手动点按钮触发。它解决的是“我写的这个按钮，读屏器到底读成啥”，不是“构建产物里有没有 landmark-no-label 错误”。
硬塞进构建流程只会带来三类问题：
- 无法自动化：没有命令行接口，没法在
package.json的scripts里调用 - 输出不可控：只在浏览器里画红框、弹气泡，没法生成 JSON 报告供 CI 解析或存档
- 环境依赖强：需要完整 DOM + JS 执行上下文，服务端渲染（SSR）或静态生成（SSG）产物里根本跑不起来
它该出现在你改完一个表单组件后，顺手打开控制台点一下；而不是出现在 webpack --mode=production 的后续步骤里。
