网页无障碍（a11y）指南：让网站对所有人可用

无障碍的核心不是“通过检查工具”，而是让用户在真实任务里不被卡住。比如用户只用键盘完成注册、用屏幕阅读器提交表单、在低亮度或高反光环境里查看价格信息。你的网站如果在这些场景下可用，才算真正可用。对商业网站而言，这直接影响咨询转化、下单成功率和品牌信任。

1. 先把 WCAG 2.2 转成工程语言

WCAG 常被误解成纯设计规范，其实它可以直接对应到前端实现任务。

原则 页面表现 开发动作
可感知（Perceivable） 图片、图标、视频信息可被获取 alt、字幕、语义标题层级
可操作（Operable） 键盘可完整操作主要流程 可见焦点、逻辑 Tab 顺序、跳过导航
可理解（Understandable） 表单与反馈语义清晰 label、错误提示、一致交互
稳健（Robust） 辅助技术可稳定解析 正确语义标签、ARIA 谨慎补充

一个实用经验是：先写语义 HTML，再补 ARIA。反过来经常会出现 role 写得很多，但真实体验仍然混乱。

2. 关键组件实现范式

导航与跳转

<a class="skip-link" href="#main">跳到主要内容</a>
<nav aria-label="主导航">
  <a href="/products">产品</a>
  <a href="/pricing">价格</a>
  <a href="/contact">联系</a>
</nav>
<main id="main">
  <h1>产品中心</h1>
</main>

.skip-link {
  position: absolute;
  left: -9999px;
}
.skip-link:focus {
  left: 16px;
  top: 16px;
  background: #fff;
  padding: 8px 12px;
  border: 2px solid #111;
}

表单与错误提示

<form novalidate>
  <label for="email">邮箱</label>
  <input id="email" name="email" type="email" aria-describedby="email-error" required />
  <p id="email-error" aria-live="polite"></p>
  <button type="submit">提交</button>
</form>

这段结构的意义在于：错误信息不只“看得到”，还“读得到”。

弹窗焦点管理（最常出问题）

const openBtn = document.querySelector('#open-modal');
const modal = document.querySelector('#modal');
const closeBtn = document.querySelector('#close-modal');

openBtn.addEventListener('click', () => {
  modal.hidden = false;
  closeBtn.focus();
});

closeBtn.addEventListener('click', () => {
  modal.hidden = true;
  openBtn.focus();
});

3. 自动化检测与人工走查要结合

自动化工具能快速扫出基础问题，但不能替代真实任务测试。推荐把这两层都纳入发布流程。

# Lighthouse CLI
npx lighthouse https://example.com --only-categories=accessibility --view

# axe-core 批量检查（示例）
npx @axe-core/cli https://example.com https://example.com/contact
无障碍不是“做给特殊人群看的附加功能”，而是网站可用性的底线。真实场景里，用户可能在地铁上单手操作、在强光下看屏幕、临时断网后重新提交表单、或者依赖屏幕阅读器完成支付流程。只要这几个环节有一个被卡住，业务上看到的就是转化下降、投诉增加、品牌信任受损。

### 1. 用 WCAG 2.2 把问题拆成可执行项

把 WCAG 四大原则（可感知、可操作、可理解、健壮）落到页面层面，最容易上手：

| 原则 | 页面层问题 | 最低修复动作 |
|------|------------|--------------|
| 可感知 | 图片无替代文本、视频无字幕 | 信息图补 alt，视频补字幕或文本稿 |
| 可操作 | 只能鼠标点击、焦点不可见 | 全流程可键盘操作，焦点样式清晰 |
| 可理解 | 错误提示模糊、语言不一致 | 明确错误原因，设置页面语言属性 |
| 健壮 | 语义结构混乱、ARIA 误用 | 使用标准标签，减少无必要 ARIA |

一个简单判断标准是：用户不看视觉界面，也能顺畅完成“进入页面 -> 找到按钮 -> 提交成功”。

### 2. 组件级实践：表单、弹窗、导航最先做

表单和弹窗通常是无障碍问题高发区。下面是一个可复用的表单错误提示写法：

```html
<form aria-describedby="form-hint" novalidate>
  <p id="form-hint">带 * 的字段为必填。</p>

  <label for="email">邮箱 *</label>
  <input id="email" name="email" type="email" aria-describedby="email-error" required />
  <p id="email-error" aria-live="polite"></p>

  <button type="submit">提交</button>
</form>

:focus-visible {
  outline: 3px solid #0b6bcb;
  outline-offset: 2px;
}

弹窗要点是“打开时把焦点移入弹窗，关闭时归还到触发按钮”，否则键盘用户会迷失在 DOM 树里。

3. 自动化检测 + 人工任务流测试缺一不可

自动化工具能快速发现明显错误，但无法替代真实操作测试。建议把这两类检查都做：

# Lighthouse 无障碍评分
npx lighthouse https://example.com --only-categories=accessibility --view

# axe 批量检查（示意，可按项目集成）
npx @axe-core/cli https://example.com

人工测试最少跑三条路径：

  1. 首页到产品页（键盘操作）；
  2. 登录或注册流程（错误提示是否可读）；
  3. 提交表单后的成功反馈（是否被屏幕阅读器播报）。

4. 常见问题与修复优先级

问题 影响等级 修复建议
只有颜色区分状态（例如仅红色报错） 高 增加图标/文案，保证非颜色信息可识别
键盘无法触达菜单子项 高 修复 Tab 顺序与展开逻辑
图标按钮无可读名称 中 增加 aria-label 或可见文本
标题层级跳跃（H1 直接到 H4） 中 重建语义层级，方便辅助技术解析
轮播自动播放无法暂停 中 提供暂停/停止控制

5. 场景案例：活动报名页为何“看起来能用却报错高”

某活动站报名页视觉设计完整，但移动端提交失败率高。排查发现：

  • 输入框 placeholder 当成标签使用，读屏无法识别字段含义；
  • 错误提示仅显示红色边框，没有文字说明；
  • 提交后提示在页面顶部，焦点未移动，用户以为没有成功。

改造后把字段标签、aria-live 提示和焦点管理补齐，提交成功率显著提升。这个案例说明，无障碍优化往往直接影响业务指标，而不是“合规文档上的勾选项”。

6. 把 a11y 接入团队流程

可执行做法是把无障碍验收写入 PR 清单：

  • 组件是否支持键盘完整操作；
  • 交互状态是否可被屏幕阅读器感知；
  • 文案是否明确且可理解；
  • 对比度是否满足最低标准。

如果你在搭建长期内容站，还可以结合2026 年网站 SEO 完全指南同步优化页面结构，因为语义化和可读性通常也会改善搜索引擎理解。

7. 最小上线检查清单

  • 全站可用键盘完成核心任务；
  • 所有图片有合适 alt（装饰图为空 alt）；
  • 表单错误有文本说明并可播报；
  • 焦点样式在亮色/暗色背景都清晰；
  • 移动端 200% 缩放后核心功能仍可操作。

做好无障碍，不会让页面一夜之间“更炫”，但会让更多用户稳定完成任务。这恰恰是一个网站长期竞争力的重要部分。

参考：https://www.w3.org/WAI/standards-guidelines/wcag/

参考：https://www.w3.org/WAI/WCAG22/quickref/

参考：https://developer.mozilla.org/en-US/docs/Web/Accessibility