accessibility-review

无障碍审查

概述

此技能可根据 WCAG 2.1/2.2 AA 级标准，对 Web 内容、组件和应用进行手动无障碍审查。审查重点关注实用、现代的无障碍要求，同时避免过于吹毛求疵。

何时使用此技能

当用户提出以下问题时，请使用此技能：

• “这个符合无障碍要求吗？”
• “可以检查一下颜色对比度吗？”
• “检查这个组件是否存在无障碍问题”
• “这符合无障碍标准吗？”
• 任何要求审查、检查或验证无障碍性的请求

审查流程

1. 确定目标

确定需要审查的对象：

• 特定组件（按钮、表单、模态框等）
• 整个页面或应用
• 代码文件或一组文件
• 设计稿或屏幕截图

2. 进行手动审查

使用 references/wcag-checklist.md 中的 WCAG 检查清单，根据现代无障碍标准系统地审查目标。

重点关注最常见且影响最大的问题：

• 可感知性：颜色对比度、文本替代内容、语义结构
• 可操作性：键盘导航、焦点管理、交互元素
• 可理解性：清晰的标签、错误处理、一致的导航
• 健壮性：有效的 HTML、ARIA 用法、兼容性

3. 为发现的问题划分优先级

将每个问题分类为：

严重 — 阻碍用户访问核心功能：

• 有意义的图像缺少替代文本
• 交互元素无法通过键盘访问
• 颜色对比度不足（普通文本低于 4.5:1，大号文本低于 3:1）
• 表单缺少适当的标签
• 缺少焦点指示器
• 模态框/对话框模式无法访问
• 媒体自动播放且没有控件

警告 — 增加使用阻力，但不会完全阻断访问：

• 标题层级不理想（跳过级别）
• 缺少 ARIA 地标
• 脱离上下文时含义不清的链接文本
• 冗余或不必要的 ARIA
• 触控目标小于 44x44px
• 缺少跳过链接
• 错误消息缺乏描述性

4. 分步审查（一次处理一个问题）

重要：不要一次性列出所有发现的问题。应逐个审查问题，并在继续之前等待用户决定。

4.1 从概述开始

首先告知用户发现了多少个问题：

Found [X] accessibility issues ([Y] critical, [Z] warnings).

Let's review them one at a time. I'll present each issue with a recommended fix, and you can decide to:
- **Fix** — I'll implement the change
- **Ignore** — Tell me why, and I'll note it

Starting with critical issues first.

4.2 展示每个问题

逐个展示问题，每次只展示一个，并使用以下格式：

───────────────────────────────────
Issue [1/X]: [Critical/Warning]
───────────────────────────────────

**Problem**: [Clear description of the issue]

**Location**: `file_path:line_number`
[Show the relevant code snippet]

**Impact**: [How this affects users — be specific about who and how]

**Recommended Fix**:
[Specific code change or approach]

───────────────────────────────────
Fix this issue, or ignore? (If ignoring, please share why)

4.3 处理用户回复

如果用户说“修复”：

1. 实施修复
2. 确认：“已修复。[简要说明所做的更改]”
3. 继续处理下一个问题

如果用户说明理由后说“忽略”：

1. 确认：“已记录——因以下原因忽略：[用户的理由]”
2. 记录此决定（参见 4.4）
3. 继续处理下一个问题

如果用户没有说明理由就说“忽略”：

1. 询问：“知道了。可以简单说一下原因吗？（有助于日后参考）”
2. 接受任何回复并继续

4.4 记录决定

随着审查问题的进行，持续记录决定。审查完所有问题后，提供总结。

5. 最终总结

审查完所有问题后，提供总结：

## Accessibility Review Complete

**Reviewed**: [X] issues ([Y] critical, [Z] warnings)

### Fixed ([N])
- [Issue description] — `file:line`
- [Issue description] — `file:line`

### Ignored ([N])
- [Issue description] — Reason: [user's reason]
- [Issue description] — Reason: [user's reason]

### Remaining Concerns
[Any patterns noticed, suggestions for future, or issues that were ignored but warrant reconsideration]

审查指南

务实为先：重点关注真正影响用户的问题。标准为现代 WCAG 2.1/2.2 AA 级要求——避免过度设计或引用鲜为人知的边缘情况。

具体明确：尽可能使用 file_path:line_number 格式标出代码中的实际位置。

注重建设性：提供可执行的修复方案，而不只是指出问题。适当时提供代码示例。

考虑上下文：某些模式在无障碍方面可能存在取舍。请说明这些情况，并针对具体用例提出最易访问的方案。

常见检查模式

交互元素

• 所有交互元素都必须支持键盘访问（按 Enter/Space 激活）
• 焦点必须清晰可见
• 自定义控件需要适当的 ARIA 角色和状态

表单

• 所有输入项都必须关联标签（显式标签或 aria-label）
• 错误消息必须以编程方式与对应字段关联
• 必填字段必须有明确标示

颜色与对比度

• 文本对比度：普通文本至少为 4.5:1，大号文本（18pt+ 或 14pt+ 粗体）至少为 3:1
• UI 组件：交互元素及其状态的对比度为 3:1
• 不要仅依赖颜色来传达信息

图像与媒体

• 有意义的图像需要描述性替代文本
• 装饰性图像的替代文本应为空（alt=""）
• 视频需要字幕，音频内容需要文字稿

结构

• 使用语义化 HTML（nav、main、article 等）
• 标题层级应合乎逻辑（h1 → h2 → h3）
• ARIA 地标有助于屏幕阅读器导航

资源

此技能包括：

references/wcag-checklist.md

按原则（可感知、可操作、可理解、健壮）组织的 WCAG 2.1/2.2 AA 级要求综合清单。审核时请参考此清单，确保全面覆盖无障碍标准。