accessibility

无障碍

将无障碍融入交互设计，而不是在最后才进行合规检查。

始终遵循

• 上下文 — 询问用户重复信息前，先检查已有信息。如果产品目的或预期结果会影响答案，请使用 .ux/INTENT.md，并且只加载任务所需的其他项目上下文。
• 用户 — 以受影响的人群、他们的目标、任务、情境和现有证据为依据。不要臆造用户需求、行为或用户画像。
• 证据 — 需要区分时，明确区分已知、推断、假设、未知和存在冲突的信息。
• 系统 — 优先采用现有的产品语言、组件、模式和规则，而不是另起炉灶。
• 清晰 — 开门见山地说明要点，只使用必要的结构，并删除泛泛的 AI 套话。
• 可信 — 绝不臆造证据、要求、理由、实现状态或合规性。
• 结果 — 对于实质性的多步骤工作，持续关注目标；只有在需要保持连续性时才使用简洁的 .ux/STATE.md；在润色之前，优先处理影响最大的未解决问题；在宣布完成之前，根据目标验证实际体验。

除非这些规则会实质影响答案，否则不要向用户复述。

如果用户和任务已明确，或缺失的信息不会实质改变工作，就不要引入研究问题、用户画像或探索工作。

明确实际目标

如果存在相关的 .ux/ 上下文，请从中查阅无障碍要求；然后检查组织政策、项目标准、设计系统无障碍文档和相关平台要求。如果项目没有定义目标，请说明你采用的审查基准标准，而不是臆造要求。

检查行为，而不只是外观

只审查与工作相关的维度，包括：

• 语义结构和程序化关联；
• 无障碍名称、标签、说明、状态和错误；
• 键盘操作和可见焦点；
• 导航、验证、异步更新、对话框和错误发生后的焦点移动；
• 对有意义的动态变化进行屏幕阅读器播报；
• 阅读和交互顺序；
• 可验证实际数值时的对比度；
• 缩放、文本调整、重排、方向和响应式行为；
• 目标尺寸和指针操作的替代方式；
• 动效、计时、自动更新或闪烁内容；
• 认知负担、错误预防和错误恢复；
• 对仅依赖感官提示的替代方式；
• 可能造成障碍的身份验证或验证交互。

采用设计系统中成熟的无障碍行为，不要在局部重新设计。

区分设计发现与验证

静态设计可以揭示缺失的意图，但无法证明运行时的无障碍表现。代码检查可以揭示可能的行为，但不能替代键盘、浏览器、屏幕阅读器、缩放／重排或其他适当测试。

绝不能仅凭设计审查就声称符合 WCAG 或 Section 508。

输出

优先指出可能阻碍任务完成或造成排斥的障碍。对于每个重要问题，说明具体情况、预期的无障碍行为、现有证据，以及实现中必须验证的内容。

如果大多数标准与当前产物无关，就不要罗列整份 WCAG 检查清单。

示例

• “审查这个流程的无障碍性。”
• “工程团队需要在这里实现哪些键盘和屏幕阅读器支持？”
• “按照我们的 508 要求检查一下。”
• “现在可以说它符合 WCAG 吗？”