将无障碍视为运营能力，而非产品功能

一篇由 Level Access 赞助、发表于 Smashing Magazine 的署名文章提出：在 AI 加速 UI 生成的当下，「无障碍」不应被当作项目收尾时的一次性审计，而应与隐私、安全、可观测性并列，成为团队日常运营的基础能力。文章引用 WebAIM Million 年度扫描与 Veracode 2025 年 GenAI 代码安全报告中的具体数据，论证「快照式合规」正在失效。

审计模式的失效

过去很长一段时间里，团队处理无障碍问题的默认方式是「一次性审计」：聘请第三方机构、拿到一份包含上百条问题的报告、修掉其中一部分、归档了事。这种模式在销售、采购与合规问询场景下仍然必要——当买方索取 VPAT 或 ACR、法务要求确认达标情况时，审计文档不可或缺。

但审计并不能帮助团队在 Sprint 规划阶段就交付可访问的功能。它不会在合并请求之前发现缺陷，也无法跟上部署节奏。文章援引 WebAIM Million 2026 年的扫描结果：在对全球前 100 万个首页的检测中，95.9% 的页面存在可检测的 WCAG 失败，平均每页 56.1 处错误；页面元素数量在过去一年中增长超过 20%，背后推手被作者指向 AI 辅助开发与「氛围编程」（vibe coding）的普及。审计结束六个月后，产品已经历数十次发布、若干新功能与一次导航改版，那份报告自然成为「虚构文件」。文章认为，合规不是一次抵达的状态，而是需要持续维护的状态，而复杂度会不断与之对抗。

AI 生成 UI 的无障碍陷阱

文章将视角转向 AI 生成代码带来的结构性放大效应。2025 年 2 月，Andrej Karpathy 提出「氛围编程」一词——描述一种「完全跟随直觉、忘记代码本身存在」的工作方式。该说法最初面向周末项目，但很快溢出原始语境：Y Combinator 披露其 2025 年冬季批次中有 25% 的项目代码库 95% 由 AI 生成。

文章解释了模型为何系统性产出非语义化标记的三重原因：

• 训练数据偏差：GitHub 上大多数 React 代码本身就充斥着非语义化结构，模型自然照学。
• 反馈回路偏差：人类评审者以视觉效果判断输出，奖励的是「看起来对」，而非「语义上对」。
• 路径依赖：<div onClick> 比 <button aria-expanded="true"> 占用更少 token，缺少约束时模型倾向走廉价路径。

文章引用 Frontend Masters 的开发者测试：典型 AI 生成的侧边栏组件在 29 行代码中出现 10 处无障碍失败——缺少地标元素与标题层级、用 click 处理程序代替按钮、缺少 aria-expanded、无键盘事件处理、图标缺少标签等。无障碍树最终呈现为「扁平、无结构的纯文本」。作者比喻：「同样的像素，一个是门，另一个是门的画」。

与安全问题同源

文章把无障碍失败与生成式代码的安全问题并置讨论：Veracode 2025 年 GenAI 代码安全报告显示，AI 生成的代码中相当比例引入了安全漏洞（含 OWASP Top 10），跨站脚本尤为常见，且更新更大的模型并未带来明显改善。根因不在模型智能本身，而在流程——开发者在没有指定安全约束的情况下生成代码、又未做系统验证就接受输出。

文章由此推断：跳过安全审查的那条捷径，也正是跳过无障碍审查的捷径；规模化之后，AI 并不会弥合无障碍差距，反而会「工业化制造差距的源头」。

速度与无障碍并非对立

文章最后回应常见的反对意见：「加护栏会不会拖慢我们？」它引用 DevOps 的「左移」（Shift-Left）思路：设计评审阶段发现的无障碍问题只是一条评论，而生产环境发现的问题则是一项整改工程。在组件构建时发现的问题，修复仅需数分钟；审计中事后追溯、定位根因并重构，则要耗费数倍时间。文章在结尾处被截断，但主线主张已很清晰：约束 AI 并验证其输出，是把它当作「一个需要护栏的高速队友」来管理。

（注：原文在末段讨论具体工程实践部分被截断，本文仅整理至可读到的范围。）