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。后者直接聚焦目标节点，避免在整棵树里手动找。

• 点开面板后，Inspect 按钮点亮为蓝色时，鼠标悬停在页面上会弹出覆盖层，含对比度、焦点状态、角色等实时信息，适合快速扫视
• 如果右键没出现该选项，说明元素被 display: none、visibility: hidden 或 aria-hidden="true" 移出了可访问性树——它对屏幕阅读器来说已“不存在”
• 动态渲染的组件（如 React/Vue 生成的按钮）需等 DOM 渲染完成再右键，否则可能 inspect 到空节点或旧版本

重点盯死三列：Role / Name / States

这三列决定屏幕阅读器“说什么、怎么读、是否响应”，缺一不可：

Wechat HTML Publisher

直接上传HTML富文本到微信公众号草稿箱。支持完整的HTML格式,无需Markdown转换。

下载

• Computed Role：应是你预期的角色。比如 button、checkbox、navigation。若显示 generic，基本是语义缺失——常见于没配 <label for="id"></label> 的 <input>，或用 <div> 写的按钮没加 <code>role="button"
• Name：必须非空且有意义。来源优先级是 aria-label ≈ aria-labelledby > <label for="id"></label> > alt > 元素内文本。混用 <label></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></text></svg> 或 currentcolor
• 禁用态按钮（:disabled）常设为 #aaa on #f5f5f5，实测对比度常跌破 3:1，但覆盖层不会主动提示“这是禁用态”，得你心里有数去 hover 那一刻
• 单纯用 textContent 更新错误提示、搜索建议或加载状态，读屏器大概率沉默。必须加 aria-live="polite" 包裹容器，或用 aria-atomic/aria-relevant 控制播报粒度

真正难的不是加 ARIA，而是让 role/name/state 在 DOM 生命周期里始终对齐——尤其是 JS 驱动的交互组件，稍一疏忽，读屏器就读到过期状态或空名称。维护期要盯住的，从来不是“写了没”，而是“算出来对不对”。