📚 课程目录第2章无障碍标准概述

无障碍标准概述：WCAG 2.1/2.2、ARIA 规范、Section 508

说实话，我刚接触无障碍测试那会儿，看着一堆标准名字就头疼。WCAG、ARIA、Section 508……每个都号称“必须遵守”，但到底谁管什么、优先级怎么排，脑子里一团浆糊。后来在项目中踩了坑才明白——这三者不是互替关系，而是三个不同维度的“指挥棒”。

这一章，我就从实战角度拆解这几个核心标准。你不必死记条款，关键是要理解它们在你的 CI 管道里分别当什么裁判。

WCAG 2.1 与 2.2 — 四大原则才是真骨架

WCAG（Web Content Accessibility Guidelines）是所有无障碍标准的“地基”。它从 2.0 走到 2.2，核心骨架没变——还是那四个原则：可感知、可操作、可理解、健壮性。我习惯简称为“POUR”。

WCAG 2.1 在 2.0 基础上加了 17 条成功标准，主要补了移动端和低视力场景。比如“非文本内容的替代文本”（1.1.1）这都老生长谈了，但 2.1 里对“输入方式”这一块新增了“手势操作”的支持——说白了就是别只靠点按，还得支持滑动、语音。

WCAG 2.2 又要来了？对，它主要改进了“焦点顺序”和“目标尺寸”。原来最小点触目标建议是 44px，现在提了提。嗯，这里要注意：2.2 还没到强制阶段，但行业里已经在预演了。

我的习惯：在 CI 管道里，我会把 WCAG 2.1 AA 级作为默认基线。AA 级覆盖了多数常见障碍，对成本也友好。AAA 级……说实话很少客户愿意为它花预算。

ARIA 规范 — 给动态内容装上“语音文案”

WCAG 告诉你要“可感知”，但怎么落实？比如一个弹出菜单，纯 HTML 做不到告诉读屏软件“这个菜单展开了”。这时候就需要 ARIA（Accessible Rich Internet Applications）。

ARIA 提供了三样东西：角色（Role）、属性（Properties）、状态（States）。你想想看，一个普通的 <div> 能变成按钮、标签页、树形控件——全靠 ARIA 给它“配音”。

但我得说：ARIA 不是万能药。滥用 ARIA 甚至比不用更糟。

我曾经……给一个自定义下拉框加了一堆 aria-activedescendant 和 aria-owns，结果读屏软件直接崩溃。后来发现原生 <select> 加上一点样式就能搞定，完全不需要 ARIA。
避坑指南：第一原则——能用原生 HTML 实现，就别用 ARIA。ARIA 是“补丁”，不是“标准实现”。

来看一个典型的问题示例：

<!-- 错误做法：裸 div 硬装按钮 -->
<div role="button" tabindex="0" onclick="submit()">提交</div>

<!-- 正确做法：原生 button -->
<button type="submit">提交</button>

在 CI 管道里，我通常用 eslint-plugin-jsx-a11y 或 axe-core 来扫描 ARIA 的误用。这两个工具对 ARIA 规则覆盖很全。

Section 508 — 美国的“法律底限”

如果你的客户是美国联邦政府机构，那 Section 508 就是必过的门框。它本质上是一个法规，要求所有电子和信息技术（包括网站、软件、文档）对残障人士可访问。WCAG 2.0 AA 级被写进了 508 的强制条款。

Section 508 里有一些特有要求：

含视频的页面必须提供字幕（跟 WCAG 1.2.2 重叠）
所有功能都必须能通过键盘操作（连鼠标都不碰）
文档（PDF、Word）也要满足 508 ——这一点经常被 CI 管道忽略

我记得有个项目，客户是国防部供应商，我专门在 CI 里加了一个步骤，对生成的 PDF 做标签检查。结果发现自动生成的表格头没给 <th> 标签，直接被打回。从那以后，我都在构建脚本里跑 PDF Accessibility Checker 的命令行版本。

三大标准对比速查

下面这个表我经常贴在团队知识库里，现在拿来用：

标准	核心侧重点	适用场景	CI 管道中重点检查
WCAG 2.1/2.2	网页内容本身的可访问性（四大原则）	所有公共网站、商业应用	颜色对比度、alt 文本、焦点顺序
ARIA	动态交互内容的语义补充	单页应用、自定义控件、富互联网应用	角色正确性、状态同步、焦点管理
Section 508	法律合规性（包含 WCAG 2.0 AA）	美国联邦政府项目、受资助机构	文档可访问性、键盘全程操作

它们怎么在 CI 管道里协作？

我自己做配置时，会把这三个标准分成两层：

第一层是 自动检查：用 lint 工具和 axe-core 跑 WCAG 和 ARIA 规则，顺便拉一下 Section 508 的条款映射表（axe-core 已经内置了 508 规则）
第二层是 手动触发：碰到视频、PDF、canvas 之类，我会单独写一个脚本调用第三方工具做 508 专项检查

为什么分两层？因为全自动化会漏掉 508 里那些“非网页内容”的条款。但 CI 管道又不能拖慢发布速度，所以我只把最核心的 WCAG 规则放进 Pre-commit hook，508 的完整检查放到 nightly 构建里。

    一句话总结：WCAG 定目标，ARIA 给方法，Section 508 划红线。你的 CI 管道里最少要覆盖前两个，第三个看项目定。

这张图我放在每个项目的 README 里。你看，WCAG 和 Section 508 共享了“内容要求”的部分，而 ARIA 更多是去填补动态交互里的语义空缺。箭头表示它们之间的依赖或补充关系。