关于 accessibility-audit
面向网站团队的 WCAG 2.2 无障碍审计技能,依照 WCAG-EM 评估页面。它结合自动扫描与引导式人工检查,并生成基于抽样和证据的符合性报告。
主要功能
- 01WCAG-EM 审计流程
- 02结构化页面抽样
- 03自动与人工评估层级
- 04严重程度与证据分级
- 05按成功标准报告符合性
适用场景
- 01按 WCAG 2.2 AA 审计网站
- 02检查关键流程和复杂界面状态
- 03整理结果以供人工辅助技术评审
安装
复制下面的命令,在终端中运行。
npx skills add https:/ / github.com/ accesslint/ skills --skill accessibility-audit安装后在 Claude Code 中输入/accessibility-audit确认已加载。
详细介绍
这是一次采用 WCAG-EM 的完整 WCAG 2.2 无障碍审计。它会界定范围、抽取有代表性的页面和流程、执行两个评估层级,并生成一份符合性报告:
- 自动化层级:
accesslint:accessibility-scan(规则引擎)。 - 半自动化人工层级:
accesslint:accessibility-inspect(键盘、焦点、状态、重排,以及引擎无法判定的其他方面)。
进行评估,不要修复(accesslint:accessibility-fix)或比较差异(accesslint:accessibility-diff)。不进行抽样的单个页面检查属于 accessibility-scan,而非审计。此技能会将每个抽样页面交由各自的子 Agent 处理(步骤 4),因此即使抽样数量较大,也能保持轻量。
完整方法论——包括 WCAG-EM 详解、含示例的严重程度分级规则、不可代理边界和证据依据——见 ../shared/methodology.md。运行此技能所需的规则如下。
分级
每项发现都包含严重程度和证据依据。请分别标注。
- 证据依据:● 已验证(确定性结论,附有引用证据)· ◐ 已标记(已收集证据,由人工判断)· ○ 需人工评估(需要辅助技术或亲身体验;转交人工处理,不进行模拟)。
- 严重程度:严重(阻碍核心任务)· 高(构成重大障碍)· 中(造成不便,但仍可完成)· 轻微(完善细节)。
WCAG-EM 步骤
按顺序执行,并说明每一步做了什么。
-
界定范围。说明目标及其边界、目标等级(默认为 WCAG 2.2 AA;
--level AAA会增加 AAA)、所用技术,以及人工交接应涵盖的辅助技术基线。由你界定该基线;不对其进行测试。 -
探索。使用 Glob/Grep 查找路由、模板和共享组件。记录关键流程、内容类型和有状态 UI(模态框、向导、空状态和错误状态)。
accesslint.config.json中的目标是起点。 -
抽样。选择一组有结构的样本(入口页面、每个关键流程的端到端路径、每个使用新模板或复杂组件的页面,以及重要状态),再加上一小组随机样本。说明每项样本包含什么以及选择原因。
-
评估。将每个抽样页面或状态委派给单独的
Task,使其在独立上下文中运行并返回发现;独立页面可以并行处理。每个 Task:- 先运行
accesslint:accessibility-scan(--format json),再针对相同的渲染状态运行accesslint:accessibility-inspect——使用相同的 URL、--selector和--wait-for——并将扫描结果(或至少引擎覆盖的 SC 列表)传入检查运行; - 在执行前而非执行后按 SC 归属去重:
accessibility-scan负责可由规则检测的标准,accessibility-inspect负责交互和判断标准;inspect 不得重新检查由引擎负责的 SC;如果两者仍在同一元素上覆盖同一 SC,则以accessibility-scan的结果为准; - 返回结构化内容块:逐条列出发现项的 SC、严重程度、证据依据(●/◐/○)、位置、层级、证据,以及修复建议或交接事项;另附此页面按 SC 划分的记录表(已验证 / 已标记 / 引擎负责 / 不适用 / 未检查)。
在步骤 5 汇总返回的内容块。对于只有一到两个页面的范围,直接运行各层级,而不是启动
Task。可选共享浏览器有助于在各层级间匹配选择器,但它是预先配置的前置条件,并非此技能会在运行时设置的内容:浏览器 MCP 会在服务器启动时连接到其 Chrome(使用
--autoConnect或--browser-url),引擎则指向相同端口。默认情况下不使用共享浏览器;每个 Task 都会在相同的 URL 和--wait-for条件下运行两个层级,并按 SC 归属去重。 - 先运行
-
报告。按下方格式汇总。符合性只有两种状态:仅 ● 发现项可判定为通过或不通过;所有 ◐ 或 ○ 项,以及没有页面检查过的每个 SC,均为未判定,需交由人工处理。任一抽样页面未通过某 SC,即表示该等级下整个范围未通过该 SC。不要报告无法证实的符合性,也不要让未检查的 SC 看起来像是通过。记录表只保留计数和简洁的 SC 列表——按共同原因对未判定的 SC 分组,每组用一个短语说明;报告的篇幅应集中在失败项、标记项和交接事项上:通过项只需在列表中列出 SC 编号,整个通过项集合最多附一句说明。
报告格式
# Accessibility audit — <product / scope>
WCAG 2.2 Level AA · WCAG-EM · <N> pages/states sampled
## Scope
- Target & boundary: <…> Goal: WCAG 2.2 AA
- Technologies in use: <…>
- AT baseline (for the human handoff, not tested here): <SR+browser pairs, keyboard-only, …>
## Sample
- Structured: <page/state> — <why> (×N)
- Random: <page/state>
## Conformance (per success criterion)
- Pass ●: <n> · Fail ●: <n> · Undetermined (◐/○/not exercised): <n> · N/A: <n>
- Fail ●: <SCs> Pass ●: <SCs> N/A: <SCs>
- Undetermined: <SCs (shared reason)> · <SCs (shared reason)>
- Pass/fail is asserted only for ● criteria; ◐/○ and not-exercised are undetermined.
## Findings — by severity, tagged by evidence basis
### Critical
- [●] <barrier> — SC x.x.x — where: <selector / file:line> — tier: scan|inspect — → `accessibility-fix`
- [◐] <barrier> — SC x.x.x — evidence: <screenshot / measurement> — confirm: <what a person checks>
### Serious / Moderate / Minor
[same shape]
## Human-required (○) — the testing handoff
- <what only AT or lived experience reveals> — SC x.x.x
needs: <functional ability + AT, per Section 508 FPC> flow: <sampled flow>
## Recommendations
- Root-cause / pattern fixes (one change that clears many instances) → hand to `accessibility-fix`.
- What to send to human and AT testing, and on which flows.
- Wire `accesslint:accessibility-diff` into CI for the sampled targets.
备注
- 评估,不要修复(使用
accessibility-fix)或比较差异(使用accessibility-diff)。不要模拟人类体验:可用性属于 ◐,亲身体验属于 ○,应交由人工处理。 - 符合性按整个样本中的每个 SC 分别判定。不要用平均值掩盖失败。
- 两个浏览器的选择器可能不一致;为达到 ● 精度,优先使用共享浏览器,否则注明去重仅为尽力而为。
- 说明未覆盖的内容(样本之外的页面、○ 标准)。省略会被理解为“一切正常”。
- 使用
list_rules和explain_rule获取引擎规则元数据。