axe DevTools 是轻量级可访问性扫描器，能在浏览器开发者工具中直接运行，快速定位 alt 缺失、label 漏绑、role 误用等高危问题，但需人工确认语义并结合键盘导航与 Lighthouse 进行深度验证。
怎么用 axe DevTools 快速扫出高危可访问性问题
axe DevTools 是目前最贴近真实使用场景的轻量级可访问性扫描器，它能直接在 Chrome 或 Firefox 的开发者工具里运行，不依赖网络上传，也不需要改代码就能看到问题定位。对大型门户来说，它不是“全量修复工具”，而是“问题雷达”——帮你把 alt 缺失、label 漏绑、role 误用这类高频、易漏、影响面广的问题先揪出来。
常见错误现象包括：图片没有 alt 属性导致屏幕阅读器跳过关键信息；表单控件没配 label 或 aria-labelledby，NVDA 读不出输入意图；按钮用了 div + onclick 却没加 role="button" 和 tabindex="0"，键盘用户根本点不到。
- 安装 axe DevTools 插件后，在目标页面按
F12→ 切到axe标签页 → 点Analyze - 默认只检查当前视口内 DOM，如需全页扫描，勾选
Include all iframes和Check all pages（后者需配合 Lighthouse 扩展） - 重点关注
critical和serious级别问题，比如image-alt、label、heading-order规则报错 - 别信“自动修复建议”里的 inline 修改——它可能把
alt=""直接塞进装饰图，但实际应判断是否真为纯装饰；需人工确认语义
为什么 W3C Validator 不能替代手动键盘导航测试
W3C Validator 只验语法，不验交互。大型门户常有动态加载模块、SPA 路由、弹窗组件，这些在静态 HTML 检查中完全不可见，但却是焦点管理、ARIA live region、模态框逃逸等可访问性故障的重灾区。
例如：一个新闻频道首页的“推荐卡片流”用 IntersectionObserver 懒加载，W3C 验证器只看到初始骨架，而键盘用户 Tab 到第5张卡时，焦点却卡死在空白区域——这问题不会出现在任何 HTML 语法报告里。
立即学习“前端免费学习笔记（深入）”；
使用 Puppeteer + Chrome 将 HTML 渲染为中文 PDF，自动处理图表等待、Tab 展开、动画、测高、白边消除、防分页，适用于看板、报表、网页和交互图表转 PDF。
- 必须关闭鼠标，全程用
Tab、Shift+Tab、Enter、Space操作整个站点主流程：导航 → 文章列表 → 详情页 → 评论区 → 返回 - 重点观察：焦点是否进入 iframe？模态框打开后能否
Tab进去、关闭后焦点是否回到触发按钮？display: none的区块是否仍被键盘捕获？ - 发现焦点陷阱时，不要只修 CSS，要检查 JS 是否调用了
event.preventDefault()却没重置focus()逻辑
如何用 Lighthouse 抓住 WCAG 2.1 AA 的硬性缺口
Lighthouse 的 Accessibility Audit 默认跑的是 WCAG 2.1 AA 子集，它不覆盖全部 78 条准则，但精准命中字体对比度、链接目的明确性、跳过链接（skip link）、lang 属性缺失等强制项。对门户来说，这是上线前必须清零的“合规红线”。
容易踩的坑是：Lighthouse 在桌面模式下测出“contrast ratio too low”，但实际移动端因系统字体缩放或深色模式开启，问题更严重；又或者它标红了某个 button 缺少 aria-label，但该按钮图标本身已有 title 属性——这时得看 WCAG 原文：title 不等于可访问名称，不能替代 aria-label。
- 在 Chrome 中打开目标 URL →
F12→Lighthouse标签 → 勾选Accessibility→ 选择Desktop和Mobile分别跑一次 - 特别关注
Color contrast报告里的具体元素路径，比如#header nav a:nth-child(2)，而不是笼统看“对比度不合格” - 对
link-name类问题，别只加aria-label，优先重构为<a href="#">订阅电子报</a>—— 原生文本永远比 ARIA 更可靠 - 若某页面 Lighthouse 得分低于 85，不要直接优化代码，先确认是否因第三方广告脚本注入了无
alt的img—— 这类问题得推动广告平台整改
定期体检时最容易被忽略的三类隐藏风险
大型门户的可访问性退化往往不在首页，而在那些“没人管”的角落：旧版频道页、PDF 下载页、404 页面、第三方嵌入的投票组件。它们长期没走 CI 流程，也没被 axe 或 Lighthouse 覆盖到，但恰恰是残障用户最常撞上的断点。
另一个隐形问题是多语言切换后的属性漂移。比如中文页 <html lang="zh-CN"> 正确，但切到英文后，部分动态模块仍沿用 lang="zh-CN"，导致屏幕阅读器发音混乱；或是简体中文页用了繁体字 alt 文本，语音合成直接卡顿。
- 建立“可访问性巡检清单”，包含：所有带
href的a标签是否都有有意义的文本；所有iframe是否声明了title；所有 SVG 图标是否包裹<title>或加aria-hidden="true" - 把
axe-core集成进 CI，在每次 PR 提交时对变更文件做快扫，阻断新引入的aria-*错用 - 每季度抽样 5 个低流量页面（如“关于我们-历史沿革”、“版权声明”、“无障碍声明”），用 VoiceOver + Safari 实际朗读一遍，听是否出现“未命名按钮”“空链接”等语音中断
