关于 accessibility-audit
用于网站和产品团队的无关技术栈无障碍审计技能,依据 WCAG 2.1 AA 检查并整理修复计划。它结合自动扫描与键盘、屏幕阅读器、视觉和认知测试。
主要功能
- 01按 WCAG 四项原则审计
- 02结合自动扫描与人工测试
- 03按严重程度排列问题
- 04生成审计报告与修复计划
- 05记录数据与工具缺口
适用场景
- 01上线前检查网站无障碍情况
- 02为法规合规准备材料
- 03跟进审计发现或用户投诉
- 04开展定期无障碍健康检查
安装
复制下面的命令,在终端中运行。
npx skills add https:/ / github.com/ rampstackco/ claude-skills --skill accessibility-audit安装后在 Claude Code 中输入/accessibility-audit确认已加载。
包含的文件
除 SKILL.md 外,安装时一起下载的参考资料和脚本。
README.mdreferences/aria-patterns.mdaudit-report-template.mdwcag-quick-reference.md详细介绍
无障碍审计
运行全面的无障碍审计,并制定修复计划。与技术栈无关。以 WCAG 2.1 AA 为基准,并在相关处注明 AAA。
此技能比 qa-testing 和 design-standards 中的无障碍检查更深入。当无障碍本身是目标时使用此技能。
适用场景
- 上线前无障碍验证
- 合规准备(ADA、EN 301 549、AODA、Section 508)
- 对审计发现的问题或投诉进行修复
- 年度或季度无障碍健康检查
- 为此前未优先考虑无障碍的团队开展无障碍入门培训
不适用场景
- 部署后的常规 QA(使用
qa-testing) - 组件级无障碍实现(使用
frontend-component-build) - 设计令牌的颜色对比度(使用
design-standards或brand-identity)
必需输入
- 待审计的网站或产品
- 范围(整个网站、特定版块、特定用户流程)
- 目标标准(最常见的是 WCAG 2.1 AA)
- 任何具体顾虑或已知问题
- 可用工具(自动扫描工具、屏幕阅读器、手动测试)
框架:WCAG 的 4 项原则
WCAG 围绕四项原则组织无障碍要求。审计会深入检查每一项。
1. 可感知
信息和 UI 必须以用户能够感知的方式呈现。
审计检查项:
- 文本替代。 所有非装饰性图像都有描述性的
alt文本。装饰性图像使用alt=""。复杂图像(图表、信息图)提供长描述。 - 基于时间的媒体。 视频配有字幕。预先录制的音频提供文字稿。必要时,实时音频提供实时字幕。
- 适应性。 内容结构通过标记(语义化 HTML)传达,而不只是通过视觉样式。禁用 CSS 后,阅读顺序仍然合理。
- 可区分。 颜色不是传达信息的唯一方式。文本对比度达到 AA 标准(普通文本为 4.5:1,大号文本为 3:1)。UI 元素对比度达到 3:1。音频可以暂停、停止或静音。
2. 可操作
UI 组件和导航必须可操作。
审计检查项:
- 支持键盘操作。 所有功能都可仅通过键盘使用。不存在键盘陷阱。焦点清晰可见。
- 提供充足时间。 时间限制可以调整、暂停或延长。自动更新的内容可以暂停。
- 避免癫痫发作和身体不适。 不存在每秒闪烁超过 3 次的内容。
- 可导航。 提供跳过链接。页面具有描述性标题。焦点顺序合理。链接用途可从文本或上下文中明确得知。提供多种查找页面的方式(网站地图、搜索、导航)。标题和标签具有描述性。
- 输入方式。 指针手势提供键盘替代方式。支持指针取消(在鼠标抬起时激活,而非鼠标按下时)。标签与无障碍名称一致。由动作触发的功能提供替代方式。
3. 可理解
信息和操作必须易于理解。
审计检查项:
- 可读。 声明页面语言(
<html lang="...">)。为生僻词和缩写提供定义或完整形式。阅读难度适合目标受众。 - 可预测。 焦点变化不会意外改变上下文。输入不会意外改变上下文。各页面的导航保持一致。外观相似的组件行为相似。
- 输入辅助。 清晰标识错误。为输入提供标签和说明。尽可能提供错误修正建议。对于处理法律承诺或金融交易的页面,用户可在提交前检查并更正错误。
4. 稳健
内容必须足够稳健,以便兼容当前和未来的用户代理。
审计检查项:
- 兼容性。 标记有效。可通过编程方式确定 UI 组件的名称、角色和值。状态消息可通过编程方式确定并播报。
审计方法
阶段 1:自动扫描
在优先检查的页面上运行自动扫描工具。这些工具可以发现 30% 到 50% 的问题,但会漏掉其余问题。
工具:
- axe DevTools(浏览器扩展)
- Lighthouse(Chrome DevTools 无障碍审计)
- WAVE(浏览器扩展)
- Pa11y(用于批量扫描的 CLI)
输出: 按页面列出的自动扫描结果。
阶段 2:手动键盘测试
拔掉鼠标。仅使用键盘浏览优先用户流程。
测试:
- Tab 和 Shift+Tab 按逻辑顺序在交互元素之间移动
- Enter 激活按钮和链接
- 空格键激活按钮(并切换复选框)
- 方向键在复合控件内导航(标签页、菜单、列表框)
- Escape 关闭模态框、弹出层和菜单
- 焦点始终清晰可见
- 模态框或弹出层关闭后,焦点返回到合理的位置
- 不存在键盘陷阱(焦点始终可以移出)
记录: 键盘导航中断的任何流程。
阶段 3:屏幕阅读器测试
至少使用一种真实屏幕阅读器进行测试,或者根据数据可用性规则说明缺口。每种组合都有其特有问题。
常见组合:
- VoiceOver + Safari(macOS / iOS)
- NVDA + Firefox 或 Chrome(Windows)
- JAWS + Chrome(Windows;商业软件,但在企业中很常见)
- TalkBack + Chrome(Android)
测试:
- 页面结构播报正确(标题、地标)
- 表单标签与对应输入框一同读出
- 错误出现时会播报
- 状态变化会播报(加载、成功、错误)
- 模态框打开时会播报其上下文
- 图像具有有意义的替代文本(或被正确识别为装饰性图像)
阶段 4:视觉测试
检查无障碍的视觉方面。
测试:
- 所有文本与背景组合的颜色对比度(使用对比度检查工具)
- UI 元素的对比度(图标、边框、焦点环为 3:1)
- 色盲模拟(至少模拟绿色盲)
- 缩放到 200%——内容仍可使用,且不会出现水平滚动
- 在 320px 视口下重新排版
- 应用文本间距(行高、字间距)后,内容不会被截断
- 可以减少动画(遵循
prefers-reduced-motion)
阶段 5:认知无障碍
这方面经常被忽视,却对打造包容性产品至关重要。
测试:
- 阅读难度适当
- 说明清晰
- 错误消息说明如何修复错误,而不只是指出发生了错误
- 表单允许在提交前修改内容
- 可以避免或延长时间限制
- 重要内容不依赖用户对先前页面的记忆
工作流
- 确定范围。 整个网站?特定流程?特定页面模板?
- 运行自动扫描。 按页面记录结果。
- 手动检查键盘操作。 测试所有优先流程。
- 检查屏幕阅读器。 至少使用一种组合进行测试。
- 检查视觉方面。 对比度、缩放、色盲、动画。
- 检查认知方面。 阅读难度、错误处理、时间限制。
- 依据 WCAG 评分。 按成功标准(A、AA、AAA 级)。
- 确定结果优先级。 严重(阻碍用户使用)、重要(降低使用体验)、轻微(细节优化)。
- 撰写报告。 使用
references/audit-report-template.md中的模板。 - 制定修复计划。 按顺序列出修复项,并估算工作量和影响。
严重性分类
用于确定优先级:
严重(P0):
- 阻断辅助技术用户的整个用户流程
- 导致关键页面完全无法访问
- 示例:没有标签的表单、没有焦点管理的模态框、无法通过键盘访问的主要 CTA
重要(P1):
- 显著降低辅助技术用户的体验
- 示例:关键图片缺少替代文本、正文文本对比度低、错误消息不会播报
轻微(P2):
- 影响边缘情况或特定辅助技术组合
- 示例:轻微的焦点顺序问题、缺少装饰性替代文本属性、边缘情况下的键盘处理问题
润色(P3):
- 超出 AA 要求、能提升无障碍体验但不影响合规的改进
- 示例:AAA 对比度目标、额外的减少动态效果变体、内嵌外语词语的语言属性
常见失败模式
- **只进行自动化扫描。**只能发现 30% 到 50% 的问题。其余 50% 到 70% 的问题需要通过键盘、屏幕阅读器和认知测试发现。
- **只测试首页。**首页通常是无障碍体验最好的页面。问题往往隐藏在更深层的流程中。
- **把无障碍工作当作一次性项目。**每次部署都会削弱无障碍体验。应将其融入开发周期。
- **不找根本原因就修复。**不了解问题产生的原因,只修补个别问题,新的问题仍会不断出现。
- **忽略屏幕阅读器测试。**很难做好,也很容易跳过。它是“我们以为已经满足无障碍要求”这类意外的最大来源。
- **混淆 AA 和 AAA。**AAA 很少是合适的目标。对大多数产品而言,AA 是切实可行的基线。
- **把无障碍责任仅归于设计师或开发者。**内容、产品、QA 和管理层都需要参与。
- **以为符合规范就等于无障碍。**符合 WCAG 是底线,而非上限。真实用户仍可能遇到困难。
输出格式
默认输出为全面的审计报告,保存至 accessibility-audit.md。
结构:
- 执行摘要
- 方法论(使用的工具、测试的页面、使用的屏幕阅读器)
- 按 WCAG 原则分类的发现
- 严重发现(P0),附具体 URL 和修复方法
- 重要发现(P1)
- 轻微发现(P2)
- 润色(P3)
- 修复路线图(按顺序排列并确定优先级)
- 附录(完整的自动化扫描结果、键盘导航备注、屏幕阅读器备注)
此外,还需提供一份修复跟踪电子表格,每个发现占一行。
所需数据不可用时
此技能的输出依赖其无法自行生成的数据、测量结果或工具结果。当所需输入、工具或数据源不可用或无法验证时,获准的输出方式是交付成果,并说明缺口:需要什么、实际获取或验证了什么,以及输出中的哪些部分受到影响。绝不允许为了完成交付成果而捏造、估算或插算所需数字。说明缺口即为完整答复。
参考文件
references/audit-report-template.md- 完整的审计报告模板。references/wcag-quick-reference.md- 精简版 WCAG 2.1 AA 标准及审计检查项。references/aria-patterns.md- 可用于决策的 ARIA 模式。语义化 HTML 优先原则、常见交互式组件(手风琴、标签页、模态框、切换开关、披露控件、导航)、实时区域、隐藏模式、标签、状态指示器、反模式。