chrome devtools的accessibility inspector可直接读取可访问性树验证语义输出，按ctrl+shift+p（win）或cmd+shift+p（mac）输入“accessibility”打开，或右键元素选“inspect accessibility properties”，重点检查computed role、name和states三列是否准确反映屏幕阅读器实际感知。
用 Chrome DevTools 的 Accessibility Inspector 快速验证语义输出
Accessibility Inspector 不是模拟器，它直接读取浏览器渲染后生成的可访问性树（Accessibility Tree），反映屏幕阅读器实际“看到”的内容。只要 HTML 结构和 ARIA 属性写对了，这里显示的 Computed Role、Name 和 States 就基本等同于 VoiceOver 或 NVDA 的朗读结果。
打开方式很简单：在 Chrome 中按 Ctrl+Shift+P（Windows）或 Cmd+Shift+P（macOS），输入 “Accessibility”，选择 “Show Accessibility” 面板；或者右键目标元素 → “Inspect Accessibility Properties”。重点看三列：
-
Name是否来自alt、aria-label、aria-labelledby或可见文本？若为空且没设role="presentation"，就是硬伤 -
Role是否匹配预期？比如标签页容器应为tablist，而不是group或未定义 -
States中的selected、disabled、expanded是否随交互实时更新？静态写死的aria-selected="true"而不随 JS 切换，会误导用户
必须用手动键盘导航走查焦点流
自动化工具完全无法发现焦点顺序错乱、焦点丢失或焦点陷阱——而这恰恰是重构后最常出问题的地方。尤其当页面引入了模态框、下拉菜单或动态加载内容时，JS 焦点管理稍有疏忽，键盘用户就卡住不动。
操作时收起鼠标，只用键盘：
- 按
Tab和Shift+Tab检查所有可交互元素是否被遍历，且顺序与视觉流一致（不是从页脚跳到导航再回顶部） - 打开模态框后，焦点是否自动进入其中？关闭后，焦点是否回到触发按钮？若没做
focus()或returnFocus，就会丢焦点 - 表单提交失败后，错误字段是否获得焦点？还是让用户手动 Tab 寻找？后者对屏幕阅读器用户极不友好
- 自定义组件（如滑块、树形控件）是否支持方向键？仅靠
click事件而没监听keydown，等于对键盘用户关闭大门
用真实屏幕阅读器做最小闭环测试
Chrome 的 Accessibility Inspector 只告诉你“结构对不对”，但不告诉你“听感顺不顺”。VoiceOver（macOS）和 NVDA（Windows 免费）是必须跑一遍的真实环境，它们的朗读节奏、停顿逻辑、上下文省略规则，和 Lighthouse 完全不同。
不必通读整站，聚焦关键路径：
- 首页主导航：是否能用
R（rotor）快速跳到navigation区域？每个菜单项是否带上下文（如 “Products, link” 而非 “Link”）？ - 搜索框：
label是否被正确关联？输入提示是否通过aria-live="polite"动态播报？ - 步骤向导：
aria-current="step"是否准确标记当前步？切换时是否伴随aria-live提示“已切换至第二步”？ - 表格数据：是否有
scope或headers属性？复杂表头嵌套下，屏幕阅读器能否正确映射行列关系？
Lighthouse 只能筛出 HTML 层硬伤，别信它的总分
Lighthouse 的 Accessibility 审计本质是静态 DOM 扫描，不执行 JS，也不触发交互。它能抓到 img 缺 alt、label 和 input 的 for/id 不匹配、button 缺 type 这类硬编码问题，但对以下情况完全无感：
- JS 动态插入的内容没补
aria-live - 焦点管理代码存在 race condition，导致偶尔失效
- 颜色对比度靠 CSS 变量或内联样式计算，Lighthouse 解析不准
- ARIA 属性值拼写错误（如
aria-lablelledby），它不会校验属性名合法性
所以，Lighthouse 得分从 80 升到 100 并不意味着可访问性达标，只是说明你把表面坑填平了。真正难啃的骨头，永远在交互逻辑和状态同步里。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
