上线前必做的 5 项无障碍检查

在上线之前，请按以下顺序执行五项检查：用键盘 Tab 遍历整个 UI、运行自动化扫描、验证语义化 HTML 与标签、检查颜色对比度，以及在 200% 缩放下进行测试。

任何人只要曾经上线过一个悄悄困住键盘用户的模态框，几周后才从 bug 报告中得知真相，就会明白这样一份清单为何存在。这类问题，手里握着鼠标是永远发现不了的。

这五项检查加起来只需几分钟，却能捕获最常见的无障碍缺陷。不需要专业知识，不需要昂贵工具，也不需要花上数周去研究。这是一份可以在每个 pull request 上运行的上线前无障碍检查清单，快速，并且对自身的局限性诚实以待。它无法让你的应用完全符合 WCAG 2.2（当前标准，于 2023 年 10 月作为 W3C Recommendation 发布，并被采纳为 ISO/IEC 40500:2025），但能清除那些对真实用户伤害最大的缺陷。做一点点，远胜于什么都不做。

1. 用键盘 Tab 遍历整个 UI

最快的真实测试是免费的，用时不到一分钟：放下鼠标，用 Tab 键遍历页面，确认你能看到焦点、能到达所有可交互元素，并且能从每个模态框中退出而不被困住。重点关注四件事：每个元素上都有可见的焦点指示器、Tab 顺序符合逻辑、每个 button/link/input 都可到达，以及下拉菜单或对话框中不存在焦点陷阱。

两类 bug 导致了大部分键盘失效问题。第一类是为了重新设计样式而隐藏了原生 outline 的自定义控件。如果你这么做了，请把可见的 :focus（或 :focus-visible）样式加回来：

.custom-checkbox input:focus-visible + .box {
  outline: 2px solid #2563eb;
  outline-offset: 2px;
}

第二类是可点击的 <div>。把它换成 <button>，它默认可获得焦点，并且免费附带 Enter/Space 激活能力和 button 角色。而 <div> 这些统统没有：

// Not reachable by keyboard
<div onClick={handleClick}>Save</div>
// Focusable and operable by default
<button onClick={handleClick}>Save</button>

你手动 Tab 一遍，测试的是你自己设计的理想路径。而对真实会话的 session replay，能暴露那些只在真实环境中出现的键盘与焦点问题：用户 Tab 进入模态框却无法 Tab 出来，或者对话框关闭后焦点消失、跳回文档顶部，让键盘用户彻底迷失方向。回放能让你看到真实的焦点行为在哪里偏离了扫描工具所”批准”的结果。

2. 运行自动化扫描（Lighthouse + axe DevTools）

扫描工具能发现页面上大约三分之一到 40% 的无障碍问题，所以绿色分数只意味着你搞定了那些容易的部分（缺失的 alt 文本、无标签的输入框、低对比度、缺失的 lang 属性），仅此而已。这个区间是测试厂商普遍报告的数据，而且它是下限而非上限：Deque 的 2021 年研究认为，如果统计发现问题的数量而非覆盖的成功准则比例，自动化的覆盖率接近 57%。无论如何，被捕获的这些问题修复成本是最低的。

从 Chrome DevTools 的 Lighthouse 面板运行扫描：打开 DevTools，选择 Lighthouse 面板，勾选 Accessibility，然后生成报告。仅运行无障碍项会很快完成。Lighthouse 的无障碍审计基于 Deque 的开源 axe-core 规则集构建，但只运行了其中一部分规则，因此建议再加上 axe DevTools 扩展，它会运行完整规则集，且只关注无障碍问题。优先修复 Critical 和 Serious 级别的问题。

3. 验证语义化 HTML 与标签

屏幕阅读器通过语义来传达结构，所以要用与任务匹配的元素：<button> 用于操作，<a href> 用于导航，<ul>/<li> 用于列表，<nav> 和 <main> 用于地标区域，标题按顺序使用（h1 → h2 → h3，绝不跳级）。当一切都是 <div> 时，屏幕阅读器只会念出”group, group, group”，页面也就失去了骨架。

每个输入框都需要关联的 <label>；纯图标按钮需要 aria-label，否则只会被念成”button”：

<label htmlFor="email">Email</label>
<input id="email" type="email" />

<button aria-label="Copy to clipboard" onClick={copy}>
  <ClipboardIcon />
</button>

一种常见的生产环境失效模式：一个外观精致的第三方组件库交付了不具备无障碍性的标记，比如某个手风琴或组合框的 <input> 没有 <label>，导致屏幕阅读器什么也念不出来。组件好看并不等于可用。请检查该库实际渲染出的 DOM，确认标签是真实存在的。

4. 检查颜色对比度，不要只依赖颜色

根据 WCAG 成功准则 1.4.3，要达到 Level AA，普通文本的对比度至少需要 4.5:1，大号文本（18pt/24px，或 14pt/18.66px 加粗）至少需要 3:1。这两个数字都应视作硬性下限，不存在向上取整一说，所以实测 4.499:1 就是不合格。界面组件和有实际含义的图标适用另一条更低的标准，即与相邻颜色达到 3:1（SC 1.4.11 Non-Text Contrast），这意味着文本颜色合格并不能保证你的按钮和表单边框也合格。

Lighthouse 会标记出许多文本对比度问题；WebAIM Contrast Checker 则能确认精确比值。举个具体例子：白底上的 #999999 是 2.85:1，不合格；白底上的 #595959 是 7:1，合格。

对比度并不是全部。永远不要仅用颜色来传达错误状态。红色边框对许多色盲用户来说是不可见的，因此要搭配图标和文字，让含义在没有颜色的情况下依然成立。在字段旁边加上”⚠ Email is required”这样的提示信息，而不只是一圈红色轮廓。

5. 缩放到 200% 并尊重减少动效设置

在浏览器 200% 缩放下，不应出现任何重叠、裁切或强制横向滚动。按住 Ctrl/Cmd 并按 +，直到缩放达到 200%，然后四处点击查看：固定宽度容器和基于像素的尺寸设定通常是罪魁祸首。使用 rem 设定尺寸并添加 overflow-wrap，可以让布局保持流动：

.container { max-width: 60rem; padding: 1rem; }
p { overflow-wrap: break-word; }

接着要尊重 prefers-reduced-motion：把非必要的动画包在媒体查询里，这样那些已在操作系统中要求减少动效的用户就不会被它触发不适。该设置要求你去掉纯装饰性的动效，而不是剥离所有动画，因此那些承载信息的动效（加载转圈、进度指示器）应当继续运行。

@media (prefers-reduced-motion: reduce) {
  /* Target the decorative motion, not every animation on the page.
     Loading spinners and other essential feedback should keep moving. */
  .parallax,
  .carousel-autoplay,
  .hero-animation {
    animation: none;
    transition: none;
  }
}

额外加分项，60 秒： 打开屏幕阅读器听一听。在 macOS 上按 Cmd + F5 启动 VoiceOver；在 Windows 上安装免费的 NVDA。Tab 遍历一遍，确认标题、标签和输入框被念出的内容确实有意义。

先上线，再深入

这五项检查是下限，不是上限。它们跳过了复杂的 ARIA 模式、单页应用中的焦点管理，以及无障碍数据表格——这些都是需要另找时间去做的实打实的工作。选好你的下一个功能，在开 PR 之前跑一遍这五项，把发现的 Critical 问题修掉。当你准备走得更远时，WCAG 2.2、WebAIM 和 MDN 的无障碍文档是值得投入时间的一手资料。无障碍是一个持续前进的方向，而今天把这五项检查落地，你就已经在往那个方向走了。

常见问题

无障碍所需的对比度是多少？

对于 WCAG 2.2 Level AA，根据成功准则 1.4.3，普通文本与背景的对比度至少需要 4.5:1，大号文本（18pt/24px，或 14pt/18.66px 加粗）至少需要 3:1。界面组件和有实际含义的图标适用另一条准则 1.4.11，要求与相邻颜色达到 3:1。这两个数字都不能向上取整，所以实测 4.499:1 就是不合格。

自动化无障碍工具能发现所有问题吗？

不能。Lighthouse 和 axe 能暴露大约三分之一到 40% 的无障碍问题，主要是那些容易搞定的部分，比如缺失的 alt 文本、无标签的输入框、低对比度和缺失的 lang 属性。它们无法判断 alt 文本是否有意义、Tab 顺序是否合乎逻辑，也无法判断交互之后焦点是否被妥善管理。Lighthouse 的绿色分数只清除了低成本的修复项，而非整个页面，因此每次扫描都应搭配键盘测试和屏幕阅读器测试。

Lighthouse 和 axe DevTools 有什么区别？

Lighthouse 的无障碍审计基于 Deque 的 axe-core 规则集构建，但只运行了其中一部分，同时它还包含性能、SEO 和最佳实践审计，全部可在 Chrome DevTools 的 Lighthouse 面板中运行。axe DevTools 浏览器扩展会运行完整的 axe-core 规则集，并且只专注于无障碍。用 Lighthouse 做快速排查，再用 axe DevTools 获得更深入的、纯无障碍方向的覆盖。

2026 年应该遵循哪个版本的 WCAG？

遵循 WCAG 2.2，也就是当前标准。它于 2023 年 10 月成为 W3C Recommendation，2024 年 12 月更新，如今同时也是 ISO/IEC 40500:2025，与 2023 年 10 月版内容一致。WCAG 3.0 目前仅以 Working Draft 形式存在，W3C 会定期修订，预计 2027 年底进入 Candidate Recommendation 阶段，最终 Recommendation 预计不会早于 2028 年。WCAG 3.0 在今天不具备任何约束力。