axe DevTools仅检测并提示修复建议，不自动修改HTML；如发现img缺alt或button无名称，会标出位置但不填充内容，语义补全须人工判断。
axe DevTools 能修什么，不能修什么
axe DevTools 本身不自动修改 HTML，它只检测并给出修复建议。比如发现 <img> 缺少 alt 属性，会标出位置并提示“添加有意义的替代文本”，但不会帮你填内容；发现 <button> 没有可访问名称，会指出问题，但不会猜你要写“提交”还是“下一步”。它适合快速定位结构性缺陷，但语义补全必须人工判断。
用 htmlhint + custom rules 预扫语义类硬伤
htmlhint 默认规则对可访问性覆盖有限，需手动启用关键项。常见遗漏点包括：attr-accesskey（避免滥用 accesskey）、attr-aria-role（检查 role 值是否合法）、attr-aria-required（验证 aria-* 属性配对）。实操时在 .htmlhintrc 中显式开启：
"attr-accesskey": true, "attr-aria-role": true, "attr-aria-required": true, "tag-pair": true
注意：tag-pair 可捕获未闭合的 <nav> 或 <main>，这类错误会导致屏幕阅读器跳过整块区域——不是样式问题，是语义断裂。
批量修复 alt、aria-label、role 的边界场景
自动化补全容易踩坑的地方集中在三类：
立即学习“前端免费学习笔记（深入）”；
-
<img src="logo.svg">：不能统一填alt=""，得区分装饰性（空）和信息性（需描述）；工具若强行填充，反而破坏可访问性 -
<div role="button">点击</div>：必须补tabindex="0"和aria-label，但工具可能只加 role 就停了，键盘焦点仍不可达 - 步骤向导中的
<li>：要加aria-current="step"，但仅当该<li>真实代表当前步——动态渲染时，静态扫描工具无法识别状态变化
建议用脚本做轻量级替换，例如用 sed 或 Node.js 脚本匹配 <img[^>]*src= 后无 alt= 的行，再人工校验上下文，而非依赖一键修复。
vnu 验证时为什么 aria-* 报错却渲染正常
vnu 按 W3C 标准校验，会拒绝某些浏览器容忍但语义违规的写法。典型例子：
-
<div role="navigation"><ul><li>首页</li></ul></div>→ vnu 不报错，但若内部用了<span>替代<a>，且没加tabindex和role="link"，vnu 会警告“交互元素缺少键盘支持” -
<input type="text" aria-describedby="error-1"><span id="error-1">必填</span>→ vnu 要求id="error-1"必须存在且唯一，历史模板里常有重复 id 或拼写错误，工具不会帮你去重，只会报attribute "id" is not unique
真正麻烦的是那些“浏览器能跑，vnu 打叉，屏幕阅读器读错”的组合——比如用 <table> 布局但没加 role="presentation"，vnu 不拦，但 NVDA 会把它当数据表朗读，打断流程。这种必须靠人工结合工具交叉验证。
