axe DevTools 适合开发中迭代，能精确定位 WCAG 违规元素并提供修复指引，支持右键忽略误报，但无法判断语义合理性或替代原生标签的可访问性损失。
只靠一个工具扫一遍就宣称“可访问性达标”，基本等于没做。
W3C Validator 能报什么、不能报什么
它只校验 HTML 语法和基础结构，比如 <main> 放在 <header> 外面、<img> 缺 alt 属性、<nav> 嵌套在 <p> 里——这些会明确标成 Error 或 Warning。但它完全不关心：aria-label 写得是否准确、tabindex 是否滥用、颜色对比度是否够、键盘焦点是否跳序。你提交一段带完整 ARIA 的代码，只要标签闭合正确，它可能直接显示 “No errors found.”
- 适合场景：上线前快速过一遍结构硬伤，尤其防低级拼写错误（如
for="emial"） - 容易踩的坑：把它的“通过”当成无障碍合格证；用 URL 模式验证时，服务可能抓取到未渲染完的 DOM（JS 注入的内容就漏了）
- 实操建议：粘贴源码（Direct Input）比输 URL 更可靠；重点盯
Element X is not allowed as child of element Y类提示
Lighthouse 的 Accessibility 审计怎么不翻车
它静态扫描 DOM，所以 JS 动态生成的内容若没在首屏完成渲染，就会被忽略。所有扣分项都来自 HTML 层面可见的缺陷：比如 <img> 的 alt 为空但没加 role="presentation"、<input> 和 <label> 的 id/for 不匹配、标题层级跳级（<h1> 后直接 <h3>）。
- 必须确保页面加载完成再点
Analyze page load，否则 DOM 不全，Accessibility 分会失真 - 选
Mobile设备模式会影响 viewport 和 UA，间接改变辅助技术对节点的识别逻辑，别默认 Desktop 就完事 - 它不报错但会降分的情况：内联样式写死颜色（如
style="color:#333"），Lighthouse 难以准确提取对比度值
axe DevTools 为什么更适合开发中迭代
它能定位到具体哪一行、哪个元素违反 WCAG 规则，比如 “<section> 缺少关联标题，屏幕阅读器可能无法识别主题” 或 “<div role="button"> 没加 tabindex="0"，键盘不可聚焦”。而且支持右键快速忽略误报项，适合边改边验。
立即学习“前端免费学习笔记（深入）”；
- 常见误判点：
<nav>里塞了搜索框或登录按钮，axe 不报错，但语义已偏离——需人工判断该区域是否真承担导航职能 - 它不会警告你用了
<div role="navigation">替代<nav>，虽然语法合法，却丢了 Safari VoiceOver 对原生<nav>的快捷跳转支持 - 实操建议：配合 Chrome 的
Elements面板实时修改，改完立刻重跑 axe，避免堆到测试阶段集中返工
工具只能告诉你“哪里不对”，但没法替你决定“为什么这样写”——比如一个 <figure> 里图片加载失败，alt 能否被读出，取决于它是否被包裹在可访问性树中，这必须手动触发屏幕阅读器验证。
