lighthouse可访问性审计需在chrome devtools中运行并禁用插件，手动验证tab导航与动态内容通知，其仅覆盖80%基础问题，语义合理性、上下文缺失等须人工结合屏幕阅读器、无样式浏览和纯键盘操作闭环验证。
用 Lighthouse 做可访问性审计是当前最直接、最可靠的落地方式，它能暴露 80% 以上的真实可访问性缺陷，但必须配合人工验证才能闭环。
Lighthouse 的可访问性审计怎么跑才不漏报
很多人点开 Lighthouse 就勾选“可访问性”，生成报告后看到“92 分”就以为过关了——其实这分只反映工具能自动检测的部分，比如 alt 缺失、aria-label 重复、tabindex 滥用等基础项。真正影响视障用户操作的逻辑问题（如上下文缺失、动态内容无通知、焦点顺序错乱）往往不会被标记。
实操建议：
- 必须在 Chrome 开发者工具中运行，而非扩展或命令行——只有 DevTools 版本会启用完整的辅助技术模拟栈
- 测试前禁用所有浏览器插件，尤其广告拦截和密码管理类，它们可能劫持
aria-live区域或覆盖焦点样式 - 手动触发一次键盘 Tab 导航，确认焦点能落到所有交互元素上；Lighthouse 不校验这个，但它是 WCAG 2.1 AA 级强制要求
- 如果页面含大量 JavaScript 渲染内容，勾选“清空缓存并硬重载”再跑，否则可能审计到未完成渲染的 DOM 快照
哪些可访问性问题 Lighthouse 根本不报
Lighthouse 对语义合理性、上下文一致性、行为预期类问题完全无感。它不会告诉你：“这个 button 标签里写的是‘提交’，但实际点击后跳转到帮助页”，也不会指出“nav 里塞了 17 个链接，但没用 aria-labelledby 做分组说明”。
典型漏检场景包括：
- 仅靠视觉区分的交互提示，例如用颜色变化表示错误，但没配
aria-invalid="true"或文本反馈 - 表单控件与
label关联正确，但label文本本身模糊，如“输入信息”而非“邮箱地址” - 使用
display: none隐藏内容，但该内容本应通过aria-hidden="false"保持可读（如模态框中的辅助说明） - 动态加载的卡片列表未设置
aria-live="polite"，屏幕阅读器无法感知新增项
自动化工具之外，必须做的三件事
工具只是起点。真实项目中，以下动作缺一不可：
- 用 NVDA 或 VoiceOver 实际朗读关键路径：首页导航 → 主要内容 → 表单填写 → 提交反馈。重点听标签名是否准确、跳过链接是否生效、错误消息是否即时播报
- 关闭 CSS 后检查 HTML 结构是否仍具逻辑流：去掉所有样式后，
main是否还在视觉中心？aside是否自然退居次位？结构崩塌说明语义依赖样式 - 把鼠标和触控板全禁用，纯靠键盘走完整流程。发现某个按钮无法
Tab进入？那是tabindex="-1"写错了位置，或是用div+onclick伪造的按钮没加role="button"
可访问性不是打勾清单，而是持续验证的习惯。Lighthouse 报告里那个绿色分数，只代表你没踩最明显的坑；真正的门槛，在于每次改完 DOM 都下意识问一句：“盲人用户此刻知道这是什么、在哪、能干什么吗？”
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
