name: accesslint-audit
description: “查找并修复 WCAG 2.2 可访问性问题。两种模式——报告（扫描代码库或页面，生成按优先级排序的书面报告，不编辑）和修复（对目标进行审计→编辑→验证循环）。偏好直接 CDP 实时 DOM 审计；回退到浏览器 MCP 组合或 HTML 字符串审计。”
risk: safe
source: “https://github.com/AccessLint/skills”
date_added: “2026-06-02”
你审计可访问性，并可选地修复发现的问题。
何时使用
- 当任务与此描述匹配时使用此技能：查找并修复 WCAG 2.2 可访问性问题。两种模式——报告（扫描代码库或页面，生成按优先级排序的书面报告，不编辑）和修复（对目标进行审计→编辑→验证循环）。偏好直接 CDP 实时 DOM 审计；回退到浏览器 MCP 组合或 HTML 字符串审计。
根据用户意图选择模式
- 报告模式——“审计我的代码库”、“审查 src/components/”、“这个页面有什么问题？”、“给我一份可访问性报告”。你审计并编写报告。你不编辑文件。
- 修复模式——“修复 X 中的可访问性问题”、“审计并修复”、“使其可访问”、“验证对比度修复是否生效”，或者将违规报告交给你并要求应用修复。你审计 → 编辑 → 验证。
如果不确定，请询问。当用户仅要求审计时，不要默认使用修复模式。
对于非常大的扫描，当主线程上下文成本很重要时，你可以通过Task（通用目的代理）被调用以实现上下文隔离。无论哪种方式，流程都是一样的。
选择流程
三个流程，按偏好顺序排列。
audit_live——对任何 URL 首先尝试。连接到正在运行的 Chrome 调试会话，或自动最小化启动 Chrome——无需用户设置。单次调用；IIFE 字节不会进入你的上下文。audit-live-page提示——当用户需要审计其现有浏览器会话（已认证的应用、特定状态）且已连接浏览器 MCP（chrome-devtools-mcp、playwright-mcp、puppeteer-mcp）时使用。通过Skill调用，使用mode: "fix"或mode: "plan"。audit_html——用于原始 HTML 字符串、文件（先Read，然后audit_html）或已渲染为字符串的 JSX。与audit_diff({ html })配对用于修复模式验证。
对于非 URL 目标，直接跳到流程 3。对于 URL，先尝试流程 1；如果自动启动失败，如果已连接浏览器 MCP 则尝试流程 2；否则回退到流程 3，并注明实时 DOM 覆盖受限。
范围处理（报告模式）
- 目录路径——分析其中的所有相关文件。
- 多个文件——分析列出的文件及其导入的文件。
- URL——审计它。如果是开发服务器 URL，则使用流程 1 或 2。
- 无参数——让用户缩小范围。全代码库扫描很少是合适的做法。
在报告开头明确说明范围。
方法（报告模式）
- 映射表面。使用 Glob/Grep 枚举组件、模板、样式。采样代表性文件；不要盲目打开所有内容。
- 尽可能审计实时 DOM——渲染后的 DOM 能捕获源码无法显示的问题。使用上面的流程选择器。
- 寻找模式。如果一个组件违反了一条规则，类似组件很可能也有同样的问题。按规则 ID 和组件系列分组——不要将同一问题的 30 个实例列出 30 次。
- 按用户影响排序。严重/严重优先。多条低影响规则违规往往是一个单一的根本原因修复。
- 扫描时使用
format: "compact"。将详细输出保留给你将在报告中展开的规则。 - 信任
Source:行。针对 React 开发构建的实时 DOM 审计通过 DevTools fibers 为每个违规附加Source: <file>:<line> (Symbol)。将其用作文件指针，而非 grep 选择器。当缺失时，回退到稳定钩子 → 可见文本 → 树位置。 - 如果单次审计返回超过约 50 个违规，停止并询问——一份 200 个违规的报告不可操作。
引擎捕获的是机械可检测的内容。内容清晰度、屏幕阅读器播报质量、键盘流程连贯性和复杂视觉对比度需要人工判断——标记这些供人工审查，不要猜测。
报告格式
# 可访问性审计 — <范围> ## 摘要 - N 个严重，M 个严重，K 个中等，J 个轻微（去重后） - 影响最大的模式：<每行一个，最多 3 个> ## 严重（阻碍访问） 对每个模式： - **模式**：<一行描述> - **WCAG**：<ID> — <名称> - **受影响文件**：<file:line>（如重复 ×N） - **修复**：<引擎输出中的指令，或具体代码变更> - **为什么严重**：<用户影响> ## 严重 [相同结构] ## 中等 / 轻微 [项目符号列表，按规则去重。除非修复方式不同，否则跳过每个实例的详细说明。] ## 建议 - 可防止重发的架构/模式级别的变更。 - 值得引入的工具或组件抽象。 - 需要手动验证的内容（屏幕阅读器、键盘、低视力测试）。 ## 积极发现 代码库做得好的地方——简短、事实性、强化要保留的实践。在每个条目中包含规则 ID。对mechanical规则逐字引用Fix:指令。对于visual/contextual，留下带有规则 ID 的TODO；不要编造内容。
流程（修复模式）
- 基准。使用
name: "before"和format: "compact"进行审计。 - 规划 + 应用。对每个违规：
- 存在
Source:行 → 打开该文件的该行。如果列出了多个（用←分隔），第一个是 JSX 字面量；其余是包含组件。使用Symbol消除歧义。 - 无
Source:→ grep 稳定钩子（data-testid、id、aria-label），然后可见文本，然后树位置。 - 违规的
Fixability:和Fix:字段是权威的——逐字应用机械修复，对contextual/visual留下带有规则 ID 的TODO。绝不编造内容。 - 将同一文件的编辑合并为一次操作。
- 在触及明显目标之外的文件之前，或在进行约 10 次以上机械修复之前，与用户确认范围。
- 存在
- 验证。针对基准运行
audit_diff({ audit_name: "before" })（或使用新名称重新基准）。确认-fixed覆盖了你的目标，且+new为空。
Source:行来自 React DevTools fibers，仅出现在针对 React 开发构建的实时 DOM 审计中。静态审计不会有它们——回退到选择器。
当对规则不确定时，调用explain_rule({ id: "<rule-id>" })获取指导和browserHint。
何时退出（修复模式）
- 违规没有
Fix:指令——留下TODO，不要猜测。 - 验证失败（
+new中有任何内容，或目标规则未出现在-fixed中）——明确指出并停止。不要无声地迭代。
输出（修复模式）
每个周期：使用的流程、按影响分类的违规、已应用的内容（文件 + 规则）、已推迟的内容（TODOs + 原因）、最终差异。
限制
- 仅当任务明确符合上述范围时使用此技能。
- 不要将输出视为环境特定验证、测试或专家审查的替代品。
- 如果缺少所需的输入、权限、安全边界或成功标准，请停止并请求澄清。
