accessibility

可访问性 skill 概览

可访问性 skill 能做什么

可访问性 skill 帮助你围绕 WCAG 2.2 Level AA 设计、实现并审计可访问的 UI。它的目标是把产品意图转化为具体的语义选择：原生元素、ARIA role、label、提示信息、焦点行为，以及 Web、iOS 和 Android 上的平台级可访问性特征。

谁应该安装这个可访问性 skill

这个可访问性 skill 最适合前端工程师、设计系统团队、UX 审核人员和产品设计师。它提供的是可直接落地的实现指导，而不是泛泛的可访问性检查清单。尤其是在做 UX Audit 相关的可访问性工作时，它很有用：能帮助你从“这个流程看起来有风险”推进到具体的修复方案。

它帮你完成的工作

真正要完成的任务，不只是“让它合规”。更重要的是把某个组件或流程正确映射到 accessibility tree，这样辅助技术用户才能得到正确的 role、name、state、顺序和交互模型。这个 skill 强调语义映射、焦点管理、命名，以及 POUR 原则，而不是宽泛的政策式总结。

为什么选它而不是普通 prompt

普通 prompt 往往只会给出比较空泛的可访问性建议。这个 skill 更适合你需要结构化推理的时候，比如：先识别组件 role，再优先使用原生语义，然后定义 label、state、键盘行为和焦点处理。这样更适合用于实现评审和审计，建议也更可执行。

如何使用 accessibility skill

安装后先看什么

先通过你的 skills 工作流安装这个 skill，然后优先打开 skills/accessibility/SKILL.md。这个 skill 没有额外脚本或参考文件，所以几乎所有有价值的指导都集中在这一份文档里。建议按这个顺序阅读：

1. When to Use
2. Core Concepts
3. How It Works
4. 关于识别组件 role 的那一部分

这是一个很轻量的可访问性安装：配置成本低，但你需要自己补充缺失的产品上下文。

这个可访问性 skill 需要哪些输入

这个可访问性 skill 在以下信息充分时效果最好：

• platform：Web、iOS 或 Android
• component or flow：button、modal、form、tabs、menu、carousel 等
• user goal：用户想完成什么
• current implementation：HTML、JSX、SwiftUI/UIKit、Jetpack Compose/View XML，或截图加行为说明
• constraints：设计系统限制、旧标记、第三方 widget
• audit target：WCAG 2.2 AA、键盘支持、屏幕阅读器行为、焦点顺序、目标尺寸，或命名/state 问题

弱输入：Make this accessible.
强输入：Audit this React modal for WCAG 2.2 AA. Check semantic role, accessible name, focus trap, escape behavior, initial focus, return focus, and screen reader announcement. Suggest corrected JSX.

把模糊目标改写成强 prompt

为了更好地使用 accessibility skill，可以用下面这种 prompt 结构：

• 先识别 UI role，以及当前实现是否应该被原生元素替换。
• 描述预期的 accessibility tree。
• 列出必要的 label、role、state、value 和 hint 信息。
• 定义键盘和焦点行为。
• 标出 WCAG 2.2 AA 风险。
• 返回修正后的代码，并附上一段简短的审计摘要。

示例：
“Use the accessibility skill to review this custom dropdown on Web. First decide whether it should be a native select, button + listbox, or another pattern. Then provide the expected ARIA, keyboard interactions, focus movement, visible focus requirements, target size concerns, and revised code.”

用于审计和实现的推荐工作流

如果你是在做 UX Audit 相关的可访问性工作，建议先从流程层面开始，再下钻到组件：

1. 说明任务和失败风险
2. 识别每个交互元素的真实 role
3. 先检查是否有原生语义替代方案
4. 验证 label、name、value 和 state
5. 审查键盘顺序和焦点可见性
6. 在概念层面测试屏幕阅读器播报
7. 索取修复后的代码或规格说明

如果你是在做实现而不是审计，不要只要一段说明文字；要让 skill 产出可以直接交给工程和 QA 的验收标准。

accessibility skill 常见问题

这个 accessibility skill 适合新手吗？

适合，但前提是你已经懂一些基础 UI 开发。这个 skill 会把核心可访问性概念讲清楚，但它不是完整的 WCAG 入门课程。把它当作实现辅助工具，会比当作唯一学习资源更合适。

它足够作为是否安装的判断依据吗？

大体上可以。这个 skill 的范围清晰、工作流具体，而且技术导向很明确。主要限制在于内容包装深度：没有配套示例、测试脚本或平台专属参考文件。如果你想要大量可复用素材，它会显得比较精简；如果你要的是快速指导，它很容易上手。

它和通用可访问性 prompt 有什么不同？

区别在于 framing。这个 accessibility 指南聚焦 role 识别、语义映射、accessibility tree 思维、label 和焦点管理。通用 prompt 往往会直接跳到 ARIA 属性，容易导致过度工程化或选错模式。

什么时候不该用这个 skill？

不要只依赖这个 accessibility skill 来做法律层面的最终确认、复杂辅助技术兼容性测试，或高度专门化的原生平台边缘案例处理。它最强的地方在于设计和代码推理，而不是替代真实设备、屏幕阅读器和纯键盘流程上的人工测试。

如何改进 accessibility skill

提供更完整的 UI 上下文，而不只是代码片段

影响效果最大的因素是上下文。要把用户任务、控件是改变状态还是导航、界面上实际显示什么、目前哪里出错都写清楚。可访问性建议依赖的是行为，而不只是标记。一个 div 可以对应好几种模式；如果你定义了预期交互，这个 skill 的输出会更准确。

先要求选择模式，再要求 ARIA

常见失误是把 ARIA 强行套到错误的组件上。想让 accessibility 输出更好，可以先问：“这到底是哪种 pattern？” 比如，在修复前先要求在原生 button、link、disclosure、tab、dialog 或 listbox 之间做判断。这样通常能避免不必要的自定义 widget。

要求按可直接落地的结构输出

如果想更好地使用 accessibility skill，可以要求它按下面的结构回答：

• 发现的问题
• 对用户的影响
• WCAG 2.2 相关风险
• 推荐的语义模式
• 具体代码修改
• 测试步骤

这种格式比单篇长文更适合交接给工程、QA 或 design system owner。

用真实失败证据做迭代

第一次输出后，把更具体的信息反馈回去，能显著提升 accessibility skill 的效果：比如屏幕阅读器播报内容、键盘陷阱、缺失的可见焦点，或触控目标尺寸。把它当作 UX audit 发现的迭代循环，而不是一次性的合规检查，它会更有价值。