第2章：无障碍标准与规范（WCAG）
2.1 什么是WCAG？
WCAG全称是 Web Content Accessibility Guidelines（网页内容无障碍指南），由W3C发布。说白了，它就是一套让残障人士也能正常使用网页和App的国际标准。
我记得刚做前端那会儿，觉得这东西离我挺远的。直到有一次，一个政府项目因为无障碍问题被退回——页面没有提供足够的颜色对比度，视觉障碍用户根本看不清按钮。嗯，从那以后我再也不敢轻视WCAG了。
目前主流版本是 WCAG 2.1 和 WCAG 2.2。2.2在2023年发布，新增了一些针对移动端和认知障碍的成功标准。但在实际项目中，2.1依然是绝大多数团队的首选。
核心要点：WCAG不是法律，但很多国家（如美国、欧盟、日本）将其纳入法规要求。不做无障碍，你可能面临法律风险。
2.2 四大原则：POUR
WCAG的核心框架是四大原则，缩写为 POUR。你想想看，如果内容连感知都做不到，那后面的操作和理解就更无从谈起。
- 可感知（Perceivable）：信息必须能以用户能感知的方式呈现。比如图片加alt文本、视频配字幕。我在项目中遇到过最典型的坑是图表只用颜色区分数据，色盲用户完全分不清。
- 可操作（Operable）：界面元素必须能通过键盘、鼠标、触摸等方式操作。说白了，如果用户只用键盘也能完成所有操作，就达标了。
- 可理解（Understandable）：信息和界面要让人看得懂。比如错误提示要明确、表单标签要清晰。别让用户猜你要他做什么。
- 健壮性（Robust）：内容必须能被辅助技术（如屏幕阅读器）正确解析。其实就是语义化HTML + 合理的ARIA标注。
我的经验：POUR不是一次性就能搞定的。我一般会按「可感知 → 可操作 → 可理解 → 健壮性」的顺序逐项检查，这样思路最清晰。
2.3 三个等级：A、AA、AAA
WCAG把成功标准分为三个等级，要求从低到高：
| 等级 | 含义 | 实战建议 |
|---|---|---|
| A级 | 最低要求，必须满足 | 这是底线。如果不达标，部分用户将完全无法访问内容 |
| AA级 | 中级标准，推荐目标 | 大多数项目以AA为合规目标。我个人习惯在CI中卡AA标准 |
| AAA级 | 最高要求，最难实现 | 极少数场景需要。比如针对视障用户的专用网站。一般项目不用强求 |
我建议新团队先冲到AA。AAA很多标准在实际项目中几乎不可能完全满足，硬追性价比不高。
注意：不要以为AA就很容易。我曾经审计过一个电商项目，光是「颜色对比度≥4.5:1」这一条，就改了二十几个组件。一开始没注意，后面全是债。
2.4 关键成功标准（实战重点）
WCAG 2.1有50条成功标准，但日常开发中我们最常用的就那几条。我挑几个高频且容易出问题的说一下。
- 1.4.1 颜色使用：不要只用颜色传递信息。比如「红色=错误，绿色=正确」，色盲用户分不清。加个图标或文字就解决了。
- 1.4.3 对比度：正文文本对比度≥4.5:1，大文本≥3:1。工具推荐WebAIM的对比度检查器。
- 2.1.1 键盘操作：所有功能必须能用键盘完成。tab键导航、回车键激活、方向键选择。这些是基本功。
- 3.3.2 标签与提示：每个表单控件都要有清晰的label。placeholder不能代替label，相信我，屏幕阅读器不会读placeholder。
- 4.1.2 名称、角色、值：自定义组件必须通过ARIA暴露正确的语义。比如一个div模拟的按钮，必须加上role="button"和aria-label。
优先级排序（我自己的清单）：
- 颜色对比度（最容易翻车）
- 键盘可操作（无键盘=不可用）
- 语义化结构（屏幕阅读器依赖于此）
- 表单标签（用户体验的起点）
2.5 落地工具与检查清单
光看规范是不够的，得有趁手的工具。我在项目中常用的组合是：
- axe DevTools：浏览器插件，能自动检测50+条WCAG规则。我习惯在开发阶段随时跑一遍。
- Lighthouse：Chrome自带的审计工具，无障碍评分很直观。CI中可以用puppeteer + Lighthouse自动跑。
- WAVE：WebAIM的工具，可视化展示无障碍问题。适合给非技术人员讲解。
- 手动测试：只用键盘操作一遍页面，再用屏幕阅读器（NVDA或VoiceOver）走一遍。自动化工具只能查出30%的问题，剩下的靠人工。
我曾经踩过一个坑：自动化工具全绿，但视障用户反馈完全无法操作。原因是什么？工具检测不到「焦点顺序不合理」这类体验问题。所以自动化+人工必须结合。
CI集成建议：我个人习惯在CI中加两个步骤——先用axe跑全量检测，再用Lighthouse卡AA标准。跑不过直接阻断合并。这样能拦住大部分回归问题。