无障碍——WCAG 2.1 AA合规的改造之路
2026年3月，一家欧洲的潜在企业客户发来了一份长达12页的《供应商可访问性评估问卷》。其中核心问题是："贵司的产品是否满足WCAG 2.1 AA无障碍标准？"我们当时的回答很诚实："目前没有，但我们在计划中。"对方回复："请达标后再联系我们。"
这次对话是触发器，但真正推动我们投入无障碍改造的，是更深层的产品信念——好的产品应该对所有人可用，无论他们是否有身体障碍。全球有超过10亿人（约占世界人口的15%）有某种形式的残疾。在中国，65岁以上的老年人口超过2亿。这些人中的很多是我们产品的潜在用户，但因为无障碍支持不足，他们被挡在了门外。
从4月到7月，我们花了3个月时间进行系统性的无障碍改造，最终通过了WCAG 2.1 AA标准的合规审查。这篇文章记录了这条改造之路的全过程。
审计先行：不知道哪里有问题就不可能修复
无障碍改造的第一步是客观评估现状。我们使用了三套工具对EIOS进行全面的可访问性审计：自动化扫描工具（axe-core、Lighthouse Accessibility）覆盖所有页面和组件，发现了217个自动化可检测问题；手动审计（基于WCAG 2.1 AA的50条成功标准逐项检查）发现了89个自动化工具无法识别的问题；真实用户测试——我们邀请了3位有不同障碍类型的用户（视力障碍使用屏幕阅读器、肢体障碍使用键盘导航、色觉障碍）进行实际使用测试，发现了31个真实使用中的致命问题。
审计结果让我们震惊。217个自动化问题中，最常见的三类是：缺少图片替代文本（alt属性）占34%，颜色对比度不足占22%，表单缺少关联标签占18%。这些问题单看都不复杂，但累积起来让产品对辅助技术用户极不友好。
更让我们惭愧的是用户测试的发现。一位使用屏幕阅读器的用户花了15分钟还没有完成"发送第一条AI消息"的操作——因为输入框缺少正确的ARIA标签，发送按钮没有可识别的角色描述，AI回复的内容结构无法被屏幕阅读器正确解析。这位用户平静地说："我已经习惯了，大多数网站都这样。"这句话比任何投诉都让我们难受。
屏幕阅读器适配：让代码会说话
屏幕阅读器（如NVDA、VoiceOver）是视障用户的核心工具。它们将页面内容转化为语音或盲文输出。但屏幕阅读器不能"看懂"视觉设计——它只能"读懂"HTML语义和ARIA标注。
v1.0的HTML大量使用div和span元素构建UI，缺乏语义化的HTML标签。一个对话列表在视觉上是清晰的列表结构，但在代码中是div嵌套——屏幕阅读器无法识别这是列表，只能读出"分组、分组、分组、文本"。
改造从HTML语义化开始。将功能性元素替换为语义化标签——导航用nav，列表用ul/li，按钮用button而非div+onclick，标题用h1-h6建立页面大纲。为动态交互组件（对话框、下拉菜单、标签页）添加正确的ARIA角色、状态和属性——如aria-expanded表示展开/折叠状态，aria-selected表示选中状态，aria-live polite用于动态变化的内容区域。
对话界面的适配是最复杂的。AI生成的消息包含多种内容类型——纯文本、代码块、表格、列表、链接。我们为每种内容类型定义了屏幕阅读器专属的阅读策略。代码块加上语言标注（aria-label="Python代码"），表格确保th和td的正确关联，链接用描述性文本而非"点击这里"。
屏幕阅读器测试成为开发流程的一部分。每个新功能组件在开发时就需要通过屏幕阅读器测试——开发者使用VoiceOver或NVDA实际体验一遍自己编写的代码，确保信息能被正确传达。这种"开发者自己用屏幕阅读器"的做法效果远超预期——亲身经历比任何文档都更有说服力。
键盘导航：不是所有人都用鼠标
许多肢体障碍用户无法使用鼠标，完全依赖键盘或替代输入设备（如头控、眼动追踪）。键盘导航的核心是：用户能够通过Tab键在所有可交互元素之间移动，通过Enter/Space激活元素，通过Escape关闭弹窗或取消操作。
v1.0的键盘导航存在三大问题：焦点顺序不逻辑——Tab键在页面元素间的跳转顺序与视觉布局不一致，用户迷失方向；焦点指示器不可见——很多元素获得焦点时没有视觉反馈，用户不知道"我现在在哪里"；键盘陷阱——某些组件（如对话框）打开后无法通过键盘关闭，用户被困住。
修复焦点顺序需要正确的DOM顺序和tabindex属性管理。页面默认的Tab顺序由DOM顺序决定，因此需要确保DOM的结构顺序与视觉布局顺序一致。对于需要在特定情况下聚焦或跳过焦点的元素，使用正值的tabindex（但不推荐，容易混乱）。
焦点指示器的设计需要被看见但不过度刺眼。我们为所有可交互元素设计了2px宽度的蓝色焦点环，带有2px的外偏移（确保焦点环与元素之间有呼吸空间）。这个焦点环同时在明亮和暗黑模式下保持足够的对比度。
键盘陷阱的修复相对简单——确保所有可通过键盘打开的元素（对话框、下拉菜单、弹出面板）也可以通过Escape键关闭。在模态对话框打开时，焦点被锁定在对话框内，Tab键在对话框的元素间循环，不会跑到背景页面中。
颜色与感知：不止是看得见
颜色无障碍涉及两个核心问题：对比度（文字与背景之间）和颜色不作为唯一信息传达方式。
对比度问题在暗黑模式章节已经详细讨论过，但无障碍改造时我们又进行了第二轮全面审查。发现了28处对比度不达标的地方——主要集中在placeholder文字、禁用状态和提示信息上。修复方法是调整这些元素的颜色或背景。
"颜色不作为唯一信息传达方式"是一条容易被忽视但影响巨大的无障碍原则。v1.0中，成功状态用绿色文字表示，错误状态用红色文字表示，但没有任何图标或文字标签辅助说明。对于红绿色盲用户（约占男性人口的8%），这些状态完全无法识别。
修复策略是：所有的状态指示都同时使用颜色和图标（如对勾和叉号）或文字标签。成功不是"变绿"，而是"显示绿色对勾图标+成功文字"。错误不是"变红"，而是"显示红色感叹号图标+错误描述"。这样，即使用户无法区分颜色，仍然可以通过图标形状或文字内容理解状态。
CI/CD集成：让无障碍不再退化
完成无障碍改造只是第一步。真正的挑战是确保未来不会退化。每次新功能开发都可能引入新的无障碍问题。
我们在CI流水线中集成了自动化无障碍检查。每次Pull Request自动运行axe-core扫描新增或修改的页面和组件。检查规则聚焦于"自动化可检测"的无障碍问题——主要是缺失的alt文本、ARIA属性错误、对比度不达标、表单标签缺失等。任何新引入的Critical或Serious级别问题会阻断Pipeline。
自动化工具只能检测约30%-40%的无障碍问题。手动审计仍然需要——但频率降低为月度审查，重点检查新功能和页面。我们开发了一个无障碍检查清单，团队成员在进行代码审查时同步进行无障碍审查。
用户反馈同样是监测无障碍问题的重要渠道。我们在应用内添加了"报告无障碍问题"的入口，鼓励遇到障碍的用户直接反馈。这些问题会直接进入无障碍修复队列，优先级高于常规功能开发。
无障碍的商业和人文价值
无障碍改造是一项需要投入但回报多元的工作。
商业回报：完成WCAG 2.1 AA合规后，我们成功签约了那家欧洲企业客户（年合同额6万欧元），并与另外两家有严格供应商合规要求的企业进入了采购谈判。合规不是成本，而是打开某些市场的钥匙。欧洲市场的公共部门采购尤其如此——WCAG合规往往是准入条件。
产品回报：无障碍改造带来了"路边效应"——为特定群体做的优化，最终惠及了所有用户。键盘导航不仅帮助了肢体障碍用户，也成为了高效用户的偏好操作方式（快捷键比鼠标更快）。更高的颜色对比度不仅帮助了视障用户，也让所有用户在强光环境下更容易阅读。
人文价值：作为产品构建者，确保产品对所有人可及是我们的道德责任。技术的力量在于消除障碍，而不是制造新的。当一个使用屏幕阅读器的用户告诉我们"这是第一个我能独立完成工作的AI平台"时，我们知道这三个月的投入完全值得。
无障碍不是一次性的项目，而是持续的产品品质。WCAG 2.1 AA合规只是一个阶段的里程碑。下一个目标是不断提升——探索WCAG 2.2的新标准，优化AI语音交互的无障碍体验，思考如何让AI本身的输出更加无障碍。产品的可及性没有终点，就像产品的进化没有终点一样。