如何测试屏幕阅读器_HTML无障碍验证方法技巧

Chrome DevTools中可用Cmd+Shift+P（Mac）或Ctrl+Shift+P（Win）输入“Accessibility”打开Accessibility Inspector，或右键元素选择“Inspect Accessibility Properties”，查看Computed Role、Name和States三列验证可访问性。

直接用 Chrome DevTools 的 Accessibility Inspector 就能快速验证屏幕阅读器是否能正确识别元素，不需要装额外工具或模拟真实读屏软件——前提是你的 HTML 语义正确、ARIA 补充得当。

怎么打开 Accessibility Inspector

在 Chrome 中打开任意网页，按 Cmd+Shift+P（Mac）或 Ctrl+Shift+P（Windows），输入 “Accessibility”，选择 “Show Accessibility” 面板；或者右键目标元素 → “Inspect Accessibility Properties”。面板会立刻显示该元素在可访问性树中的计算结果。

重点看三列：

• Computed Role：是否是你预期的角色（比如 button 而不是 generic）
• Name：是否非空、有意义（来自 alt、aria-label、label 或文本内容）
• States：如 disabled、expanded、checked 是否实时同步

为什么 inspect 后看到 role 是 generic

这几乎总是语义缺失的信号。常见原因包括：

立即学习“前端免费学习笔记（深入）”；

• 用 <div onclick="..."> 模拟按钮，没加 role="button" 且没处理 tabindex 和键盘事件
• <input type="text"> 没配 <label for="id">，导致 Name 为空，Role 降级为 generic
• 自定义下拉菜单用了 div + ul，但没设 role="combobox"、aria-haspopup 等必要属性
• <dialog> 在旧浏览器 fallback 时只写了 <div role="dialog">，却漏了 aria-modal="true" 和焦点管理逻辑

表单字段 name 显示为空怎么办

屏幕阅读器读不出字段名，用户根本不知道要填什么。修复优先级如下：

• 首选显式 <label for="xxx"> + <input id="xxx">，这是最稳定、兼容性最好的方式
• 次选隐式包裹：<label>邮箱<input type="email" name="email"></label>，注意不能跨块级元素
• 仅当无可见标签时才用 aria-label，比如搜索框的放大镜图标按钮：<button aria-label="搜索"></button>
• 避免混用：<label for="x">用户名</label> + <input id="x" aria-label="账号"> 会导致 Name 取决于实现，Chrome 优先取 aria-label，NVDA 可能忽略

动态内容更新后屏幕阅读器没读出来

比如表单提交后弹出错误提示、加载中状态切换、实时搜索建议列表——这些需要主动“喊话”辅助技术：

• 错误提示区域加 role="alert"（适合中断式消息）或 aria-live="polite"（适合非中断式更新）
• 不要仅靠 CSS display: none 控制提示显隐，要用 aria-hidden="true" 配合 hidden 属性
• 焦点跳转要谨慎：focus() 到错误字段是好的，但别在 modal 打开后强行 focus() 到标题以外的位置，容易打断读屏节奏
• 用 aria-busy="true" 标记异步操作中状态，比单纯改文字更可靠

真正卡住人的往往不是 ARIA 属性写不写，而是 DOM 结构本身就不支持可访问性树生成——比如把 <label> 放在 <input> 后面、用 position: absolute 打乱阅读顺序、或在 <main> 外塞重要内容。验证前先确保语义结构干净，比堆 ARIA 更有效。