网页无障碍基础

每四个美国成年人里就有一个带着某种形式的残障生活，而世界卫生组织估算全球约有 13 亿人存在不同程度的障碍。然而当我们用 WAVE、axe 这类自动化工具扫描排名靠前的一百万个首页时，中间值的网站依旧有几十个 WCAG 检查点不达标。这缺口不是技术问题——做无障碍界面所需的 HTML、CSS、JavaScript 早已存在多年。真正的缺口是流程问题：绝大多数团队把无障碍当成上线前的“最后审计”，而不是从第一张线框到最终代码评审都贯穿始终的硬性要求。

这篇文章是为开发者、设计师和产品人准备的一条实用入口，目标是帮你从“缝缝补补式无障碍”转向“原生内置式无障碍”。你会弄明白哪些标准真正重要、审计工具到底能测出什么又漏掉什么、无障碍改造到底要花多少钱，以及能防止网站倒退的具体习惯。如果你在搭现代应用，无论是从零开始还是一头扎进某个 Web 框架，以下基础都适用——而让页面变快的性能纪律，和交付无障碍体验所需的工作高度重合。

WCAG 合规到底要求什么

WCAG（网页内容无障碍指南）按四大原则组织：可感知（Perceivable）、可操作（Operable）、可理解（Understandable）、稳健（Robust）。其下有 A、AA、AAA 三个合规层级，对绝大多数组织来说 AA 是现实且具有法律意义的达标线。像美国人残障法案（ADA）和欧洲无障碍法案（EAA）这类法规，通常对应 WCAG 2.1 或 2.2 的 AA，所以这也是你合规团队会反复引用的那条杠。记忆模型很优雅：如果用户因为内容只用颜色传达而无法感知，因为界面必须用鼠标操作而无法操作，因为错误提示含糊而无法理解页面，或因为辅助工具无法稳健解析标记而通不过，你的无障碍缺陷往往同时踩中好几条原则。

最常见的高发失败点

别去背每个检查点，背那些真实审计里最容易翻车的模式就够了：缺 alt 文本、颜色对比度不足、键盘陷阱、缺表单标签、标题没有描述页面结构。修好这五类问题，就能覆盖你第一次扫描时报告的大部分自动化错误。以后每一次改版上线前，都应该把同样这五条再跑一遍。

自动化工具的局限在哪

axe、WAVE、Lighthouse、Siteimprove 这类工具不可或缺，但它们只给出一半的图画。它们能抓出确定性的失败——没有 alt 的图片、没有标签的字段、对比度低于 4.5:1 的配色；但判断不了焦点顺序对读屏用户是否真的顺、轮播图好不好懂、你写的 alt 文本是“够好”还是仅仅“存在”。这正是业界区分自动化测试与人工辅助测试的原因，也是 WebAIM Million 报告反复提醒“仅靠自动扫描永远会低估真实无障碍债务”的缘由。

搭建“测试金字塔”

• 自动化层：每次 Pull Request 都在 CI 里跑一遍 axe-core，成本低、持续拦截回归。
• 抽查层：每个迭代用免费读屏 NVDA（Windows）或 VoiceOver（Mac）人工过一遍关键流程。
• 用户层：每季度至少做一次带真实用户的引导式测试，解决机器人永远做不了的主观判断。

无障碍改造真实成本：起步时机决定一切

“无障碍很贵”是个顽固的误区，真相几乎完全取决于你何时开始。改造存量站点很贵，因为你付的是“撤销旧决策”的钱；一开始就做得无障碍很便宜，因为你只在构建期多付出几乎可忽略的一点成本。英国残障商业论坛早就量化过：在设计阶段修一个无障碍问题的成本，只是上线后修同一问题的零头。当无障碍是硬性要求时，一个能用键盘导航的按钮和一个只能点鼠标的按钮，代价几乎一样；一张有 alt 的图片和一张没有的图片，代价也一样。

给小中型营销站算一笔现实的账：axe 的 CI 集成花的工程时间是以“小时”计而不是“天”；十个核心模板的 WAVE 人工过一遍每个迭代也就几小时；每季度一次的用户引导测试，通过 UserTesting 之类服务花几百美元，或干脆内部做。对比之下，一次追溯性的法律补救，对中等规模公司动辄六位数美元加几个月折腾。经济账根本不用算——无障碍以绝对优势更便宜，而且还能让你不进法庭。

现在就能跑的“纯键盘审计”

找出最常见的无障碍缺陷不需要特殊软件，一次纯键盘过检抓到的真实问题往往比许多自动扫描还多。先把鼠标拔掉，把焦点放到页面顶部，然后反复按 Tab。盯三件事：每个交互元素是否都能到达、焦点环是否始终可见、顺序是否和视觉布局一致。再用回车和方向键在 select 和 checkbox 上走一遍，确认键盘完全可用。最后用读屏器或浏览器的无障碍树点进页脚，确认阅读顺序合理。

多数团队跑完这一遍，至少会揪出一个逃不掉的弹窗、一个必须悬停才展开的下拉，或一个被 outline: none 抹掉的焦点环——这些恰恰就是制造用户投诉和法律函件的元凶。凡是动了导航、表单或弹窗的 Pull Request，都强制跑一次纯键盘过检，你就能在上线前干掉绝大多数可解决的问题。这是你所能采纳的回报率最高的无障碍习惯。

让无障碍与设计、性能协同工作

无障碍想扛过“上线”这关就不能孤立存在，要把它绑进让你网站又快又好维护的那套系统里。语义化 HTML 对无障碍和性能是双赢，因为原生元素自带键盘行为、焦点管理和角色，否则你得手搓一套。lang 属性、合理标题层级、规范的表单标签都是免费福利，还能让全组同事更好维护标记。这也解释了为什么无障碍和你在 Web 开发课程里学到的纪律天然合拍，又理应成为你讨论 Web 性能优化时长期的固定议题。

给每个 Pull Request 定一个轻量的“无障碍完成”定义：自动化检查绿、键盘过检完成、alt 文本存在且有意义、任何新配色都验证过对比度。把这份“完成定义”公开给团队，让评审者照章执行而不必扮演“无障碍警察”。几个迭代之后这些检查就会自动化，回归骤降，工具成本几乎为零——因为它本来就是你构建方式的一部分。无障碍不再是吓人的大项目，而只是你交付 Web 工作的标准方式，正如你从扎实的地基开始养成的习惯一样。

常见问题

到底要按 WCAG 2.2 AA 还是 2.1 合规？

目标定为 WCAG 2.2 AA，因为它是当前推荐标准，新增项（目标尺寸、焦点外观）也越来越被监管方引用。多数自动化工具现在默认就查 2.2。如果你有存量页面，优先补齐 2.2 的焦点外观和目标尺寸，是用低投入达到新杠的实惠办法。

快速发现自己站点无障碍问题的最快方法是什么？

在最重要的页面上跑一遍 axe DevTools 扩展，再做一次纯键盘 Tab 遍历。扩展抓确定性错误，键盘过检抓交互问题，两者互补，几小时就能暴露大部分真实问题。

用 CSS 和 JS 的“无障碍覆盖层”能修复问题吗？

不能。号称“一键 WCAG 合规”的自动化覆盖组件大多只处理症状，甚至可能因注入重复 UI 而干扰辅助技术。修好底层 HTML、对比度和焦点行为才是持久方案，这也是任何 Web 开发流程里都在强化的纪律。覆盖层还带法律风险——它们承诺合规却很少真正做到。

无障碍是不是只跟视障用户和读屏器有关？

不是。它涵盖低视力、色盲、运动障碍、听力损失、认知差异，以及断臂、强光这类暂时性状况。为稳健而设计对所有人都有益——字幕帮到嘈杂房间的人，大目标帮到戴手套或触屏的人。无障碍本质上是面向更大人群的优质用户体验。想系统掌握这些页面构建的底层能力，可以参考 Python 入门指南与 编程入门基础里对结构、清晰与规范的一贯强调。

延伸阅读：Python 自动化脚本教你用代码简化重复劳动，Web 开发课程与 Web 性能优化能帮你夯实构建现代页面的基本功。