可访问性是运营能力，而非功能特性
本文由我们的挚友 Level Access 友情支持，该公司致力于帮助各类机构打造兼具可访问性与合规性的网站、移动应用、软件及其他数字体验。致谢！
此刻，或许正有一位资深工程师在发布一套"一下午就搭好"的结账流程：AI助手包办了繁重工作，常规流程测试顺畅，订单摘要页的旋转箭头也正常显示。可两周后，工程部收到客服通知：一位使用屏幕阅读器的视障用户无法完成支付——原因是"立即支付"控件只是个绑定了点击事件的<div>标签，既无语义角色，也无法获取焦点，完全无法被辅助设备识别。
这种"能运行的代码"与"真正可用的产品"之间的鸿沟，正成为AI时代软件工程的核心挑战之一。如今团队生成UI的速度前所未有，但仍需确保交付的产品可用、安全且易于维护。
而可访问性，恰恰是这一难题的核心。
本文不谈合规 checklist，也不聊项目尾声的审计工作，我们聚焦的是工程体系——具体来说，为何应将可访问性视为一项运营能力，与隐私、安全、可靠性、可观测性并列，以及在实践中如何落地。
审计陷阱
多年来，"做"可访问性的默认模式是一次性审计：聘请第三方机构，拿到一份列有200项问题的报告，修复其中一部分，然后将报告归档。如今许多团队已摒弃这种模式，背后的原因值得深究。
审计并非毫无价值。对于销售、采购和治理环节，它必不可少：当客户索要 VPAT（Voluntary Product Accessibility Template，自愿产品可访问性模板）或ACR（Accessibility Conformance Report，可访问性合规报告），你得拿得出来；当法务询问是否符合合规要求，你需要有文档支撑。审计能很好地满足这些需求。
但审计无法在 sprint 规划阶段帮你打造可访问的功能，反而可能占用 sprint 资源；它无法在代码合并前发现问题，也无法跟上部署节奏。本质上，错误在于把可访问性当成了"快照式"任务，而实际上我们需要的是持续监控。审计完成六个月后，产品可能已经发布了数十个版本、新增了多项功能，甚至重构了导航栏，当初的报告早已过时。合规不是一个可以"达成"的状态，而是需要持续维护的过程，而产品复杂度会始终成为阻碍。
每年扫描百万级首页的 WebAIM Million报告 显示，2026年的检测结果中，95.9%的页面存在可被识别的WCAG（Web Content Accessibility Guidelines，网页内容可访问性指南）合规问题，平均每个页面有56.1处错误。单年内页面元素数量增长超20%，这很可能是AI辅助开发和"氛围编码"导致的——元素越多，出问题的概率就越高。可访问性债务与技术债务如出一辙：每交付一个不可访问的组件，未来就多一项整改任务，且"利息"会不断累积。
任何将可访问性视为周期性事件，而非系统持续属性的策略，最终都会失效。
无人愿提及的AI难题
随着团队生成UI的规模扩大，上述鸿沟不仅没有缩小，反而在成倍扩大。
先看变化来得有多快。2025年2月，Andrej Karpathy提出了"氛围编码"的概念——一种"完全跟着感觉走""忘记代码本身"的工作方式：你描述需求，模型生成代码，你直接接受改动，甚至不看具体内容。这种方式原本只适用于周末小项目，却很快普及开来。Y Combinator的报告显示，其2025冬季孵化项目中，25%的代码库95%由AI生成。
AI生成非语义化标记并非偶然，背后有三重驱动因素：GitHub上的大部分React代码都充斥着非语义化的"标签杂烩"，模型学习的正是这类内容；人类评审者通常以视觉效果评判输出，反馈机制更看重外观而非语义；而且<div onClick>比<button aria-expanded="true" ...>占用的token更少，在没有约束的情况下，模型会选择更"廉价"的路径。
关于AI生成UI，有一个关键事实：它默认就是不可访问的，不是偶尔如此，而是从一开始就存在问题。一位Frontend Masters的开发者测试了多款工具生成的React组件，并记录下普遍问题：一段仅29行的AI生成侧边栏代码，竟存在10处不同的可访问性缺陷——无地标、无标题、无列表结构、用绑定点击事件的元素替代按钮、无aria-expanded属性、无键盘交互支持、图标未标注等。屏幕阅读器实际读取的可访问性树，最终变成了扁平无结构的文本。正如这位开发者所说："视觉上看起来一模一样，但一个是能打开的门，另一个只是画出来的门。"
再将其与安全问题联系起来，两者根源相同。Veracode的《2025生成式AI代码安全报告》测试了多款大语言模型在数十项编码任务中的表现，发现大部分AI生成代码存在安全漏洞，包括OWASP十大风险，其中跨站脚本攻击尤为常见，且更新、更大的模型并未显著提升安全性能。问题不在于模型的智能程度，而在于流程：开发者生成代码时未明确安全约束，也未对输出进行系统性验证就直接采用。
跳过安全审查的捷径，同样会跳过可访问性审查。从规模上看，AI不仅不会缩小可访问性鸿沟，反而将导致鸿沟扩大的行为工业化了。
解决办法不是禁用AI——你的开发者早已在使用它。正确的做法是为AI设置约束并验证输出，将其视为一位速度极快但始终需要护栏的队友。
交付速度与可访问性并非对立
这时可能有人会说："护栏？听起来不错，但会拖慢我们的速度。"
但实际情况往往相反。
DevOps的核心思想左移，在这里同样适用：在设计评审阶段发现可访问性问题，只需一句评论就能解决；而在生产环境中发现问题，则需要启动一整套整改项目。
在组件开发阶段发现可访问性问题，只需几分钟就能修复；而事后整改——从审计中发现问题、诊断根源、重构标记、实施修复到编写测试——往往需要数小时。如果是后期审计发现的数百个问题，那意味着数周的计划外工作，而这些本可以通过早期的自动化检查（无论是设计评审、开发流程还是CI环节）避免。
将可访问性融入日常工作流的团队，能避免诸多昂贵的意外：紧急审计、整改冲刺、采购受阻，以及悄悄破坏核心用户流程的重构。拖慢交付速度的不是可访问性，而是计划外工作。将可访问性嵌入流程，正是消除计划外工作的方式之一。
企业级落地的正确姿势
成功规模化可访问性的企业，不依赖"英雄式"个人，而是依赖体系。
最高效的切入点是设计系统：一个可访问的组件可以被复用数千次。GOV.UK设计系统就是很好的例子：其组件会通过JAWS、NVDA、VoiceOver、TalkBack等辅助技术，接受自动化与人工双重测试。团队明确自动化工具的局限性，会补充开展面向残障用户的测试；同时也清楚，使用设计系统不会"魔法般"让服务变得可访问，只是提供了一个更高的起点。
关键在于：让可访问性成为基础设施。
在此基础上，将可访问性融入工程工作流：
- 可访问性要求纳入"完成定义"（Definition of Done）；
- 代码合并请求（Pull Request）评审包含明确的可访问性检查；
- 交互控件默认使用语义化元素（
<button>、<a>）； - 键盘导航与焦点管理被视为标准工程需求，而非可选的优化项。
最后，通过自动化确保可访问性落地：
- eslint-plugin-jsx-a11y在代码提交前捕获常见问题；
- LevelCI、Pa11y等工具在CI/CD流水线中提供自动化测试；
- @storybook/addon-a11y在组件开发阶段暴露问题。
到这时，可访问性不再依赖个人记忆，而是依托流程运转，成为平台的一部分。
可规模化的实践模式
在这方面做得好的团队，往往会遵循以下几种实践模式。
提前约束AI生成规则
不要在生成后再修复可访问性问题，而是通过Cursor规则、Copilot指令或仓库级标准，将要求直接融入工具。明确告诉模型要使用语义化HTML，何时用按钮、何时用链接，以及如何正确暴露状态和标签。相比一次性提示，模型遵循持久化约束的可靠性要高得多。
停止自行开发复杂组件
组合框、菜单、标签页、模态框等控件，往往是可访问性问题的重灾区。Radix UI、React Aria、Headless UI等库已经解决了这些问题。规模化的做法不是反复从零开始实现可访问性，而是从经过充分测试的基础组件中继承可访问行为。
设计交付阶段明确可访问性要求
焦点顺序、标签、标题层级、交互状态等，应在开发开始前就明确。如果设计文档中缺少可访问性要求，最终产品往往也会缺失这些内容。在设计交付时附上一份简单说明——比如标签顺序是什么、各元素标签是什么、错误状态下如何处理——能大幅减少后续开发中的猜测。
这些模式都不复杂，只是将DevOps和平台思维应用到了可访问性领域。
更广泛的业务影响
工程领导者很少仅仅因为法规要求而优先考虑可访问性，但法规、采购需求、用户留存和产品质量都指向同一个方向。
法律压力持续增大。美国的数字可访问性诉讼每年仍有数千起，且并非只针对大型企业。《欧洲可访问性法案》已在欧盟全境生效，适用于电子商务、银行、票务、电信等多个领域，无论企业总部位于何处。信号很明确：在监管机构眼中，可访问性不再是"锦上添花"的选项。
但合规只是一部分，更大的影响是错失市场。世界经济论坛（2023年12月）估计，全球13亿残障人士"及其亲友"的消费能力达13万亿美元；据Valuable 500数据，仅残障消费者每年的可支配收入就约为8万亿美元。
仅在英国，《2019年点击流失英镑报告》显示，"点击流失金额"已升至171亿英镑——超490万有访问需求的用户因网站不可访问而转向其他平台消费，较2016年的117.5亿英镑增长了近45%。这些用户不会提交bug报告，只会直接离开，转而购买竞争对手的产品。
此外，采购端的现实也让可访问性从成本变成了竞争壁垒。如果你的业务是B2B或面向政府客户，对方会越来越多地要求提供可访问性证明——VPAT/ACR或同等文档。根据Level Access《第七年度数字可访问性现状报告》，75%的组织在采购数字产品时，至少大部分情况下会要求提供可访问性证明，这一比例与上一年的74%基本持平，但严格执行的比例从27%升至31%，明显提升一份完善的ACR能加快销售周期；反之，薄弱的证明或完全没有证明，则会形成阻碍，导致销售停滞甚至失败。对一些买家而言，这是产品进入评估阶段的硬性要求。
退一步看，更深层的逻辑很清晰：可访问性是工程成熟度的体现。一个能交付语义化HTML、管理焦点、正确暴露状态，并在CI中测试的团队，必然是一个管理有序的团队。打造可访问组件的纪律性，同样能带来可维护、可测试、bug更少的产品。
对于开发和产品领导者而言，这才是真正的商业价值：可访问性工作属于平台建设范畴，能让每次功能发布都更快、更顺畅，减少返工。
依赖体系，而非冲刺
如果本文只能让你记住一件事，那请记住：可访问性不是来自审计、英雄式个人，也不是来自上线前的突击整改冲刺，而是来自体系。
一套可访问的设计系统，让组件从一开始就走在正确的路上；一份明确的"完成定义"，确保组件始终符合要求；自动化测试和CI关卡，让回归问题无法通过构建；明确的治理机制，确保有人负责；AI辅助开发的护栏，让你最快的工具不再成为最大的隐患。
这些实践都不耀眼，但正因如此才有效——它们和你已经依赖的、用于保障安全、可靠性和性能的那些单调但可靠的体系，本质是一样的。
不过，有一件事是任何工具都做不到的：无论代码检查工具、自动化扫描器还是仪表盘，都无法告诉你，视障用户使用屏幕阅读器时、因手抖无法使用鼠标只能靠键盘导航结账时，你的产品实际体验如何。所以，要搭建体系——你需要它们，这是可访问性能在真实发布节奏中持续落地的唯一途径。但同时也要定期邀请真实的残障用户测试。当你第一次坐在旁边，看着用户用JAWS艰难地填写你们团队认为"已经完成"的表单时，一切都会改变。工具能告诉你是否通过了检查，但只有真实用户能告诉你产品是否真正可用。
可访问性不是一项功能，而是一项运营能力。只有这样看待它，你才能获得开发和产品领导者真正关心的东西：一种更快、更安全、更可靠的软件交付方式。
(il, yk)
(il, yk)