Web无障碍质量守护

为什么需要无障碍优先的开发策略

在 AI 驱动的前端开发流程中，人工测试往往被压缩到最低限度。当一个项目需要在自动化生成代码与快速迭代之间寻找平衡时，无障碍问题很容易被推迟到“以后再说”。但现实是，事后修复的成本远高于从头做好。一个按钮缺少键盘支持、一张图片没有 alt 文本、一段文字对比度不足——这些问题在开发阶段可能只需要几分钟就能解决，等到上线后再处理却可能需要重写组件结构。

这套规范针对的就是这类反复出现的低级错误，把无障碍要求前置到代码编写阶段，而不是留给 QA 阶段去发现。

这套规范如何落地

语义化优先，ARIA 作为补充

• 用真实的 <button> 元素做按钮，而不是用 <div onclick>
• 表单使用 <label> 和 <input> 的原生关联，而不是事后补 aria-label
• 标题层级保持逻辑递进（h1 → h2 → h3），不跳级
• ARIA 只在没有原生替代方案时使用，且必须记录原因

键盘可访问性是强制项

所有交互元素必须支持 Tab、Enter、Space 和方向键操作。焦点指示器不能被 outline: none 抹掉，需要保留或自定义。触摸目标尺寸满足 WCAG 要求，确保每个用户都能用。

对比度与非文本内容有明确公式

• 普通文本对比度不低于 4.5:1
• 大文本（≥18pt 或粗体 ≥14pt）不低于 3:1
• 图片必须提供描述性 alt 文本，装饰性图片用 alt=""
• 数据表格使用 <th> 和 scope 属性
• 避免“点击这里”“继续阅读”这类无意义链接文本

文档化与持续检查

为无障碍实现添加代码注释，引用具体的 WCAG 2.2 条款编号。每次新增图片时检查 alt 文本，每次新增颜色时验证对比度。使用 Pa11y 等工具集成自动化测试，同时定期用屏幕阅读器（NVDA/VoiceOver）做手动测试。

适用边界与注意点

这套规范适用于面向公众的 Web 应用，尤其是需要满足 WCAG 2.2 AA 或更高等级的项目。它不替代专业的无障碍审计，但可以作为代码审查阶段的基础检查清单。

注意：AI 辅助生成的组件需要手动确认焦点管理和屏幕阅读器通知是否完整。prefers-reduced-motion 媒体查询不能只在设计稿里出现，必须在代码中真正生效。表单错误提示不能只靠颜色传达，还需要文字说明。