audit

アクセシビリティを監査し、必要に応じて問題を修正します。

ユーザーの意図に応じてモードを選択

• レポートモード — 「コードベースを監査して」「src/components/をレビューして」「このページの問題点は？」「a11yレポートを作成して」。監査してレポートを作成します。ファイルは編集しません。
• 修正モード — 「Xのa11yの問題を修正して」「監査して修正して」「アクセシビリティに対応させて」「コントラストの修正が反映されたか確認して」、または違反レポートを渡して修正を依頼する場合。監査 → 編集 → 検証を行います。

判断に迷う場合は質問してください。ユーザーが監査だけを依頼した場合、修正モードを既定にしないでください。

メインスレッドのコンテキストコストが問題になる大規模な調査では、コンテキストを分離するためにTask（汎用エージェント）経由で呼び出せます。どちらの場合も手順は同じです。

フローの選択

フローは2つあり、優先順に記載しています。

1. audit_live — URLにはまずこちらを試してください。デバッグ可能なChromeを確保し（接続可能なものがなければ、ヘッドレスで自動起動します。ユーザー側での設定は不要です）、ライブDOMを監査します。1回の呼び出しで完了し、監査エンジンがコンテキストに入ることはありません。selectorで対象を1つのコンポーネントに絞り込み、wait_forで非同期コンテンツの読み込みを待機できます。
2. audit_html — 生のHTML文字列、ファイル（先にReadしてからaudit_htmlを実行）、または文字列にレンダリングしたJSXを対象にします。

URL以外を対象とする場合はフロー2を使用します。URLを対象とする場合はフロー1を使用してください。Chromeを起動できない場合（システムにChromeがなく、ダウンロードも無効な場合）は、ライブDOMの網羅性に限りがある旨を伝えたうえで、フロー2に切り替えてください。

ユーザーがすでに開いている認証済みセッションを監査する場合、別のフローは不要です。ユーザーにヘッド付きのデバッグ可能なChromeを起動してもらい（npx @accesslint/chrome ensure --headed）、そこでサインインしてもらってから、audit_live({ url, port })を呼び出します。独自にChromeを起動するのではなく、そのChromeに接続します。

対象範囲の扱い（レポートモード）

• ディレクトリパス — その中にある関連ファイルをすべて解析します。
• 複数ファイル — 指定されたファイルと、それらがインポートするファイルを解析します。
• URL — そのページを監査します。開発サーバーのURLの場合は、フロー1を使用します。
• 引数なし — 対象範囲を絞り込むようユーザーに尋ねます。コードベース全体の調査が適切なケースはほとんどありません。

レポートの冒頭で、対象範囲を明示してください。

アプローチ（レポートモード）

1. 対象を把握する。 Glob/Grepでコンポーネント、テンプレート、スタイルを列挙します。代表的なファイルを確認し、無差別にすべて開かないでください。
2. 可能であればライブ環境を監査する。 レンダリング済みのDOMでなければ分からない問題があります。上記のフロー選択手順を使ってください。
3. パターンを探す。 あるコンポーネントがルールに違反している場合、似たコンポーネントも同様に違反している可能性があります。ルールIDとコンポーネント群ごとにまとめ、同じ問題を30件、個別に列挙しないでください。
4. ユーザーへの影響を優先する。 重大、深刻な問題を最初に扱います。影響の小さい違反が同じルールに多数ある場合、多くは根本原因が1つです。
5. 調査中の呼び出しではformat: "compact"を使用します。 レポートで詳しく説明するルールに限り、詳細な出力を使ってください。
6. Source:行を信頼します。 Reactの開発ビルドを対象とするライブDOM監査では、DevToolsのfiberを通じて、各違反にSource: <file>:<line> (Symbol)が付与されます。セレクターをgrepする代わりに、ファイルの場所を示す情報として使用してください。ない場合は、安定したフック → 表示テキスト → ツリー上の位置の順に手掛かりを探してください。
7. 1回の監査で違反が約50件を超えた場合は、いったん止めて質問してください。 違反が200件あるレポートでは、具体的な対応につながりません。

エンジンが検出するのは、機械的に判定できる問題です。コンテンツの分かりやすさ、スクリーンリーダーでの読み上げの品質、キーボード操作の一貫性、複雑な視覚的コントラストについては、人による判断が必要です。推測で判断せず、確認が必要な項目として挙げてください。

レポート形式

# Accessibility audit — <scope>

## Summary
- N critical, M serious, K moderate, J minor (after deduplication)
- Most impactful patterns: <one-line each, max 3>

## Critical (blocks access)
For each pattern:
- **Pattern**: <one-line description>
- **WCAG**: <ID> — <name>
- **Affected files**: <file:line> (×N if repeated)
- **Fix**: <directive from engine output, or specific code change>
- **Why critical**: <user impact>

## Serious
[same shape]

## Moderate / Minor
[Bullet list, deduplicated by rule. Skip per-instance detail unless the fix differs.]

## Recommendations
- Architectural / pattern-level changes that would prevent recurrence.
- Tooling or component abstractions worth introducing.
- What to verify manually (screen reader, keyboard, low-vision testing).

## Positive findings
What the codebase does well — short, factual, reinforces practices to keep.

すべての項目にルールIDを記載してください。mechanicalルールでは、Fix:の指示を一字一句そのまま引用してください。visual／contextualでは、内容を創作せず、ルールIDとともにTODOを記載してください。

レシピ（修正モード）

1. ベースライン。 format: "compact" で対象を監査し、違反一覧（各ルール ID とセレクター）を記録します。これを修正前の一覧とします。
2. 計画して適用。 各違反について、次の手順に従います。
   • Source: 行がある場合 → 該当ファイルの該当行を開きます。複数の項目が記載されている場合（← 区切り）、最初の項目は JSX リテラルで、それ以降は囲んでいるコンポーネントです。Symbol を使って特定します。
   • Source: がない場合 → 安定したフック（data-testid、id、aria-label）を検索し、次に表示テキスト、最後にツリー上の位置を確認します。
   • 違反の Fixability: フィールドと Fix: フィールドを正として扱います。機械的な修正は記載どおりに適用し、contextual／visual の場合はルール ID を含む TODO を残します。内容を推測して補ってはいけません。
   • 同じファイルへの編集は、1 回の操作にまとめます。
   • 明らかな対象の範囲外にあるファイルに触れる場合、または機械的な修正が約 10 件を超える場合は、作業前にユーザーに対象範囲を確認します。
3. 検証。 同じ監査を再実行し、修正前の一覧と比較します。対象の違反がすべて解消され、新たな違反が発生していないことを確認します。URL の対象について、実際のベースラインに対する新規・修正済み・既存の違反を厳密に比較する必要がある場合は、目視で判断せず、スナップショットベースの accesslint:diff スキルを使います。

Source: 行は React DevTools のファイバーから取得され、React の開発ビルドに対するライブ DOM 監査でのみ表示されます。静的監査では表示されないため、セレクターを使って特定します。

ルールについて判断に迷った場合は、explain_rule({ id: "<rule-id>" }) を呼び出して、ガイダンスと browserHint を確認します。

中止する場合（修正モード）

• 違反に Fix: の指示がない場合は、推測せずに TODO を残します。
• 検証に失敗した場合（新たな違反が発生した、または対象の違反が残っている場合）は、その違反を明示して作業を中止します。黙って修正を繰り返してはいけません。

出力（修正モード）

各サイクルについて、使用したフロー、影響度別の違反、適用した内容（ファイル＋ルール）、保留した内容（TODO＋理由）、および修正前後の違反件数を記載します。