a11y-audit

アクセシビリティ監査

認証済みの対象

明示的に承認された認証済みスキャンを行う場合は、実行前に references/authenticated-scans.md を読んでください。対象ごとに、ストレージ状態のペアと URL／準備完了のアサーションを必須とします。状態ファイルを所持していることを根拠にアクセス承認を推測してはいけません。認証に失敗したら停止し、ログインページを対象の読み込み成功として扱わないでください。検出は引き続き未認証で行います。状態データをバージョン管理や成果物に含めないでください。

アーキテクチャ

このスキルは単一のレイヤーとして動作します。プロジェクト環境を読み取り、自動アクセシビリティツールを実行し、検出結果をコンプライアンス標準に対応付け、設定可能な形式で出力します。外部スキルへの依存は必要ありません。

プロジェクト固有の監査状態は、インストール済みスキルのディレクトリではなく、対象ワークスペースに保存します。既定のパス： ワークスペースのルートにある .a11y-audit/PROJECT_CONTEXT.md。このファイルが存在する場合は、出力モード、追加のコンプライアンス標準、課題トラッカーの設定、ルート一覧、カラーパレット、既存ドキュメントへの相互参照など、プロジェクト固有の設定に使用します。存在しない場合は、唯一の標準として WCAG 2.1 AA を使用し、出力モードを markdown として、それ以外は汎用の既定値を使用します。

このファイルの標準スキーマとして references/project-context-template.md を使用してください。最小構成と markdown+issues の例が記載されています。

適合する場合は、場当たり的な生成よりも同梱のヘルパーを優先してください。

• scripts/bootstrap-context.js は、簡単な入力からワークスペース内の .a11y-audit/PROJECT_CONTEXT.md を作成します。
• scripts/scan.js は、再利用可能な axe ベースのスキャンを実行し、Lighthouse の実行意図を任意で記録します。出力サイズを減らすには --summary を使用します（違反の詳細はすべて保持し、パス／該当なしのノードデータは削除します）。
• scripts/report.js は、scan.js の出力から Markdown レポートと JSON データファイルを生成します。WCAG エビデンスマトリックス、違反の集約、色のコントラストの詳細抽出を決定論的に処理します。
• scripts/discover.js は、大規模サイトのテンプレートグループを特定し、スキャン対象の代表ページを選択します。まず sitemap.xml を読み取り、次に HTML ナビゲーションのクロールにフォールバックします。テンプレートグループを含むスキャン計画と、scan.js ですぐに使える URL リストを出力します。検出は既定で同一オリジンに限定されます。サイトマップで宣言されたクロスオリジンの対象をユーザーが承認した後に限り、--allow-cross-origin-sitemaps を使用してください。 フラットなルート構造や不規則なルート構造では、パスの深さに依存せず、レビュー済みのルートグループマップを使用してください。このマップを作成またはレビューする場合は、references/route-grouping.md を読んでください。
• scripts/select-changed-surfaces.js は、プロジェクトが管理する明示的なソースプレフィックスマップを、検出済みの正確なグループに対応付けます。変更されたすべてのパスを安全に対応付けられる場合に限り、既存の計画を絞り込みます。スキーマ v2 のマップには、レビュー済みのソースからルートへの変換によって、すでに検出済みの同一オリジン URL が解決される場合、変更された正確なページを含めることもできます。それ以外の場合は代表サンプル全体を保持し、フォールバックの理由を記録します。この経路を設定またはレビューする場合は、references/changed-surfaces.md を読んでください。
• scripts/run-audit.js は、検出、選択、スキャン、レポート生成を構成するための単一の JSON リクエストを必要とする、外部エージェントシステムおよび CI ランナー向けのベンダー中立なプロセスアダプターです。この境界を設定する場合は、references/interoperability.md を読んでください。オプトインのターミナル JSON および終了ステータスのパイロット版を利用する場合は、--contract posix-json-v1 を選択する前に references/cli-contract.md を読んでください。

ネットワークとブラウザーのポリシー

リモート対象をスキャンする場合、クロスオリジンのサイトマップコンテンツを使用する場合、またはサンドボックスのオーバーライドを設定する場合は、事前に references/network-policy.md を読んでください。既定の Chromium サンドボックスを有効にしたままにし、追加の対象オリジンを明示的に承認してください。

依存関係

Node.js 22.12.0 以降が必要です。スキャンする前に node --version を実行してください。 サポート対象外のランタイムは、依存関係をインストールする前にアップグレードしてください。管理対象バンドルでは Puppeteer 25.16.0 が固定されています。ブラウザーキャッシュ、ダウンロードのスキップ、v3 への移行手順については、references/runtime-compatibility.md を参照してください。

scan.js には axe-core と puppeteer が必要です。次の順序でこれらを解決します。

1. スキルローカルの deps/ ディレクトリ（scripts/ と同じ階層）
2. 対象プロジェクトの node_modules/（および一般的なワークスペースのサブディレクトリ）
3. グローバルの npm モジュール

いずれかのパッケージがどこにも見つからない場合、scan.js はスキャナーの依存関係一式を自動インストールし、スキルローカルの deps/ ディレクトリにまとめて配置します。スキルローカルにある既存の Puppeteer が固定リリースと異なる場合も、このインストールが実行され、古い管理対象ブラウザーパッケージが置き換えられます。デフォルトのバージョンでは、コミット済みのロックファイルを使って npm ci を実行します。意図的に --axe-version を指定した場合は、コミット済みのマニフェストを書き換えずに、指定した両方のバージョンをインストールします。インストールはバックオフを挟んで最大3回試行し、npm audit と資金提供に関するネットワーク呼び出しは省略します。deps/node_modules/ ディレクトリは gitignore の対象です。

同じロックファイルでは、再利用可能な Action 用の http-server も固定されています。serve-path が設定されている場合、Action はローカルサーバーを起動する前に npm ci を完了し、その後、サーバーの準備完了を待つ時間の計測を開始します。レジストリへのアクセス時間が、サーバーの起動失敗として誤って報告されることはありません。

各試行のタイムアウトは、デフォルトで 120000 ミリ秒です。遅いランナーでは、--install-timeout-ms <milliseconds> または A11Y_AUDIT_INSTALL_TIMEOUT_MS で延長してください。タイムアウト時の診断には、依存関係のセット、経過時間、制限時間、設定項目が示されます。ゼロ以外の npm 終了コードは別個に扱われます。

scan.js は、不足している依存関係を自動インストールしたり、古いスキルローカルの Puppeteer を置き換えたりする場合があるため、そのインストール範囲がまだ承認されていない場合は、scan.js の実行前に許可を求めてください。ブラウザーのダウンロードも、その範囲に含めてください。

バンドルされたスキャナーがサポートするのは Puppeteer のみです。--browser はユーザーが制御するパッケージインストーラーではなく、固定オプションとして扱ってください。

バージョンの固定と差分の整合性。 axe-core のルールセットとブラウザーの動作はリリース間で変わるため、scan.js は axe-core と Puppeteer の自動インストールを検証済みバージョンに固定します（--axe-version <x.y.z|latest> では、意図的に axe-core のバージョンを上書きできます）。各スキャンは出力 JSON に解決された axe_version と browser_version を記録し、report.js は axe_version を監査 JSON に引き継ぎます。また、「前回の監査との差分」セクションでは、2つの監査で異なるバージョンの axe-core が実行された場合にその旨を示します。バージョン間のルールセットの差異を、サイトの修正やリグレッションとして示してはなりません。プロジェクトで解決された axe-core が依存関係の検索で優先された場合も、同じ方法でそのバージョンが記録されます。プロジェクトレベルで片方の依存関係だけを指定しても、不足しているパッケージのインストールは抑止されません。固定された一式がスキルローカルにインストールされ、まとめて使用されます。

プラットフォーム固有の参照資料

• Claude Code で実行している場合は、.claude/launch.json の処理と Preview ツールの使用方法について、references/claude-code.md を読んでください。
• Codex で実行している場合は、ワークスペース内の状態の処理と実行時の前提条件について、references/codex.md を読んでください。
• references/output-contract.md と references/output-schema.json の内容は scripts/report.js に組み込まれています。レポートスクリプトを変更する場合に限り、これらを読んでください。
• output_mode が markdown+issues の場合に限り、references/issue-trackers.md を読んでください。
• CI で定期的な監査を運用したい場合は、assets/ci/github-actions/accessibility-audit.yml から始めてください。アップストリームの Action は実際の利用者として動作を確認し、actionlint と zizmor で検証されています。検出はサイトマップを優先します。配信済みのビルドを discover-url からクロールする必要がある場合は、Action で discover-no-sitemap: true を設定してから、実装を対象リポジトリにコピーせずに入力を調整してください。プルリクエストの対象範囲を絞るには、ルートグループと所有権マップの例をコピーし、changed-base と changed-head を指定して、検出と選択の両方の成果物を保持してください。
• 安全なレビューと重複排除を行ってから実際のチケットを作成する必要がある場合は、scripts/plan-issues.js を優先して使用してください。

このスキルはソースコードを変更しません。 修正ツールではなく、監査ツールです。 検出事項は修正方法のガイダンスとともに報告されます。対応するかどうかはユーザーが判断します。

出力モード

このスキルでは、.a11y-audit/PROJECT_CONTEXT.md の output_mode フィールドで設定できる、3 つの出力モードをサポートしています。

モード	出力	用途
markdown	Markdown レポートのみ	人によるレビュー、ドキュメント
markdown+json	Markdown レポート + JSON データファイル	CI 連携、ダッシュボード、傾向の追跡
markdown+issues	Markdown レポート + イシュートラッカーのチケット	積極的な修正ワークフロー

初回実行時に .a11y-audit/PROJECT_CONTEXT.md で output_mode が設定されていない場合は、希望するモードをユーザーに尋ね、その選択を ## Output Configuration セクションとしてファイルに追記して保存してください。コンテキストファイルが存在しない場合は、references/project-context-template.md に従って既定のパスに作成してください。シンプルな生成ファイルで十分な初回のコンテキスト作成では、scripts/bootstrap-context.js を優先して使用してください。

markdown+json モードでは、レポートと同じ場所に、axe-core の生の結果、Lighthouse のスコア、証拠マトリックスを構造化データとして含む、付随ファイル audit-YYYY-MM-DD.json が出力されます。このファイルは機械可読形式で、CI パイプライン、ダッシュボード、傾向追跡ツールで利用できます。

markdown+issues モードでは、コンテキストファイルで追加の設定が必要です（Phase 6 を参照）。

回帰ゲート

現在の重大または深刻な基準違反をゼロにすることが合格基準の場合は、--fail-on major を使用します。このモードでは、現在のスキャン全体を評価するため、承認済みのベースラインで既存の重大な違反を抑制することはできません。中程度、軽微、およびベストプラクティスのみの違反は引き続き表示されますが、ブロック要因にはなりません。ベストプラクティスのタグが付いていても、WCAG、EN 301 549、Section 508、または認識されないタグも付いているルールの重大度は下がりません。ベストプラクティスのみと判定されるには、明示的な best-practice タグが必要で、それ以外のタグは axe の cat.* タグに限られます。

違反の影響度が不明な場合や、critical、serious、または影響度不明の axe incomplete 候補がある場合は、判定不能としてゼロ以外の結果を返します。moderate および minor の incomplete 候補は参考情報として扱われます。自動テストの合格はスキャン対象の範囲にのみ適用され、完全な適合を示すものではありません。

major モードでは、指定された URL が HTTP エラーを返すか、HTML 以外のレスポンスを返す場合、必要なカバレッジが不足していると判定されます。スキャナーはページエラーと判定不能なゲートを記録し、エラーペイロードを要求されたページとして監査することはありません。既存のモードでは、これまでどおりのレスポンス動作が維持されます。

エビデンスマトリクスでは、確認済みの違反が Fail として優先され、axe の incomplete 候補は自動テストの合格より優先されて Needs review となります。未解決の incomplete エビデンスがある基準について、条件なしの合格を表示しないでください。

既存のアクセシビリティ課題があるサイトでは、すべてかゼロかのゲートより、承認済みのベースラインを優先してください。

# Create a baseline only after reviewing the current findings.
node a11y-audit/scripts/scan.js \
  --urls http://127.0.0.1:3000/ \
  --write-baseline .a11y-audit/baseline.json

# Fail only when the current scan introduces a finding outside it.
node a11y-audit/scripts/scan.js \
  --urls http://127.0.0.1:3000/ \
  --baseline .a11y-audit/baseline.json \
  --fail-on new

スキャナーは、axe のルール、正規化したルート、正規化した axe ターゲットを基に各検出項目のフィンガープリントを生成します。ベースラインには axe-core のバージョンが記録されます。意図的に上書きしない限り、バージョンが一致しない場合は比較が停止します。CI でベースラインを自動更新しないでください。ベースラインの変更は、明示的な承認判断としてレビューし、コミットしてください。

---

パイプライン

アクセシビリティ監査は、6 つのフェーズで進行します。各フェーズは、次のフェーズで使用するデータを生成します。フェーズ 1〜4 は必ず実行されます。フェーズ 5 では、設定された出力モードに応じた出力が生成されます。フェーズ 6 は markdown+issues モードでのみ実行され、ユーザーによる明示的な確認が必要です。

ユーザーは部分的な実行を依頼できます。一般的なパターンは次のとおりです。

• 「クイックスキャン」：フェーズ 1〜2 のみを実行し、結果を会話内で要約します
• 「完全な監査」：フェーズ 1〜5 を実行し、設定されたモードに従って出力します
• 「課題付きの監査」：フェーズ 1〜6 を実行し、レポートに加えてトラッカーのチケットも作成します

フェーズ 1 -- 環境の調査

目的： スキャンの前にプロジェクトを把握します。

1. .a11y-audit/PROJECT_CONTEXT.md が存在する場合は読み込みます（基準、ルート、出力モード、ラベル）。存在しない場合は、scripts/bootstrap-context.js を使用するか、references/project-context-template.md から作成します。
2. package.json を読み込み、技術スタック、既存の a11y ツール、および利用可能なブラウザー自動化ツール（puppeteer / playwright）を確認します。
3. ルーター設定または HTML ファイルの glob から、スキャン可能な URL のリストを作成します。ページ数の多いサイト（ルートが 15 件を超える場合）では、ページをテンプレートグループに分類し、代表的なページを選定する scripts/discover.js を優先してください。フェーズ 2 に進む前に、スキャン計画をユーザーと確認します。
4. 開発サーバーにアクセスできることを確認します。起動方法のヒントを得るため、.claude/launch.json とプラットフォーム固有のリファレンスを確認します。アプリが想定と異なる URL で起動した場合は、稼働中の URL に切り替え、相違点を記録して、コンテキストファイルを更新します。
5. Node.js 22.12.0 以降であること、および不足している依存関係のインストール、古くなった管理対象 Puppeteer の置き換え、ブラウザーのダウンロードを実行する権限があることを確認します。

出力： 続行する前に、構造化された概要をユーザーに報告します。

フェーズ 2 -- 自動スキャン

目的： 稼働中のページに対して、自動アクセシビリティチェックを実行します。

前提条件： 稼働中の開発サーバー（またはユーザーが指定した本番環境の URL）。

axe-core スキャン

使い捨てのスキャンスクリプトを書く前に、同梱の scripts/scan.js を優先して使用してください。同梱スクリプトでまだサポートされていない動作がワークスペースで必要な場合に限り、アドホックなスクリプトを使用してください。

再利用可能なスキャナーは、次の処理を行う必要があります。

1. puppeteer と axe-core をインポートする
2. ヘッドレスブラウザーを起動する
3. 対象 URL ごとに、次の処理を行う。 a. ページに移動する b. ネットワークがアイドル状態になるまで待機する（waitUntil: 'networkidle0'） c. axe-core を注入する。node_modules/axe-core/axe.min.js から axe-core のソースファイルを読み込み、page.evaluate() で注入する d. 監査を実行する：page.evaluate(() => axe.run()) e. 結果の JSON を収集する
4. ブラウザーを閉じる
5. 生の結果を JSON に書き込む

実行例：

node a11y-audit/scripts/scan.js \
  --root . \
  --discover /tmp/a11y-discover.json \
  --output /tmp/a11y-scan.json \
  --summary

プロジェクトに合わせてください。 依存関係がフロントエンドのサブディレクトリにある場合は、--root にワークスペースのルートを指定してください。同梱スクリプトは、一般的なフロントエンドのパスをすでに確認します。それでも動作しない場合は、アドホックなスクリプトを使用するか、フロントエンドのディレクトリから直接実行してください。

よくある間違い： ES モジュールのプロジェクトで require() を使用しないでください。package.json で "type": "module" を確認してください。設定されている場合は、アドホックなスクリプトで import 構文と __dirname の回避策を使用してください。設定されていない場合は、require() を使用できます。

Playwright の代替手段： 同梱スキャナーが受け付けるのは Puppeteer のみです。別途スコープを設定した監査で既存の Playwright インストールを使用する場合は、プロジェクト内のアダプターを作成し、検証済みの同梱スキャナーの経路外であることを明記してください。インストール済みのスキルと固定されたマニフェストはそのまま維持してください。

Lighthouse スキャン

各対象 URL に対して Lighthouse CLI を実行します。

npx lighthouse <url> \
  --output=json \
  --output-path=stdout \
  --only-categories=accessibility \
  --chrome-flags="--headless --no-sandbox" \
  --quiet

JSON 出力を解析します。次の項目を抽出してください。

• categories.accessibility.score（0～1。100 を掛けてください）
• score !== 1 の監査項目（失敗または部分的に成功した監査）
• 各監査項目の description と details.items

Lighthouse を使用できない場合、または実行に失敗した場合（CI 環境でよく発生します）は、スキップし、その不足をレポートに記載してください。エグゼクティブサマリーと方法論には、CLI が見つからなかった、Chrome の起動に失敗した、または別のランタイムエラーが発生したために Lighthouse をスキップしたかどうかを明記してください。axe-core の結果だけでも、有効な監査として十分です。

スコープの制御

• デフォルト：フェーズ 1 で見つかったルートをスキャンします
• discover.js のスキャン計画が存在する場合は、--discover で計画を渡してください。レポートの方法論にサンプリング戦略が記録されます。
• ルートが 10 個を超え、discover の計画が利用できない場合は、どのルートをスキャンするか、またはすべてスキャンするかをユーザーに尋ねてください
• ユーザーは特定の URL リストを指定して、検出結果を上書きできます
• SPA の場合：ページを再読み込みせず、ルーター経由で移動してください（一部のルートは URL を直接指定しても動作しない場合があります）

結果の構造

各ページについて、次の項目を収集してください。

• url：スキャンした URL
• violations：axe の違反項目の配列。それぞれに id、impact（critical／serious／moderate／minor）、description、help、helpUrl、tags（WCAG 基準）、nodes（セレクターを含む影響を受けた要素）を含めます
• passes：合格したルールの数
• incomplete：完全には評価できなかったルール
• lighthouseScore：0～100（利用可能な場合）
• lighthouseAudits：失敗した監査の詳細（利用可能な場合）

フェーズ 3 — 規格の根拠とのマッピング

目的： 自動検出された問題を、設定された規格の達成基準およびプロジェクト固有の規格に対応付けます。

scripts/report.js が根拠マトリックスを決定的に処理します。 基準マトリックスは references/standards/ 内のデータファイルで、--standard <id> を指定して選択します。

• wcag21-aa（デフォルト）：WCAG 2.1 レベル A および AA の全 50 基準。 ADA Title II 最終規則および EN 301 549 V3.2.1 で引用されています。
• wcag22-aa：WCAG 2.2 レベル A および AA の全 55 基準（4.1.1 Parsing を削除し、2.4.11、2.5.7、2.5.8、3.2.6、3.3.7、3.3.8 を追加）。
• en301549：EN 301 549 V3.2.1 の第 9 条（Web）。European Accessibility Act に基づく整合規格です。WCAG 2.1 基準との一対一の対応関係に加え、条項番号を表示します。

.a11y-audit/PROJECT_CONTEXT.md の standards の値を対応する ID にマッピングし（例：WCAG 2.2 AA → wcag22-aa、主な規格が EN 301 549 の場合 → en301549）、--standard で渡します。スクリプトは axe のタグを達成基準にマッピングし、Markdown と JSON の出力にマトリックスを生成します。JSON には使用した規格が記録されます。マトリックスを手動で作成する必要はありません。

.a11y-audit/PROJECT_CONTEXT.md でこれら以外の追加規格（例：CAN-ASC-6.2）が指定されている場合は、二次マッピングを作成します。その規格が WCAG 基準に対応している場合は、自動検出された問題を相互参照します。公平性、組織的なプロセス、透明性など、WCAG を超える要件は、プロジェクトの既存の適合性文書を参照する手動レビュー項目として記載します。

フェーズ 4 — 手動チェックのガイダンス

目的： 自動化では検証できない項目について、自動検出された問題の優先度に基づいたチェックリストを作成します。

フェーズ 3 のマトリックスで「Manual」とされた WCAG 基準ごとに、テスト項目を作成します。テスト方法ごとに整理します：キーボード操作、スクリーンリーダー、目視確認、認知、時間と動き。

動的な優先順位付け： 固定のチェックリストは作成しないでください。フェーズ 2 の結果を活用して、手動での確認に注力します。

• axe が色のコントラスト違反を検出した場合は、目視確認の項目を優先します（SC 1.4.1、1.4.11、1.4.10、1.4.12、1.4.13）。
• axe が ARIA またはランドマークの違反を検出した場合は、スクリーンリーダーの項目を優先します（SC 1.3.1、4.1.3、3.3.1、3.3.2）。
• axe が見出しまたは構造の違反を検出した場合は、キーボード操作の項目を優先します（SC 2.4.3、2.4.7、2.1.1）。
• フォーム関連の違反が見つからなかった場合は、フォームのテスト（SC 3.3.3、3.3.4）の優先度を下げ、自動チェックに合格した旨を注記します。
• 時間に関する項目（SC 2.2.1、2.2.2、2.3.1）は、まったく自動化できないため、必ず含めます。

各チェックリスト項目には、WCAG 基準、テスト内容、テスト方法、重点的に確認するページ（自動検出された問題があるページを優先）を記載します。

.a11y-audit/PROJECT_CONTEXT.md に既存のテストガイドが記載されている場合は、手順を重複して記載するのではなく、そのガイドへの相互リンクを追加します。

フェーズ 5 -- 出力の生成

目的： 設定された出力モードに基づいて出力を生成します。

scripts/report.js を実行して、フェーズ 2 のスキャン出力から Markdown レポートと JSON データファイルを生成します。

node a11y-audit/scripts/report.js \
  --input /tmp/a11y-scan.json \
  --output-dir docs/accessibility/audits \
  --project-name "Project Name" \
  --runtime-url http://127.0.0.1:3000 \
  --expected-url http://localhost:3000 \
  --discover /tmp/a11y-discover.json

discover.js のスキャン計画を使用した場合は、--discover を渡します。これにより、テンプレートグループとカバレッジ率を記載した「サンプリング戦略」の小見出しが、レポートの方法論に追加されます。

--previous <prior-audit.json> を渡すと、修正されたルール、新しいルール、インスタンス数の変化、進捗の純増を示す「前回の監査との差分」セクションが生成されます。

このスクリプトは、references/output-contract.md と references/output-schema.json の仕様に従って、audit-YYYY-MM-DD.md と audit-YYYY-MM-DD.json を生成します。レポートスクリプト自体を変更する場合を除き、これらの参照ファイルを読む必要はありません。

report.js の実行後、出力を確認し、「手動テストの推奨事項」セクションにフェーズ 4 のガイダンスを記入してください（このセクションは、特定の検出結果のパターンについて推論が必要なため、report.js によってプレースホルダーが用意されています）。

.a11y-audit/PROJECT_CONTEXT.md で出力先を上書きできます。

定期実行またはオンデマンドの CI ジョブをユーザーが希望する場合は、ワークフローを一から作成するのではなく、assets/ci/github-actions/accessibility-audit.yml を対象のワークスペースに合わせて調整してください。 ベースラインの更新は CI の外で行い、Action の検出結果とスキャン成果物を保持して、ゲートに失敗した場合もレビューできるようにしてください。変更箇所の選択を使用する場合は、その選択成果物も保持してください。フレームワークの命名から所有者を推測しないでください。references/changed-surfaces.md とレビュー済みのマップを使用してください。

フェーズ 6 -- 課題の作成（条件付き）

目的： 検出結果について課題管理システムのチケットを作成します。出力モードが markdown+issues の場合にのみ実行します。

このフェーズにはユーザーの明示的な確認が必要です。 チケットを作成する前に、作成するチケットの件数と優先度をユーザーに示し、承認を求めてください。

トラッカーの設定、重複排除、優先度のマッピング、チケットの構成については、references/issue-trackers.md を読んでください。.a11y-audit/PROJECT_CONTEXT.md のトラッカー設定を使用してください。

---

検証

監査の完了後、以下の品質チェックを検証してください。

1. axe の結果の妥当性： 同じページで手動実行した axe DevTools ブラウザー拡張機能の結果と、違反件数を比較してください。件数は許容範囲内で一致する必要があります（axe のバージョンによって多少異なる場合があります）。

2. Lighthouse スコアの整合性： Lighthouse を実際に実行した場合は、Chrome DevTools で手動実行した Lighthouse の結果と比較してください。スコアの差は 5 点以内である必要があります。

3. 規格マトリックスの完全性： 設定されたエビデンスマトリックスに、想定される基準の件数が含まれていることを確認してください。wcag21-aa では 50 件、wcag22-aa では 55 件、en301549 では条項に対応付けられた 50 件です。基準に漏れがないようにしてください。

   このマトリックスは、エビデンスに基づくステータス報告として扱ってください。自動実行の結果が優れていても、多くの WCAG 基準は依然として手動で確認する必要があるため、完全な適合の証明として位置付けないでください。

4. レポートの構成： 必須セクションがすべて存在することを確認してください。Markdown ビューアーで表が正しく表示されることも確認してください。

5. JSON の妥当性（markdown+json モード）：JSON ファイルがエラーなく解析できることを確認してください。違反件数が Markdown レポートと一致する必要があります。

6. 課題の重複排除（markdown+issues モード）：スキルを 2 回実行してください。2 回目の実行では、重複チケットが作成されないことを確認してください。

7. 出力モードの保持： 初回実行後、出力モードが .a11y-audit/PROJECT_CONTEXT.md に保存され、次回の実行時に自動的に使用されることを確認してください。

8. 実行時 URL の調整： アプリが想定と異なるローカル URL で起動した場合は、レポートに不一致が記録され、コンテキストファイルに実際の作業用 base_url が反映されていることを確認してください。

---

このスキルでできないこと

• ビジュアルリグレッションテスト：実行間でスクリーンショットを比較しません。この用途には Percy、Chromatic、または BackstopJS を使用してください。
• PDF のアクセシビリティ：PDF ドキュメントのタグ付き構造、読み上げ順序、代替テキストを監査しません。
• 実機／AT テスト：ヘッドレス Chromium でのみ実行します。実際の iOS／Android 端末や実際のスクリーンリーダーを使ったテストはできません。フェーズ 4 では、このための手動チェックリストを生成します。
• コードの修正：検出結果を報告しますが、ソースコードは変更しません。
• VPAT の生成：Voluntary Product Accessibility Templates（特定の法的形式）は作成しません。
• ホスト型の継続的なモニタリング：スケジュール実行されるスキャンサービスやダッシュボードはありません。CI でのゲート設定には対応しています。リポジトリには、プッシュ／PR 時にスキャナーを実行し、すべての違反、または承認済みベースラインに含まれない検出結果のみを対象に失敗させられる複合 GitHub Action（.github/actions/scan）と、ワークフローのスターターファイル assets/ci/github-actions/accessibility-audit.yml が含まれています。アップストリームリポジトリでは、複合 Action をエンドツーエンドでテストし、ワークフローのセマンティクスとセキュリティのチェックを実行しています。markdown+json 出力モードでは、さらなるインテグレーションの構築に使える構造化データを提供します。
• サードパーティの監査：プロジェクト独自のフロントエンドのみを監査し、埋め込まれたサードパーティサービスは監査しません。