handoff

无障碍决策交接

将无障碍决策整理成清晰的规范，供工程师据此实现——因为“让它具备无障碍性”并不是一份规范。

流程

第 1 步：汇总决策

使用 decision-documentation，收集该功能的所有无障碍决策：

• 交互模式和键盘行为
• 屏幕阅读器播报和 ARIA 要求
• 视觉规范（对比度、颜色独立性、动画）
• 内容要求（阅读难度、替代文本、链接文本）
• 自适应行为（偏好、缩放、密度）

第 2 步：映射到实现

使用 compliance-mapping，将每项设计决策转换为具体的实现要求：

对于每个交互元素，指定：

• HTML 元素或 ARIA 角色
• 键盘行为（哪些按键执行什么操作）
• 焦点管理（操作后焦点移到哪里）
• 屏幕阅读器播报的名称、角色和状态
• 视觉状态（默认、悬停、焦点、激活、禁用、错误）

对于每个内容元素，指定：

• 标题级别
• 替代文本（确切文本或撰写策略）
• 链接文本
• 多语言场景下的语言属性

对于每种自适应行为，指定：

• 媒体查询和预期响应
• 检测到的偏好及其引发的变化
• 断点和重排行为

第 3 步：定义测试标准

使用 accessibility-testing-strategy，为每项要求提供具体测试用例：

• 键盘测试：“按 Tab 键移至提交按钮，按 Enter 键，验证焦点是否移至确认消息”
• 屏幕阅读器测试：“定位到错误信息，验证其是否播报：‘错误：电子邮件地址为必填项’”
• 视觉测试：“验证正文文本在浅色和深色模式下的对比度至少为 4.5:1”
• 缩放测试：“在 200% 缩放时，验证表单是否重排为单列且没有水平滚动条”

第 4 步：标记风险和依赖项

注明工程师需要留意的事项：

• 需要自定义键盘处理的组件
• 框架默认行为不符合无障碍要求的地方
• 可能需要封装或替换的第三方组件
• 自动化测试无法发现问题的领域

输出

交付一份交接文档，包含：

1. 无障碍规范 — 逐项列出元素要求，包括 HTML、ARIA、键盘和视觉规范
2. 测试用例 — 针对键盘、屏幕阅读器、视觉和缩放测试的具体、可执行场景
3. WCAG 映射 — 每项要求对应的成功标准
4. 风险登记表 — 已知挑战和建议的处理方式
5. 完成定义 — 功能发布前必须通过的具体无障碍标准