可访问性合规：把 WCAG 2.2 无障碍规范落地成可复用的工程模式
- 定位清晰：这是一个专注于无障碍（Accessibility / a11y）实现的 AI 技能，目标是把 WCAG 2.2、ARIA 模式、键盘导航、屏幕阅读器兼容等规范，转成开发者可以直接参考的实现方案。
- 覆盖范围广：从 Web 端的语义 HTML、ARIA 角色与状态、焦点管理，到移动端的 VoiceOver / TalkBack、触摸目标尺寸与动态字体，均有对应指引。
- 规范可查：内置 WCAG 2.2 成功标准检查清单与颜色对比度要求（AA 4.5:1、AAA 7:1、非文本 3:1 等），方便逐条核对。
- 有现成模式：提供可访问按钮、模态对话框、可访问表单、跳过导航链接、实时区域（live region）等常见组件的实现范式与常见坑位清单。
- 上手成本低：只需在支持 AI 技能的平台上安装该技能，用自然语言描述需求即可获得结构化建议，适合前端、移动端、设计与 QA 协同使用。
1. 该技能叫什么？如何一键安装 AI 技能提升开发效率？
技能中文名：可访问性合规 技能英文名：accessibility-compliance 技能 ID：13168
它要解决的问题很具体：无障碍规范条文多、英文原文长、分散在 WCAG 文档与各家框架实践中，团队往往"知道要合规，但不知道从哪一行代码改起"。这个技能把规范、检查清单、组件模式和测试工具整合在一起，让开发者用一句话描述场景，就能拿到"该满足哪条标准、代码怎么写、怎么验证"的完整回答。
一键安装的思路与一般步骤（具体命令、入口地址与账号要求请以官方说明为准）：
- 确认前提：你的账号已具备使用 AI 技能（Skill）的能力，且当前工作环境支持安装第三方技能；部分平台要求先登录账号并开通技能市场权限。
- 找到技能：在技能市场 / 技能商店的搜索框中输入技能名「可访问性合规」或英文名「accessibility-compliance」，也可以直接用技能 ID「13168」定位，避免同名技能混淆。
- 一键添加：在技能详情页点击安装 / 添加按钮，按提示确认授权范围，等待状态变为"已安装"。
- 在会话中启用：新建对话时选择该技能，或按平台规则在对话中显式调用（不同平台可能是 @ 技能名、技能开关或命令形式，以官方说明为准）。
- 验证是否生效：问一个边界明确的问题，例如"实现一个键盘可访问的模态对话框，需要哪些 ARIA 属性和焦点管理？"如果回答中出现
role="dialog"、aria-modal、焦点陷阱、Escape 关闭等要素，说明技能已正常挂载。
安装完成后无需额外配置，后续提问会自动带上无障碍领域的专业上下文，这就是"一键安装提升开发效率"的核心逻辑——把领域知识前置注入，减少查文档与反复纠正提示词的时间。
2. 该技能的主要功能和特点
- WCAG 2.2 合规指引：围绕可感知、可操作、可理解、健壮四大原则，给出 Level A / AA / AAA 的达标路径，并附成功标准检查清单（如 1.1.1 非文本内容替代、1.4.3 对比度 4.5:1、2.4.7 焦点可见、2.5.8 目标尺寸 24×24px 等）。
- ARIA 模式落地：覆盖角色（role）、状态（展开 / 选中 / 禁用）、属性（labelledby、describedby）与实时区域（live region），强调"能用原生语义就不要堆 ARIA"的最佳实践。
- 键盘导航与焦点管理：包含 Tab 顺序、可见焦点指示器、快捷键、模态框焦点陷阱，以及导致焦点卡死的常见"键盘陷阱"排查。
- 屏幕阅读器兼容：语义化 HTML 结构、图片替代文本、标题层级、地标（landmark）与跳过链接，覆盖 VoiceOver、NVDA、JAWS、TalkBack 等主流工具。
- 移动可访问性：触摸目标最小 44×44dp、手势替代方案、动态字体（Dynamic Type）支持，适配 iOS 与 Android 双端。
- 可直接抄的组件模式：可访问按钮（含
aria-busy加载态播报）、模态对话框、带错误摘要的表单、跳过导航链接、结果数量播报等，均有示例代码。 - 常见坑位清单：缺 alt、对比度不足、表单无标签、自定义控件重造原生功能、自动播放媒体、焦点顺序与视觉顺序不一致等，能直接当自查表用。
- 测试工具指路：自动化侧推荐 axe DevTools、WAVE、Lighthouse；手动侧推荐真实屏幕阅读器；并提示可结合视觉模拟器辅助验证。
与普通"代码生成工具"的区别在于：它不只产出能跑的代码，还要求代码满足规范——焦点可见、状态可播报、目标尺寸达标，这些细节恰恰是通用工具最容易漏掉的部分。
3. 如何使用该技能？
步骤一：明确你的目标等级。 先告诉技能你要达到 A、AA 还是 AAA。多数产品以 AA 为基线，AAA 通常只对关键页面提要求。
步骤二：用"场景 + 技术栈 + 约束"三段式提问。 输入示例：
我有一个 React + TypeScript 的后台系统，需要一个带加载状态的主按钮组件，要求符合 WCAG 2.2 AA：加载时禁用、键盘可聚焦、触摸目标不小于 44×44px，请给出实现要点和必填的 ARIA 属性。
步骤三：按输出结构落地。 典型输出会包含：需要满足的成功标准编号、组件代码骨架、必须声明的 ARIA 属性、可见焦点样式写法，以及自测方法。
步骤四：做一次审核式提问。 把已有代码片段贴进去，问"这段模态框有哪些无障碍违规，怎么改？"技能会按常见问题清单（缺失标签、焦点陷阱、Escape 未响应、背景未 aria-hidden 等）逐项指出。
步骤五：补充移动端与偏好适配。 追加提问如"iOS VoiceOver 下如何让这个卡片正确播报"或"如何支持 prefers-reduced-motion 与高对比度偏好"，拿到跨端建议。
步骤六：用工具验证。 依据技能给出的测试工具建议，先用 axe DevTools / Lighthouse 跑一遍自动化检查，再用键盘走查 + 屏幕阅读器手动确认，避免"自动化全绿但真实用户用不了"。
小提示：输入示例越具体（框架、组件、目标等级、目标人群），输出越贴近可直接提交的代码。若详情中未涉及的命令或平台配置，请以官方说明为准。
4. 同类型竞品对比分析
| 方案名称 | 定位 | 核心功能 | 安装/使用门槛 | 适用场景 | 优势与不足 |
|---|---|---|---|---|---|
| 可访问性合规（本技能） | AI 技能：规范 + 实现模式的知识助手 | WCAG 2.2 清单、ARIA 模式、键盘与焦点、屏幕阅读器、移动可访问性、组件范式 | 在支持技能的平台一键安装；需描述清楚场景 | 写代码前查方案、评审时查违规、培训新人 | 优势：回答成体系、带示例与自测方法；不足：不直接对页面做自动化扫描，最终仍需人工与工具验证 |
| axe DevTools | 浏览器扩展类自动化检测工具 | 扫描页面并列出违规项与修复建议 | 安装浏览器插件，几乎零学习成本 | 页面级快速体检、回归检查 | 优势：快、误报相对少；不足：无法覆盖全部语义与体验问题，需配合手动测试 |
| WAVE | 可视化无障碍评估工具 | 页面标注错误、对比度、结构提示 | 在线使用或安装扩展 | 教学演示、结构性问题定位 | 优势：可视化直观；不足：偏检查而非实现指导，复杂交互组件不够深入 |
| Lighthouse | 综合性能与质量审计 | 无障碍评分 + 性能 + SEO 等 | 集成在浏览器开发者工具中 | 上线前综合体检 | 优势：无需额外安装、指标统一；不足：无障碍项覆盖范围有限，评分不能代表真实可用性 |
| eslint-plugin-jsx-a11y | 静态代码检查 | 在编码阶段提示 JSX 无障碍问题 | 需在项目中配置构建链 | 团队规范化、CI 卡口 | 优势：左移最早、成本低；不足：只查静态代码，无法判断焦点流程与实际播报效果 |
结论：这几类方案是互补关系。本技能负责"怎么写、为什么这么写"，静态检查与自动化扫描负责"有没有漏"，真实屏幕阅读器与残障用户测试负责"到底好不好用"。三者叠加，才构成完整的无障碍质量闭环。
5. 该技能的典型应用场景与实际体验情况
场景一：前端工程师改造存量表单。
痛点：表单报错只在输入框下方变红，屏幕阅读器用户完全感知不到。使用方式：贴入表单代码并说明"需要错误摘要 + 实时播报"。技能会建议用 role="alert" 配合 aria-live="assertive" 输出错误摘要，输入框加 aria-invalid 与 aria-describedby 关联提示文本，必填项用视觉星号加 sr-only 文字双重标注。实际体验：上手几乎零门槛，方案与现有组件库兼容性好；注意错误摘要里的锚点链接要指向字段 id，否则跳转无效。
场景二：设计 / 产品做上线前合规自检。 痛点：设计师不清楚对比度到底差多少、点击区域多大才算够。使用方式：直接索取对比度要求与目标尺寸标准。技能会明确正常文本 AA 4.5:1、大文本 3:1、UI 组件与非文本 3:1，WCAG 2.2 新增的 2.5.8 要求最小 24×24px，AAA 级别则要求 44×44px。实际体验：把抽象规范变成可核对的数字，评审会效率明显提升；注意"大文本"的界定（约 18pt 或 14pt 粗体）容易记错，建议写进团队检查清单。
场景三：移动端团队适配 VoiceOver / TalkBack。 痛点：手势操作在屏幕阅读器下失效，卡片信息播报顺序混乱。使用方式：描述组件结构与交互，要求给出触摸目标 44×44dp、手势替代、动态字体支持建议。实际体验：对双端差异的提示很实用；注意事项是必须在真机上用真实屏幕阅读器验证，模拟器结论只能作参考。
场景四：代码评审 / 新人培训。 痛点：评审时没人能说出具体违反了哪条标准。使用方式：让技能按"违规项 + 对应成功标准编号 + 修复建议"输出。实际体验：有了标准编号，讨论从"我觉得不好用"变成"这违反 2.4.7 焦点可见"，沟通成本大幅下降。
6. 该技能能为用户带来的价值
- 效率提升：以往查 WCAG 原文、翻 ARIA 编写实践、再对照框架实现，一个组件的无障碍改造可能耗掉半天；现在用自然语言提问即可拿到成体系的方案骨架，把时间集中在验证与打磨上。
- 门槛降低：无障碍常被视为"专家领域"，该技能把规范、模式、坑位清单前置，让没有 a11y 背景的开发者也能写出基本合规的代码。
- 风险前置：不少行业对无障碍有明确的合规要求，问题发现得越晚修复成本越高。在编码阶段就对照检查清单自查，可显著减少上线后返工。
- 体验普惠：键盘用户、屏幕阅读器用户、低视力与运动障碍用户都能受益，覆盖的是真实存在且规模不小的人群。
- 长期资产：沉淀下来的组件模式与团队检查清单可复用，形成组织级的无障碍规范，而不是一次性修补。
7. 常见问题 FAQ
Q1：这个技能怎么安装？需要写代码配置吗？ A：在支持 AI 技能的平台技能市场搜索中文名「可访问性合规」、英文名「accessibility-compliance」或技能 ID「13168」，点击安装并在会话中启用即可，通常不需要写配置文件。具体入口与账号权限要求请以官方说明为准。
Q2：使用它收费吗？ A：该技能的计费方式取决于所在平台的规则，技能详情中未提供价格信息，请以官方说明为准。一般可先在平台查看是否有试用额度，再决定是否长期使用。
Q3：它能替代 axe、WAVE 这类自动化检测工具吗？ A：不能，二者定位不同。该技能提供的是实现方案、规范依据与自查清单，属于"教你怎么做"；自动化工具负责扫描已渲染页面并列出违规项，属于"帮你查漏"。建议技能 + 自动化工具 + 真实屏幕阅读器手动测试三者结合。
Q4：适合谁用？后端或设计师用得上吗？ A：最适合前端与移动端开发者，但设计师可用于核对对比度与目标尺寸，产品与 QA 可用于编写验收标准，技术负责人可用于制定团队规范。只要涉及界面交付，都能从中获益。
Q5：支持哪些等级和平台？ A：覆盖 WCAG 2.2 的 Level A、AA、AAA 要求，并包含 Web 端（语义 HTML、ARIA、键盘导航、屏幕阅读器）与移动端（iOS VoiceOver、Android TalkBack、触摸目标、动态字体）的适配指引。示例以 React / TypeScript 为主，其他技术栈可按同样思路迁移。
Q6：和通用 AI 编程助手相比，优势在哪？
A：通用助手能写出"能跑"的组件，但不一定会提醒你加 aria-busy、不一定会检查焦点陷阱、不一定告诉你违反了哪条成功标准。该技能的价值在于把合规要求变成默认输出的一部分。