Chrome DevTools Accessibility Inspector可直接检测绝大多数关键无障碍问题，无需构建或第三方服务；Mac按Cmd+Shift+P、Win/Linux按Ctrl+Shift+P输入“Accessibility”打开，或右键目标元素选“Inspect Accessibility Properties”，重点验证Computed Role、Name、States三列是否准确同步。
直接用 Chrome DevTools 的 Accessibility Inspector 就能检测绝大多数关键合规问题，不需要等构建、不依赖第三方服务——它显示的是浏览器实际生成的可访问性树，也就是 VoiceOver、NVDA 真正“读”的内容。
怎么快速打开并验证具体元素
Mac 按 Cmd+Shift+P，Windows/Linux 按 Ctrl+Shift+P，输入 “Accessibility”，回车选 Show Accessibility；更推荐右键目标元素（比如一个按钮、表单输入框或表格单元格）→ 选 Inspect Accessibility Properties。后者直接聚焦节点，避免在整棵树里手动找。
- 如果右键没出现该选项，说明元素被
display: none、visibility: hidden或aria-hidden="true"移出了可访问性树——对屏幕阅读器来说它已“不存在” - React/Vue 等动态渲染的组件，需等 DOM 完全挂载后再右键，否则可能 inspect 到空节点或旧版本
- 点击面板左上角
Inspect按钮点亮为蓝色后，鼠标悬停页面会弹出覆盖层，含对比度、焦点状态、角色等实时信息，适合快速扫视整页
重点盯死 Role / Name / States 三列
这三列是屏幕阅读器“说什么、怎么读、是否响应”的唯一依据，缺一不可：
-
Computed Role：应是你预期的角色（如button、checkbox、navigation）。若显示generic，基本是语义缺失——常见于没配<label for="id">的<input>，或用<div>写的按钮没加role="button" -
Name：必须非空且有意义。来源优先级是aria-label≈aria-labelledby><label for="id">>alt> 元素内文本；混用<label>和aria-label会导致不同读屏器行为不一致（Chrome 优先取后者，NVDA 可能忽略前者） -
States：如disabled、expanded、checked必须实时同步。JS 手动改input.checked = true后，若没触发 DOM 变更或未补aria-checked，读屏器仍可能读“未选中”
颜色对比度和动态内容更新怎么查
这两类问题不会出现在 Role/Name/States 里，但极易漏检，且直接影响低视力和读屏用户：
立即学习“前端免费学习笔记（深入）”；
- 悬停元素时，DevTools 覆盖层会标出对比度：绿色勾表示 ≥4.5（满足 WCAG AA），橙色感叹号表示不达标。注意它只检查
color和background-color计算值，不识别::before、<svg><text>或currentcolor场景 - 禁用态按钮（
:disabled）常设为#aaaon#f5f5f5，实测对比度常跌破 3:1，但覆盖层不会主动提醒你“这是禁用态”——得你心里有数去 hover 那一刻 - 单纯用
textContent更新错误提示、搜索建议或加载状态，读屏器大概率沉默。它需要明确通知信号：aria-live="polite"包裹动态区域，或用aria-atomic/aria-relevant控制播报范围
为什么结构异常比 ARIA 错误更致命
浏览器静默纠错（比如把 <div><p>文字</div></p> 自动修正）会直接破坏语义链，ARIA 补救也无效——屏幕阅读器根本读不出内容，键盘焦点顺序错乱，甚至 <main> 被吞进 <div> 里。
- Elements 面板里看到灰色斜体节点就是危险信号：这不是“显示效果问题”，而是浏览器被迫修复非法 HTML 后留下的痕迹
-
<html>标签必须带lang属性（如lang="zh-CN"），否则 NVDA/VoiceOver 可能按英文朗读中文 - 缺失
<!DOCTYPE html>或<meta charset="UTF-8">会导致 DOM 解析异常，SSR 渲染可能出错 - 复杂表格若省略
scope、headers或caption，静态扫描工具（如@trae/plugin-a11y）能自动抓出这类遗漏，但 DevTools 不报
