必须用工具+人工交叉验证；axe devtools可检测运行时问题如aria-*误用、焦点断裂、对比度不足，但漏检未渲染分支；htmlhint仅做静态匹配，无法处理上下文依赖规则；剩余30–40% wcag问题须键盘导航、屏幕阅读器实测及行为逻辑人工验证。
可访问性漏洞没法靠肉眼扫出来，必须用工具+人工交叉验证；单靠浏览器开发者工具或W3C验证器会漏掉90%以上的实际问题，比如aria-hidden错用在焦点元素、role缺失但语义依赖上下文、或嵌套模板中img漏alt。
用axe DevTools做实时可访问性扫描
它直接集成在Chrome/Firefox开发者工具里，比W3C验证器更贴近真实渲染后的DOM，能检测aria-*属性误用、焦点顺序断裂、颜色对比度不足等运行时问题。
- 安装axe DevTools插件后，在Elements面板右键任意节点 → “Analyze accessibility”，它会高亮当前节点及父链的可访问性风险
- 注意它的“Critical”级报错（如
aria-hidden="true"applied to focusable element），这类必须立即修复，否则屏幕阅读器会跳过交互控件 - 它不检查未渲染的条件分支（比如
v-if或*ngIf为false时的模板），所以得手动触发不同状态再扫描
为什么HTMLHint对可访问性基本无效
HTMLHint不是基于AST的解析器，它只处理token流和行文本，根本拿不到parentNode、children或isSelfClosing这些节点关系信息，所以无法判断“button在modal内是否缺aria-label”或“同一页面两个nav是否用了重复的aria-label”。
- 它能做的仅限于静态模式匹配：比如强制
img带alt属性，但无法识别img在figure里且有figcaption时alt=""是合法的 - 所有依赖上下文的规则（如组件内role校验、模板嵌套层级中的alt逻辑）都超出HTMLHint能力边界
- 如果项目用了Vue/React，别白费力气写HTMLHint自定义规则——直接上
eslint-plugin-vue或eslint-plugin-jsx-a11y
手动验证那些工具永远扫不到的点
自动化工具只能覆盖约60–70%的WCAG标准，剩下必须靠人眼+辅助技术验证，尤其是涉及行为逻辑的部分。
- 用键盘Tab导航走一遍表单和菜单，确认焦点不卡死、不跳失、顺序符合视觉流
- 打开NVDA或VoiceOver，朗读关键路径（登录页、搜索结果页、错误提示），听它是否把
icon button读成“button”而不是“删除商品” - 检查
aria-live区域更新时，屏幕阅读器是否及时播报，而不是静默吞掉动态内容 - 特别注意JavaScript动态插入的DOM：比如
document.createElement('div')后没补role="alert"，axe可能根本看不到这个节点
真正卡住团队的从来不是工具不会用，而是把可访问性当成“扫完axe没报错就完工”的交付动作——那些需要理解用户场景、设计意图和交互上下文的漏洞，永远藏在工具报告之外。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
