自动化工具仅能发现30–40%结构性问题，键盘导航、屏幕阅读器语义流、动态内容通知等必须手动验证；键盘测试需严格遵循焦点顺序与视觉流一致，模态框焦点管理、焦点指示器、aria语义、工具参数配置及动态内容交互均需人工实测。
只靠 axe 或 Lighthouse 扫一遍，根本没法确认页面是否真正可访问。 自动化工具能抓出约 30–40% 的结构性问题（比如缺失 alt、label、role），但对键盘流、焦点管理、屏幕阅读器语义流、动态内容通知等关键路径完全无感。手动审查不是“补充”，而是不可替代的验证环节。
键盘导航必须从零开始走查
把鼠标拿开，只用 Tab、Shift+Tab、Enter、Space 和方向键操作整个页面。重点不是“能不能按”，而是“按得合不合理”：
- 所有交互元素（按钮、链接、输入框、自定义控件）都必须能被
Tab访问到；display: none或visibility: hidden的元素不能抢焦点，但opacity: 0或position: absolute; left: -9999px的仍可能被聚焦——得实测 - 焦点顺序必须匹配视觉流和 DOM 顺序；React/Vue 中用
key或条件渲染打乱 DOM 时，极易出现跳序 - 模态框打开后，焦点必须进入框内，且
Tab不能逃逸；关闭后，焦点应回到触发按钮（不是页面顶部） - 没有可见焦点指示器？立刻加
:focus-visible或至少:focus样式，否则键盘用户直接“失联”
屏幕阅读器测试不能只听前两秒
用 NVDA（Windows）或 VoiceOver（macOS）闭眼操作，不是“点开读一遍就完事”。真实问题是：
- 标题层级是否断裂？
h2后直接跳h4，屏幕阅读器用户会丢失结构锚点 - 表单控件有没有被正确朗读？
<input type="checkbox">缺少<label></label>关联，读出来就是“未选中 复选框”，没上下文 -
aria-live区域更新后，是否真的被播报？很多应用写了但没触发，或用了polite却在关键操作（如提交成功）里该用assertive - 图标按钮（如 ✕、?）是否都有
aria-label或包裹在语义化button里？纯div+click事件 = 屏幕阅读器静音
axe 和 Lighthouse 必须调对参数再跑
默认配置下，这两个工具漏报严重，尤其对现代前端项目：
-
axe插件默认禁用color-contrast规则，进 Settings → Rules 手动勾选，否则对比度问题直接不报 - Lighthouse CI 中
assert.categories:accessibility失效，常见原因是：minScore写成{"minScore": 90}（错），必须是{"minScore": 0.9}（对） - React/Vue 应用跑 axe 前，务必等
document.querySelector('#root')有子节点——否则异步加载的表单、aria-live区域全被跳过 - WAVE 报 “Contrast Error” 但找不到元素？切到 DevTools → Elements → 右键目标文本 → Copy outerHTML，粘贴到独立 HTML 文件里重测，排除 CSS 变量或 Shadow DOM 干扰
最常被忽略的点：动态内容（如搜索建议、分页加载、表单校验提示）的可访问性，既不在 axe 的静态快照里，也难被键盘用户预判。它必须在真实交互节奏下，由人来判断“焦点去哪了”“提示读出来了没”“用户下一步直觉想按什么”。工具扫完只是起点，不是终点。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
