mcpField
A
accessibility-audit

accessibility-audit

github.com/rampstackco测试与质量1.0k314 次安装2 周前更新
代码仓库

关于 accessibility-audit

用于网站和产品团队的无关技术栈无障碍审计技能,依据 WCAG 2.1 AA 检查并整理修复计划。它结合自动扫描与键盘、屏幕阅读器、视觉和认知测试。

主要功能

  1. 01按 WCAG 四项原则审计
  2. 02结合自动扫描与人工测试
  3. 03按严重程度排列问题
  4. 04生成审计报告与修复计划
  5. 05记录数据与工具缺口

适用场景

  1. 01上线前检查网站无障碍情况
  2. 02为法规合规准备材料
  3. 03跟进审计发现或用户投诉
  4. 04开展定期无障碍健康检查

安装

复制下面的命令,在终端中运行。

$npx skills add https://github.com/rampstackco/claude-skills --skill accessibility-audit

安装后在 Claude Code 中输入/accessibility-audit确认已加载。

包含的文件

除 SKILL.md 外,安装时一起下载的参考资料和脚本。

README.md
references/
aria-patterns.md
audit-report-template.md
wcag-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:认知无障碍

这方面经常被忽视,却对打造包容性产品至关重要。

测试:

  • 阅读难度适当
  • 说明清晰
  • 错误消息说明如何修复错误,而不只是指出发生了错误
  • 表单允许在提交前修改内容
  • 可以避免或延长时间限制
  • 重要内容不依赖用户对先前页面的记忆

工作流

  1. 确定范围。 整个网站?特定流程?特定页面模板?
  2. 运行自动扫描。 按页面记录结果。
  3. 手动检查键盘操作。 测试所有优先流程。
  4. 检查屏幕阅读器。 至少使用一种组合进行测试。
  5. 检查视觉方面。 对比度、缩放、色盲、动画。
  6. 检查认知方面。 阅读难度、错误处理、时间限制。
  7. 依据 WCAG 评分。 按成功标准(A、AA、AAA 级)。
  8. 确定结果优先级。 严重(阻碍用户使用)、重要(降低使用体验)、轻微(细节优化)。
  9. 撰写报告。 使用 references/audit-report-template.md 中的模板。
  10. 制定修复计划。 按顺序列出修复项,并估算工作量和影响。

严重性分类

用于确定优先级:

严重(P0):

  • 阻断辅助技术用户的整个用户流程
  • 导致关键页面完全无法访问
  • 示例:没有标签的表单、没有焦点管理的模态框、无法通过键盘访问的主要 CTA

重要(P1):

  • 显著降低辅助技术用户的体验
  • 示例:关键图片缺少替代文本、正文文本对比度低、错误消息不会播报

轻微(P2):

  • 影响边缘情况或特定辅助技术组合
  • 示例:轻微的焦点顺序问题、缺少装饰性替代文本属性、边缘情况下的键盘处理问题

润色(P3):

  • 超出 AA 要求、能提升无障碍体验但不影响合规的改进
  • 示例:AAA 对比度目标、额外的减少动态效果变体、内嵌外语词语的语言属性

常见失败模式

  • **只进行自动化扫描。**只能发现 30% 到 50% 的问题。其余 50% 到 70% 的问题需要通过键盘、屏幕阅读器和认知测试发现。
  • **只测试首页。**首页通常是无障碍体验最好的页面。问题往往隐藏在更深层的流程中。
  • **把无障碍工作当作一次性项目。**每次部署都会削弱无障碍体验。应将其融入开发周期。
  • **不找根本原因就修复。**不了解问题产生的原因,只修补个别问题,新的问题仍会不断出现。
  • **忽略屏幕阅读器测试。**很难做好,也很容易跳过。它是“我们以为已经满足无障碍要求”这类意外的最大来源。
  • **混淆 AA 和 AAA。**AAA 很少是合适的目标。对大多数产品而言,AA 是切实可行的基线。
  • **把无障碍责任仅归于设计师或开发者。**内容、产品、QA 和管理层都需要参与。
  • **以为符合规范就等于无障碍。**符合 WCAG 是底线,而非上限。真实用户仍可能遇到困难。

输出格式

默认输出为全面的审计报告,保存至 accessibility-audit.md。

结构:

  1. 执行摘要
  2. 方法论(使用的工具、测试的页面、使用的屏幕阅读器)
  3. 按 WCAG 原则分类的发现
  4. 严重发现(P0),附具体 URL 和修复方法
  5. 重要发现(P1)
  6. 轻微发现(P2)
  7. 润色(P3)
  8. 修复路线图(按顺序排列并确定优先级)
  9. 附录(完整的自动化扫描结果、键盘导航备注、屏幕阅读器备注)

此外,还需提供一份修复跟踪电子表格,每个发现占一行。


所需数据不可用时

此技能的输出依赖其无法自行生成的数据、测量结果或工具结果。当所需输入、工具或数据源不可用或无法验证时,获准的输出方式是交付成果,并说明缺口:需要什么、实际获取或验证了什么,以及输出中的哪些部分受到影响。绝不允许为了完成交付成果而捏造、估算或插算所需数字。说明缺口即为完整答复。


参考文件

评论

支持 Markdown