WCAG AA级验证需结合Lighthouse自动化扫描与人工走查：Lighthouse可识别约30%缺陷（如alt缺失、对比度不足），但须人工核查alt描述性、键盘导航流、语义化结构、aria属性使用及禁用JS后的渲染效果。
如何验证页面是否满足 WCAG AA 级基础要求
直接打开浏览器开发者工具的「Lighthouse」面板，运行 Accessibility 审计即可快速识别对比度不足、缺失 alt、label 绑定错误等高频问题。但注意：Lighthouse 只能检测约 30% 的可访问性缺陷，比如它无法判断 alt 文本是否真正有意义，也无法验证键盘导航流是否自然连贯。
真实落地必须配合人工走查，重点检查以下几类场景：
- 所有
<img alt="HTML网页无障碍可访问性规范的落地实施流程" >是否具备描述性alt（功能图 ≠ “图片1”，图表 ≠ “柱状图”） - 每个
<input>是否有明确的<label for="xxx"></label>或aria-labelledby - 模态框（
role="dialog"）是否正确设置aria-modal="true"、焦点捕获和关闭逻辑 - 动态更新区域（如搜索建议、表单校验提示）是否使用
aria-live="polite"或assertive
语义化 HTML 不是“加标签”，而是重构 DOM 结构逻辑
很多团队误以为把 <div class="button"> 换成 <code><button></button> 就算完成语义化——其实远不止。真正的语义化需要按内容意图组织层级：
-
<h1></h1>必须唯一，且代表整个页面的核心主题；后续标题严格递进（h2→h3），不可跳级或仅靠 CSS 视觉降级 -
<nav></nav>应包裹全部主导航链接，而非只包菜单图标；多个导航区需用aria-label区分，如<nav aria-label="主导航"></nav>和<nav aria-label="页脚导航"></nav> -
<main></main>是页面唯一主内容容器，不能嵌套在<section></section>内，也不能遗漏 - 纯装饰性元素（如分隔线、背景 icon）必须加
aria-hidden="true"或设alt=""，否则会被屏幕阅读器误读
键盘导航不是“能 tab 进去就行”，而是聚焦流必须可预测
用户按 Tab 键时，焦点顺序应与视觉阅读流一致（从上到下、从左到右），且所有交互控件必须可获得焦点。常见断裂点包括：
立即学习“前端免费学习笔记（深入）”；
- 使用
div+onclick模拟按钮，却未加tabindex="0"和role="button" - 轮播图/手风琴组件未实现
ArrowLeft/Right键控制，或焦点未随展开内容自动移入 - 弹出菜单（
role="menu"）未支持Esc关闭，也未将焦点返回触发按钮 - 自定义滚动容器（如
overflow: auto的 div）未监听keydown处理方向键滚动
验证方式很简单：拔掉鼠标，全程只用 Tab / Shift+Tab / Enter / Space / 方向键操作完整流程。
对比度检测不能只看设计师给的色值，要实测渲染后像素
CSS 中写的 #333 在不同背景、不同字体粗细、不同抗锯齿处理下，实际对比度可能低于 4.5:1。尤其要注意：
- 禁用浏览器默认字体平滑（如 macOS 的 subpixel antialiasing）后，浅灰文字在白底上对比度常下降 0.3–0.5
- 使用
font-weight: 300的细体字，比常规400更难满足 AA 要求 - 渐变背景、图片背景上的文字必须用工具实测——推荐用浏览器插件
axe DevTools或桌面端Colour Contrast Analyser (CCA) - 不要依赖设计稿标注的“已达标”，而要在 Chrome DevTools 的「Computed」面板中复制最终渲染色值再检测
最易被忽略的一点：禁用 JavaScript 后，某些通过 JS 动态插入的文本或背景色会失效，此时对比度可能完全不达标——无障碍必须覆盖无 JS 场景。
