Web无障碍设计规范

要解决的工程问题

在 AI 驱动的开发流程中，人工测试环节往往被压缩，无障碍（a11y）问题很容易从立项时就埋下。常见情况包括：团队直到后期才补做 WCAG 合规，结果发现改造成本远高于从一开始就纳入设计；现有代码里充斥着 <div onclick>、跳级标题、低对比度配色这类反模式；自定义组件缺少键盘支持，屏幕阅读器用户完全无法操作。

技能如何工作

这套规范把无障碍拆解为几个可执行的工程动作：

• 语义化 HTML 优先：优先使用 <button>、<fieldset>、正确的标题层级等原生元素。这些自带键盘行为和 ARIA 语义，远比手写组件可靠。
• 键盘交互模型：确保所有交互元素可通过 Tab、Enter、Space、方向键操作。仅在自定义可聚焦元素上使用负值 tabindex，且必须在脚本中处理对应按键事件。
• ARIA 仅作兜底：只有在原生元素确实无法实现时才引入 ARIA，并且必须记录选择理由和预期用户流程，标注对应的 WCAG 2.2 条款。
• 持续校验机制：每次新增媒体必须提供 alt 文本（装饰性图片用 alt=""）；所有新配色需按公式 (L1 + 0.05) / (L2 + 0.05) 计算对比度，正文至少 4.5:1；利用 eslint-plugin-jsX-a11y 或 Pa11y 做自动化回归。
• 可访问性注释：在代码中用注释说明某段实现对应的 WCAG 条款和预期用户操作路径，方便后续维护者理解上下文。

适用边界与注意点

需要明确：这套规范不覆盖 WCAG 全部细节。遇到不确定的情况，应查阅 W3C/WCAG/WAI-ARIA 官方文档，而不是凭经验猜测。

人类测试仍然是不可替代的环节，设计团队需要持续评估真实用户流程。如果某个需求提示词可能引入无障碍缺陷（例如强制使用非语义化标签），技能会先告知风险并征求确认，而不是盲目执行。

此外，不要在 UI 文案中提及"无障碍"功能——这是反模式。真正的可达性是看不见的，它体现在每一处键盘导航、每一段 alt 文本和每一次对比度检查里。