北京
无障碍审计的价值毋庸置疑。它能发现那些平时容易被忽略的问题，给团队一个结构化的视角，看清产品在无障碍方面的全貌，也给出一个具体的整改起点。
但审计报告只是起点，不是修复计划。
一个常见的误区是：把审计发现当成任务本身——逐条过清单，关掉每个问题，然后发布。但一条审计发现告诉你的是“渲染出来的体验哪里出了问题”，它并不一定告诉你“为什么会出问题”“该在哪里修”以及“怎么防止它再次发生”。
这正是无障碍修复成为软件工程的地方。
一条发现是症状，不是位置
审计告诉你输出哪里不对，但它不告诉你系统里该修哪里。
如果同一个故障出现在十个页面上，修十个页面可能只是处理了报告里列出的实例，并没有处理根因。更值得问的问题是：这个故障是在哪里被产生的。
可能是一个共享组件，一个模板，一个设计系统的基础元素，也可能是内容本身，或者某个第三方脚本。
正确的修复往往改变的是结构，而不只是一个属性。
问题不在于逐条处理审计发现——这往往是必要的。问题在于把每一条发现当成一个孤立任务，而不去追问它是由什么产生的，以及这个修复能不能站得住。
只修输出，故障可能在下次生成输出时再次出现。修那个生成输出的东西，修复才有更大机会在下次变更中存活下来。
修复同样会积累技术债
总是存在更快的路径。一行在渲染后重写 DOM 的 JavaScript，一个一次性的 ARIA 补丁，一个复制出来的“这次是无障碍的”组件变体。
每一条都能关掉一个审计发现。每一条也可能让代码库变得更糟：一个无限期维护服务端渲染标记的脚本，冲突的 ARIA，或者一个在底层标记变化时就失效的修复。
这些做法并不总是错的。在某些系统约束下，它们可能就是正确的解决方案。
但它们应该是经过深思熟虑的工程决策。
一次修复应该让代码处于更好的状态，而不是把问题挪到一个更难被发现的地方。
回归本身就是问题的一部分
只作用于输出的修复，在输出被重新生成时很容易回归。在新上下文中复用组件，复制模板，拉取上游更新，或者一个新开发者照着现有模式复制却不知道它是坏的。
构建在系统里的修复则更有韧性。当正确性被构建进组件、模板、设计系统或开发流程时，每次使用同一个模式就不需要重新做决定。
这就是修复一个实例和修复产生它的系统之间的区别。
一个撑不过下次变更的修复，从来就不是真正的修复。
这是工程，不是另一条轨道
我不把无障碍修复看作独立于软件工程之外的事情。
这个要求来自 Web 本身——当无障碍被当作一个独立的、事后的检查清单来处理时，它就成了一个永远在追赶的负担。但当它被当作工程实践的一部分，当作系统设计的一个维度，修复就不再是打勾，而是构建。
审计报告的价值在于它指出了问题所在。但真正让产品变得无障碍的，是那些把修复当作工程问题来对待的团队——他们追问根因，把正确性构建进系统，让修复能够撑过下一次变更。
这才是无障碍修复的本质：不是清单，是工程。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
