自动化工具仅能发现约30%的可访问性问题，剩余语义错误、焦点逻辑断裂、屏幕阅读器交互异常等必须人工验证；W3C HTML验证器只检查语法规范（如标签闭合、alt属性存在性），不检测颜色对比度、键盘导航、ARIA逻辑或屏幕阅读器行为。
直接用自动化工具扫一遍，只能发现约30%的可访问性问题——剩下的是语义错误、焦点逻辑断裂、屏幕阅读器交互异常等，必须人工验证。
W3C HTML验证器能查什么？
它只检查HTML语法是否符合规范，比如标签是否闭合、属性是否拼写正确、<img>有没有alt属性（但不判断alt值是否有意义）。它不检测颜色对比度、键盘导航、ARIA逻辑或屏幕阅读器行为。
常见误用现象：
- 把
alt=""当成“已通过”——其实装饰性图片才该这么写，功能性图片留空等于丢弃关键信息 - 提交含
aria-hidden="true"但内部有<button>的结构——验证器不报错，但屏幕阅读器会完全跳过该按钮 - 用
<div role="button">却没加tabindex="0"和onkeydown处理——验证器认为合法，用户却无法键盘触发
axe-core 浏览器插件怎么用才有效？
axe-core 是目前最贴近真实辅助技术行为的开源检测器，但它默认只运行“基础扫描”，很多关键规则（如color-contrast、heading-order、landmark-one-main）需要手动开启或配置上下文。
立即学习“前端免费学习笔记（深入）”；
实操建议：
- 在开发者工具中打开 axe 面板后，点「Settings」勾选
Include automated checks for WCAG 2.1 AA，否则默认只跑 A 级 - 对单页应用（SPA），必须等动态内容渲染完成后再点击「Analyze」，否则
aria-live区域、步骤向导当前步等状态不会被捕获 - 遇到
aria-required-children报错时，别急着加role——先确认是否本可用<nav>或<main>替代，滥用role反而破坏原生语义
为什么 keyboard-only 测试不能跳过？
所有自动化工具都无法模拟人按 Tab 键时的焦点流路径。一个看似“通过”的页面，可能在键盘操作下出现：
- 焦点卡死在某个
<div tabindex="-1">里出不来 - 轮播组件切换后，焦点没落到新幻灯片的第一个可操作元素上
- 步骤向导点击“下一步”，焦点仍停在旧步骤的按钮上，屏幕阅读器读不出新内容
-
aria-current="step"更新了，但对应<li>没设tabindex="0"，导致无法被聚焦
真正有效的做法是：关掉鼠标，全程只用 Tab / Shift+Tab / Enter / 空格键操作，同时开着屏幕阅读器（如 NVDA 或 VoiceOver）听它怎么读——这才是检验可访问性的黄金标准。
最常被忽略的复杂点：动态内容更新后的焦点管理和语义同步。比如表单提交失败后插入错误提示，不仅要加aria-invalid="true"和aria-describedby，还要确保错误区域被aria-live="polite"包裹，并且键盘焦点能自然移动到第一个错误输入框——这些，没有工具能自动帮你做对。
