无障碍是运营能力，不是功能清单

从一次“顺利”的交付说起

想象一个场景：资深工程师用AI助手一个下午“搞定”了结账流程，happy path跑得顺畅，订单摘要上的旋转箭头动画也很炫酷。但两周后，客服转来投诉——一位视障用户用屏幕阅读器无法完成支付，因为“立即支付”按钮是个带点击事件的<div>，没有角色（role）、不可聚焦、完全不工作。

这个案例揭示了一个正在成为AI时代核心工程挑战的问题：代码能跑，不等于产品可用。当团队用AI生成UI的速度越来越快，如何保证交付的东西真正可用、安全、可维护？无障碍（Accessibility）恰好处于这个问题的中心。

审计陷阱：为什么一次性检查不够

过去，做无障碍的默认方式是“审计一次”：请外部公司扫描，拿到200条问题清单，修复一部分，归档报告。这种模式在销售、采购、法务场景下确实必要——比如客户要VPAT或ACR文档，或者法务需要合规证明。

但审计无法帮助你在冲刺规划中构建无障碍功能。它不检查合并请求前的问题，也跟不上部署速度。关键误区在于：把无障碍当成快照，而它需要的是持续监控。 审计后六个月，产品可能已经发布了十几个版本、新增多个功能、重设计了导航——那份报告早就过时了。合规不是一个到达的状态，而是一个需要维护的状态。

WebAIM Million报告（每年扫描前一百万个主页）显示，2026年有95.9%的页面存在可检测的WCAG失败，平均每页56.1个错误。页面元素数量一年内增长了20%以上，这很可能与AI辅助开发和“vibe coding”有关——元素越多，出错的点就越多。无障碍债务和代码债务一样：每交付一个不可访问的组件，未来都要花更多成本去修复，利息不断累积。

AI时代的放大器

2025年2月，Andrej Karpathy提出了“vibe coding”概念——一种完全“跟着感觉走”的开发方式，开发者描述意图，AI生成代码，然后直接接受差异而不细看。这种方式原本是给个人开发者用的，但现在团队也在用。结果是：UI生成速度暴涨，但无障碍问题不是消失了，而是成倍增加。

问题在于，AI模型训练数据中，可访问的代码样本本来就少。模型擅长生成视觉上美观的界面，但往往忽略键盘导航、ARIA标签、焦点管理这些细节。当团队依赖AI生成UI，又没有把无障碍嵌入流程，问题就会在规模上爆发。

把无障碍变成运营能力

要解决这个问题，需要把无障碍从“功能”或“清单”提升为运营能力——就像安全、隐私、可靠性、可观测性一样，是系统持续具备的属性。具体怎么做？

1. 在开发流程中内置检查

• 代码审查阶段：把无障碍检查加入CI/CD流水线，用自动化工具（如axe、Lighthouse）扫描每次提交，阻止明显问题合并。
• 组件库层面：确保每个UI组件默认带有正确的ARIA角色、键盘支持、焦点管理，而不是让开发者每次手动添加。

2. 建立持续监控机制

• 定期扫描：生产环境部署后，用工具定期扫描关键页面，跟踪错误数量变化。
• 真实用户测试：定期邀请残障用户参与可用性测试，特别是屏幕阅读器用户和键盘用户。自动化工具只能发现约30%的问题，其余需要人工判断。

3. 教育团队，而非依赖少数专家

• 培训开发者：让每个工程师理解基本无障碍原则，比如语义HTML、对比度、焦点顺序。
• 设置“无障碍大使”：在每个团队中指定一人负责无障碍知识传播和问题咨询。

4. 把无障碍纳入定义完成（Definition of Done）

• 每个用户故事或任务在“完成”前，必须通过无障碍检查——就像必须通过单元测试一样。

对谁有用？

• 开发者：减少后期返工，避免因无障碍问题导致的产品延期或法律风险。
• 产品经理：把无障碍纳入规划，而不是事后补救，提升产品整体质量。
• 企业决策者：理解无障碍是运营成本的一部分，而非一次性支出，有助于长期降低风险。

结语

无障碍不是功能列表上的勾选项，而是像安全一样的系统属性。在AI生成代码成为常态的今天，团队需要主动把无障碍嵌入工程文化、流程和工具链。否则，代码生成得越快，缺陷积累得越多。真正的工程能力，是让系统在持续变化中依然可用——对所有人。