アクセシビリティレビュー - WCAG適合監査

アドバイザリーのみのアクセシビリティ監査です。QA - Web A11y Reviewerエージェントを派遣して、Webコンテンツを WCAG 2.2 レベル AA に照らして評価し、問題を実際のユーザーへの影響で優先順位付けし、修正を推奨します。変更は行いません。

理念

適合性よりも影響を優先。 スクリーンリーダーユーザーを阻むフォームラベルの欠落は、誰にも害を与えない冗長な ARIA ロールよりも重要です。この監査は、障害のある人々のアクセスを妨げたり低下させるバリアを優先します。

診断的であり、治療的ではない。 このスキルはアクセシビリティバリアを識別し、修正を推奨します。実装は行いません。調査結果を確認した後、直接変更をリクエストするか、監査をコンテキストとして /implement を使用してください。

ワークフロー概要

┌──────────────────────────────────────────────────────┐
│           アクセシビリティレビュー                    │
├──────────────────────────────────────────────────────┤
│  1. Webコンテンツを検出                              │
│  2. スコープを決定                                   │
│  3. アクセシビリティ監査者を派遣                      │
│  4. 監査レポートを提示                                │
└──────────────────────────────────────────────────────┘

ワークフロー詳細

1. Webコンテンツを検出

プロジェクトをスキャンしてWebコンテンツファイルを探します：

拡張子	コンテンツタイプ
.html, .htm	HTML ドキュメント
.jsx, .tsx	React/JSX コンポーネント
.vue	Vue コンポーネント
.svelte	Svelte コンポーネント
.css, .scss, .less	スタイルシート
.ejs, .hbs, .pug, .njk	HTML テンプレート

除外対象： node_modules/、vendor/、dist/、build/、.git/、その他の生成/ベンダーディレクトリ。

Webコンテンツが見つからない場合： 「このプロジェクトではWebコンテンツが検出されませんでした。アクセシビリティ監査は、HTML、CSS、またはUIコンポーネントファイルを含むプロジェクトに適用されます。」と報告して中止します。

2. スコープを決定

検出された Webコンテンツをファイルカウント付きでユーザーに提示します：

検出されたWebコンテンツ:
  - HTML: 12 ファイル
  - React (TSX): 28 ファイル
  - CSS: 8 ファイル

何を監査すべきでしょうか?
  - プロジェクト全体 (デフォルト)
  - 特定のディレクトリ (例: src/components/)
  - 特定のファイル

ユーザーの選択を受け入れます。デフォルト：プロジェクト全体。

3. A11y 監査者を派遣

Glob でスコープサイズを評価します。

小規模なスコープ (概ね ≤20 個の Webコンテンツファイル)： 完全なスコープを持つ単一の QA - Web A11y Reviewer エージェントを起動します。

大規模なスコープ (概ね >20 個の Webコンテンツファイル)： ディレクトリまたはコンポーネント境界でパーティション分割します。複数の QA - Web A11y Reviewer エージェントを並行に起動し、それぞれに焦点を絞ったパーティションを割り当てます。

各エージェントへのプロンプト：

以下のWebコンテンツをアクセシビリティの問題について監査してください。
スコープ: [パーティションまたは完全なスコープ]

スコープ内のすべてのファイルを読み、完全な監査を実行してください：
1. 自動化されたアクセシビリティツール (axe-core、pa11y など) を検出して実行
2. 自動化ツールが見落とす問題の手動検査
   (キーボードナビゲーション、セマンティック正確性、動的コンテンツ、
   ARIA の使用法、コンテンツの品質、メディア)
3. すべての問題を重大度別に分類 (CRITICAL / HIGH / LOW)

標準的な出力形式で、概要、重大度別の問題、ツール推奨を提示してください。

4. 監査レポートを提示

すべてのエージェント応答を収集します。複数のエージェントが派遣された場合、調査結果を単一のレポートにマージして、パーティション間に広がる問題を重複排除します。

統合レポートを提示します：

## アクセシビリティ監査レポート

適合対象: WCAG 2.2 レベル AA
方法: [自動化 + 手動 | 手動のみ]
スコープ: [監査対象の内容]
見つかった問題: N件 (X件が重大、Y件が高、Z件が低)

### CRITICAL（重大）
[すべてのエージェントからの統合された重大な調査結果]

### HIGH（高）
[統合された高リスク調査結果]

### LOW（低）
[統合された低リスク調査結果]

### ツール推奨
[該当する場合 — 自動化されたアクセシビリティテストを追加するための推奨]

### 推奨される次のステップ
[調査結果に基づいて：
- 重大/高リスク問題が見つかった場合: それらの修正を推奨し、
  HTML 変更で対応するもの、CSS 変更で対応するもの、
  JS 変更で対応するものを記載
- 重大な問題が見つからない場合:
  「重大なアクセシビリティバリアは見つかりませんでした」
- 自動化ツールが存在しない場合: axe-core または pa11y の追加を推奨]

このレポートはあなたの合成です。 複数のエージェントが派遣された場合、パーティション間のパターンを探してください (例: ラベルの欠落は孤立した事例ではなく、プロジェクト全体の習慣)。エージェント出力を単に連結しないでください。

エージェント調整

• すべての監査エージェントは並行実行されます (読み取り専用で独立)
• 統合レポートを提示する前に、すべてのエージェントの完了を待ちます
• エージェントが失敗またはタイムアウトした場合、レポートに失敗を記載して他の結果で続行します

中止条件

中止する:

• スコープ内で Webコンテンツファイルが検出されない
• Git リポジトリではない

中止しない:

• 自動化されたアクセシビリティツールが利用できない (手動監査で進める)
• マルチエージェント派遣で単一のエージェントが失敗 (失敗を報告、続行)
• 見つかった問題が少ない (「重大な問題なし」と報告 — これは有効な結果です)