accessibility-fix

此技能用于修复无障碍违规：建立基线、编辑、验证。它只负责修复。若要查找问题，请使用 accesslint:accessibility-scan（单个页面，自动化）、accesslint:accessibility-inspect（单个页面，手动）或 accesslint:accessibility-audit（整个网站，WCAG-EM）；若要检查回归，请使用 accesslint:accessibility-diff。此处运行的引擎仅用于修复循环——修复前建立基线，修复后进行检查——而不是生成报告。

通用规范（以事实为准，绝不臆造内容）：../shared/methodology.md。

对于大型修复任务，通过 Task 运行以隔离上下文；步骤相同。

输入

• 问题清单（来自 accessibility-scan、accessibility-inspect 或 accessibility-audit，也可以直接粘贴）：直接应用清单；基线已建立。
• 目标（URL、配置中的目标名称、文件或目录）：先对其进行审核以建立基线，然后修复。

两者都未提供时，请询问要修复什么。不要在未获提示时扫描整个代码库。

选择流程（用于建立基线和验证）

1. 任意 URL 都使用 audit_live。它会确保有可调试的 Chrome（如果没有可连接的实例，会自动启动无头实例），并审核实时 DOM。使用 selector 限定范围，使用 wait_for 等待异步内容。实时 DOM 能捕获源码无法发现的问题。
2. 对原始 HTML 字符串、文件（先使用 Read 读取）或渲染为字符串的 JSX，使用 audit_html。

对于经过身份验证的会话，请让用户启动一个带界面的可调试 Chrome（npx @accesslint/chrome ensure --headed）并登录，然后调用 audit_live({ url, port }) 连接到该实例。

步骤

1. 建立基线。使用 format: "compact" 进行审核，并记录违规项集合（每项包含规则 ID 和选择器）。如果收到的是问题清单，则跳过此步。
2. 应用修复。针对每项违规：
   • 如果存在 Source: 行，打开该文件并定位到对应行。如果列出了多处位置（以 ← 分隔），第一处是 JSX 字面量，其余是外层组件；使用 Symbol 消除歧义。
   • 如果没有，则先搜索稳定的钩子（data-testid、id、aria-label），再搜索可见文本，最后检查树中的位置。
   • 使用 Fixability: 和 Fix: 字段：按给定方式应用 mechanical 修复；对于 contextual 或 visual 修复，留下包含规则 ID 的 TODO。不要臆造内容（替代文本、标签、链接文本）。
   • 将同一文件的编辑合并为一次操作。
   • 修改明显目标之外的文件，或进行约 10 项以上的机械修复之前，先确认范围。
3. 验证。重新运行同一项审核并与基线比较：所有目标违规都已消除，且没有新增违规。若要对 URL 进行精确的新增／已修复／原有违规对比，请使用 accesslint:accessibility-diff，不要凭目测检查。

Source: 行来自 React DevTools fibers，且只会出现在针对 React 开发构建的实时 DOM 审核中。静态审核不会包含这些行；此时请改用选择器。若不确定某条规则的含义，请使用 explain_rule({ id })。

何时停止

• 某项违规没有 Fix: 指令：留下 TODO，不要猜测。
• 验证失败（出现新违规，或目标违规仍然存在）：报告问题并停止。不要默默反复尝试。

输出

每个周期都要说明：使用的流程、按影响级别分类的违规项、已应用的修复（文件和规则）、延后处理的事项（TODO 及原因），以及修复前后的数量。