查看英文原文

中文编辑版。法规要求因地区与时间变化，实际合规应核对所在地最新规则。

无障碍不是开发结束后的检查项目，而是服务从发现到上线都必须持续处理的质量属性。人的使用能力会受到环境、健康、设备与网络影响，因此无障碍设计不仅服务长期残障用户，也能改善所有人在不同情境下的体验。

先把无障碍变成团队责任

开发、内容、交互、研究、产品与交付人员都可能引入或消除障碍。把责任交给单一“无障碍专家”，通常会让问题在流程后期集中爆发，修复成本更高。

团队应在预算中预留培训、残障参与者招募、辅助技术、测试和审计成本，并把无障碍标准写进完成定义。

发现阶段：理解障碍

研究视觉、听觉、运动和认知障碍用户如何完成目标，识别他们可能遇到的环境与流程问题。即使尚未开始招募，也可以通过障碍用户画像、能力范围和辅助技术资料建立基础认知。

Alpha 阶段：让方案接受现实检验

原型阶段就应对照 WCAG 原则，并邀请残障用户参与研究。尽早让审计人员检查关键流程，可以在视觉系统和技术架构固化前发现问题。

Beta 阶段：组合测试与正式审计

自动检测只能覆盖部分问题。团队需要组合键盘测试、屏幕阅读器、放大、语音输入、人工代码检查和真实用户研究。正式审计应提供证据，并为公开无障碍声明准备问题清单和修复计划。

上线后：持续维护

新功能、内容更新与第三方集成都可能破坏原有无障碍。上线不是终点；团队应持续测试，在重大变更后重新审计，并让无障碍声明反映真实状态。

一份可执行检查表

• 明确当前适用的标准与法规。

• 在每轮研究中纳入残障用户。

• 关键流程必须能用键盘和常见辅助技术完成。

• 把发现的问题进入正常产品待办，而不是单独搁置。

• 公开已知问题、替代方案和修复计划。

结论

成熟的无障碍实践不是一次通过审计，而是让每个角色、每个阶段都拥有发现和移除障碍的能力。