网络应用的无障碍已成为企业无法再忽视的问题。践行包容的道义责任叠加无障碍相关法律带来的合规风险，使得掌握如何构建与测试无障碍应用成为每一位前端开发者必备的重要能力。

网页内容无障碍指南（WCAG）为确保任何人无论有何种障碍都能使用网站制定了标准。多数法规都要求达到 AA 级合规，而这离不开对这些标准的主动理解与持续验证。

无障碍可以贯穿于开发流程的各个环节：

• 方法：规划与开发的方式
• 自动化：将检查集成到自动化测试中
• 手工测试：对应用进行审计
• 超越工程：应对代码之外的问题

方法

树立无障碍意识

第一步就是开始关注无障碍。通读 WCAG 文档，了解众多网页普遍存在的无障碍问题，努力成为团队中推动无障碍的倡导者。一旦稍作深入，你很快就会发现，原来有如此多的问题是你过去有幸从未需要考虑过的。

目标是在尽可能早的阶段就把无障碍纳入考量。在需求规划和细化会上主动提出无障碍相关问题，确保从一开始就将其融入工作方式。对于会降低整体无障碍水平、增加无障碍技术债的改动要敢于提出反对。仅靠自动化测试来发现问题是远远不够的。

复用现有方案

借助公开或内部的组件库，可以避免重复造轮子、从零解决常见的无障碍问题。使用 MUI 或 Chakra 这类组件框架，能够直接获得已内置无障碍能力的常用组件。通过设计系统库来共享内部组件，也有助于在团队间复用无障碍最佳实践，做到一次解决、处处受益。

尽可能优先使用浏览器原生元素，因为它们已针对多种使用场景实现了无障碍支持。你真的需要自己去实现一个自定义的 <select> 或 <input type="date" /> 吗？

如果必须自行构建自定义组件，react-aria 提供了一系列 React Hook，能为大多数常用组件提供无障碍支持和交互行为。

Storybook

Storybook 是一款用于隔离开发、编写文档和测试前端组件的优秀工具。它还为无障碍测试提供了一些实用功能。

借助 无障碍插件，每个 story 都会由 axe 自动扫描，检测到的问题会展示在面板中。这能在组件开发过程中快速反馈潜在的无障碍问题。

该插件还提供了多种色彩滤镜，可模拟不同类型色盲用户所看到的界面效果。利用它可以轻松验证界面对色盲用户是否依然可用。

自动化

使用无障碍 Lint 规则

静态分析能够发现部分无障碍问题。在 ESLint 配置中引入类似 eslint-plugin-jsx-a11y 的插件，就能检测出诸如 img 标签缺少 alt 属性、aria 属性使用不规范等问题。

这样在编写 JSX 时就能在 IDE 中获得即时反馈。

使用 Testing Library 编写单元测试

Testing Library 鼓励开发者编写更健壮、不易因重构而失效的测试。与类似 XPath 的选择器不同，它提倡像真实用户那样去查找页面元素，这种查询方式在设计变更或重构后更不容易失效。例如，通过标签文本 Password 查找密码输入框，即使页面设计全面重做，测试依然有效；而通过 .password-input 类名查找则很容易失效。

这种方式还有一个好处，就是能促使组件更具无障碍性。标签和 aria 属性既让你更容易基于语义化标签编写健壮的测试，也让使用读屏软件的用户更容易找到这些元素。如果你发现用 Testing Library 内置的选择器很难写出查询，那很可能说明你的界面本身就不符合无障碍标准。

Testing Library 已与多种框架集成，包括 React、Angular、Svelte 以及 原生 DOM。

在单元测试与集成测试中使用 axe

axe 是一款强大的网页无障碍自动化测试工具。它可以扫描页面中的无障碍问题，并能与自动化测试流程中的多种测试工具集成。

你可以将 axe 与 Playwright 和 Puppeteer 等自动化浏览器测试工具结合使用。通过对应用的每个页面进行测试，你能在发布前就发现无障碍问题。如果是在已有项目中引入，还可以通过快照测试建立现有无障碍问题的基线，确保在新增功能时不会让情况进一步恶化。

借助 jest-axe，你可以在 JSDOM 环境中添加利用 axe 检测无障碍问题的单元测试。这有助于更早获得反馈，而不必等待完整集成测试的结果。

手工测试

像 axe 这样的自动化测试工具平均只能发现约 60% 的无障碍问题。例如，自动化工具能检测出 <img /> 元素上是否存在 alt 属性，却无法判断其中的文字是否真正有意义地描述了图片。因此，手工测试也应纳入你的无障碍工作流。

像 VPAT 这类文档可用于指导手工测试，并可分享给外部用户以证明应用对无障碍标准的合规程度。定期对手工评估和复查无障碍情况，有助于发现问题、持续跟踪改进，也能让用户确信你正在将无障碍放在优先位置。

让真正有障碍的用户来测试你的网站，是检验系统真实无障碍水平的最佳方式。试着用读屏软件或在不使用鼠标的情况下使用你的网站，亲身感受它的可用性究竟如何。

超越工程

仅靠工程上的最佳实践无法解决所有的无障碍问题——整个组织都需要参与进来。

设计师需要在最初的 UX 和 UI 设计阶段就考虑无障碍。像 Figma 这类工具提供了 无障碍集成，有助于确保设计稿在创作时就兼顾无障碍。

任何生产网页内容的人都应了解无障碍及其重要性。你的 CMS 也许会要求为图片填写 alt 文本，但每个人都明白这一字段的重要性、知道如何为读屏软件用户编写可用的描述吗？所有产出的视频内容都配有字幕吗？

通过员工资源小组（ERGs）或跨职能工作组等方式，有助于在组织内统筹和推广无障碍的重要性。从办公设施到内部系统，再到面向外部的网络应用，无障碍都需要被纳入考量，而重视这些需求的文化也需要有人去积极倡导和推动。