Web 无障碍（a11y）：从 WCAG 到落地实践

全球约 16% 的人口存在某种形式的残疾。Web 无障碍（Accessibility，简称 a11y）不是「给残障人士的特殊功能」，而是让所有人——包括老年人、临时受伤者、网络环境差的人群——都能使用你的产品。更重要的是，无障碍做得好的网站，SEO 和用户体验通常也更好。

WCAG 2.2 四大原则

Web Content Accessibility Guidelines 将所有要求归纳为 POUR 四原则：

• 可感知（Perceivable）：信息和 UI 组件必须以用户能感知的方式呈现
• 可操作（Operable）：UI 组件和导航必须可操作
• 可理解（Understandable）：信息和 UI 操作必须可理解
• 健壮（Robust）：内容必须足够健壮，可被各类用户代理解释

合规等级分 A、AA、AAA 三级，大多数法规和政企采购要求达到 AA 级。

语义化 HTML：成本最低、收益最高

屏幕阅读器依赖 HTML 语义来理解页面结构。最常见的修复方式往往不需要任何 JavaScript：

<!-- 错误：全部用 div 堆砌 -->
<div class="nav">
  <div class="link" onclick="goHome()">首页</div>
</div>

<!-- 正确：语义化标签 + 键盘可达 -->
<nav aria-label="主导航">
  <a href="/">首页</a>
</nav>

<main>
  <h1>文章标题</h1>
  <article>...</article>
</main>

关键实践清单

1. 图片 alt 文本：信息性图片写描述，装饰性图片用 alt=""
2. 颜色对比度：正文文字与背景对比度 ≥ 4.5:1（AA 级），用 Chrome DevTools 的 Contrast Checker 检测
3. 键盘导航：所有交互元素可通过 Tab 键到达，焦点顺序符合视觉顺序
4. 焦点可见：不要 outline: none，自定义清晰的 focus 样式
5. 表单标签：每个 input 关联 <label> 或 aria-label
6. 动态内容：SPA 路由切换后用 aria-live 区域通知屏幕阅读器

ARIA 的正确使用

ARIA（Accessible Rich Internet Applications）是补充语义化的工具，但有一条铁律：

不要在没有原生 HTML 元素可用时使用 ARIA。先选对标签，再考虑 ARIA。

常见 ARIA 属性：

• role="button" + tabindex="0"：让 div 充当按钮（但优先用 <button>）
• aria-expanded：折叠面板的开合状态
• aria-hidden="true"：对屏幕阅读器隐藏装饰性元素
• aria-describedby：关联错误提示文本

自动化检测工具

• axe-core：集成到 CI 流水线，自动扫描页面违规项
• eslint-plugin-jsx-a11y：编码阶段拦截常见错误
• Lighthouse Accessibility：快速评估，但只能发现约 30% 的问题
• 手动测试：用 VoiceOver（macOS）或 NVDA（Windows）实际操作一遍

法规与商业影响

欧盟《欧洲无障碍法》（EAA）已于 2025 年 6 月生效，要求电商、银行、交通等数字服务满足 EN 301 549 标准。美国 ADA 诉讼数量连年增长。提前投入无障碍建设，比被动应对诉讼成本低得多。

小结

无障碍不是项目末期的「补丁」，而是从设计阶段就纳入的工程质量标准。语义化 HTML + 键盘可达 + 足够对比度，这三项就能覆盖大部分 AA 级要求。