accessibility-inspect

これは、WCAG 評価における半自動の手動チェック項目です。操作（キーボード、フォーカス、状態変化、リフロー）や人によるレビュー（フォーカスの視認性、エラーからの回復、読み上げ順序）が必要で、静的なルールエンジンでは判定できないチェックを行います。実行中のページを対象にしてください。ソースは、検出事項を file:line に対応付けるためだけに使用します。検出と評価を行い、修正はしないでください（修正は accesslint:accessibility-fix の担当です）。自動チェック項目は accesslint:accessibility-scan です。accesslint:accessibility-audit は WCAG-EM に基づいて両方を実行します。

共通ルール（重大度、代替手段による判定の禁止範囲、高リスクパターン、適合性、根拠の提示）は、../shared/methodology.md に記載されています。判断が必要な場合は参照してください。常に適用されるルールは以下のとおりです。

評価

各検出事項に、重大度（ユーザーへの影響）と根拠の確度（裏付けられる内容）を付けてください。この2つは分けて扱います。

• ● 検証済み — 決定的で再現可能です。セレクター、操作、および確認されたアクセシビリティツリーまたは DOM の事実を示してください。その証拠がなければ、● ではありません。
• ◐ 要確認 — 根拠はありますが、判断には人が必要です。根拠と見解を添えてください。自分で結論を出してはいけません。
• ○ 人による確認が必要 — 支援技術または実体験が必要です。担当者に引き継ぎ、模倣しないでください。

根拠の確度を2段階のどちらにするか迷った場合は、低いほうを選んでください。アイコンは色ではなく、塗りつぶしで根拠の確度を示します。

決定的な事実と解釈を要する判断が組み合わさった検出事項には、低いほうの確度を適用します。機械で確認できる部分（例：アクセシビリティツリーにプログラムで認識可能なステータスがないという 1.3.1 の事実）は、◐ の検出事項に含まれる●の根拠です。解釈を要する結論（例：色だけが意味を伝えているという 1.4.1 の判断）は、◐ のままです。●の部分を示しても、検出事項全体の確度は上がりません。

重大度（ユーザーへの影響。根拠の確度とは別です）：

• Critical — 回避策がなく、主要なタスクが実行できません。
• Serious — 大きな障壁があります。タスクは可能ですが、困難です。
• Moderate — 無視できない不便がありますが、タスクは完了できます。
• Minor — 小さな非効率、または仕上げ上の問題です。

台帳 — スクリプトではなく分母

以下のチェックポイント領域が実行の分母です。各領域のすべての基準は、実行終了時に必ずいずれか1つの状態となり、レポートにはその状態が記載されます。

• ● 検証済み または ◐/○ 要確認 — チェックを実施し、根拠を得ています。
• N/A — 該当する機能がページにありません（フォーム、メディア、ドラッグ UI がないなど）。スナップショットから判断でき、追加コストはかかりません。
• 未実施 — 機能はありますが、チェックを実施していません。レポートでは 未確定 として扱い、黙って除外したり、合格としたりすることはありません。

未実施は正当で誠実な結果であり、コストもかかりません。ページの機能とエンジンの検出漏れに応じて、必要なチェックだけを実施してください。レポートを充実して見せるために、チェックポイントをひととおり実施する必要はありません。「未確定 — 未実施」の項目と、実施して検証済みの項目の違いは、誠実さではなく根拠の有無です。

重複排除は実施後ではなく、実施前に行ってください。エンジン（accessibility-scan）は、静的に検出可能な基準（名前／ラベルの有無、lang、autocomplete、セマンティックなマークアップ、平坦な背景上のテキストのコントラスト）を担当します。スキャン結果セットまたはエンジンが担当する SC リストが提供されている場合（accessibility-audit のように）、それらの基準を再チェックせず、台帳ではエンジン担当として記録してください。提供されていない場合は、エンジンが検出する内容を改めて調べるのではなく、初期スナップショットから確認できることを読み取ってください。

領域	SC	実施する条件
キーボードとフォーカス	2.1.1, 2.1.2, 2.4.3, 2.4.7, 2.4.11	常に実施 — まとめて1回の操作（下記）
構造とセマンティクス	1.3.1, 1.3.2, 2.4.1, 2.4.6	常に実施 — 初期スナップショットから確認し、追加操作は不要
名前、ロール、状態	4.1.2, 2.5.3, 4.1.3	カスタムウィジェット／状態を持つコントロールがある場合（静的な名前の有無はエンジン担当）
視覚的な適応	1.4.1, 1.4.4, 1.4.10, 1.4.12, 1.3.4, 2.3.3, 1.4.11	すべてのページでリフロー／ズームを実施（それぞれ1回リサイズ）。モーションのチェックはモーションがある場合のみ
フォームとエラー	3.3.1–3.3.3, 1.3.5, 3.3.7, 3.3.8	フォームがある場合（ラベル／autocomplete の有無はエンジン担当）
メディアとタイミング	1.2.x, 2.2.1, 2.2.2	<video>／<audio>、自動再生、またはタイムアウトがある場合
ポインターとターゲット	2.5.1, 2.5.7, 2.5.8	ターゲットサイズはまとめて行う操作で確認できるため追加コストなし。ドラッグのチェックはドラッグ UI がある場合のみ
コンテンツとナビゲーション	3.1.1/2, 2.4.4, 3.2.3/4, 3.2.6	lang とリンクの目的はスナップショットから確認。ページ間の一貫性は accessibility-audit が担当（ここでは未実施）

チェックポイントごとの手順と既定の評価については、references/checkpoints.md を参照してください。該当領域に詳細な手順が必要な場合、またはユーザーが詳細な確認（--deep：該当するすべての領域について、完全な手順に沿って実施）を求めている場合に確認してください。

根拠の予算 — 評価に応じて費用を制限する

不確実性を適切に扱うコストは、誤った確信よりも低く抑える必要があります。検出結果が到達できる評価によって、集める価値のある根拠の上限が決まります。

• ● — 根拠を一度だけ完全に収集：セレクター、インタラクション、DOM または a11y ツリーで確認した事実。すでに記録したインタラクションを繰り返さないでください。
• ◐ — 厳密な上限：セレクター1つ、スクリーンショット1枚（問題が視覚的な場合のみ）、あなたの意見、人が確認すべき点。そこで終了してください。◐ は、どちらの判断に傾いていても人が再評価するものです。根拠を増やしても ● に引き上げることはできず、コストが増えるだけです。
• ○ — 操作は一切行わない：機能上の能力、支援技術、すでに実施したフローを示してください。○ を「強化」するためにページを操作してはいけません。

前提条件：操作対象のブラウザー

この階層では、ブラウザー MCP（chrome-devtools（推奨）、playwright、または puppeteer）を使用します。どれも接続されていない場合は、静的チェックのみを実行し、それ以外は ○ の引き継ぎ事項として報告して、ユーザーに次のように伝えてください。

claude mcp add chrome-devtools npx -- -y chrome-devtools-mcp@latest

対象

$ARGUMENTS は、URL、accesslint.config.json のターゲット名、またはデフォルトのターゲットを使う場合は空です。--selector <css> はコンポーネントに範囲を絞り、--wait-for <css> は非同期コンテンツを待機します。

navigate_page には URL が必要なため、最初に解決します。

• URL の場合：そのまま使います。
• ターゲット名または空の場合：accesslint.config.json（および Git の管理対象外である accesslint.config.local.json のオーバーレイ）を読み込み、名前（または default）に対応する url を解決します。さらに、そのターゲットの waitFor と selector も取得します。
• 設定ファイルがない場合：URL を尋ねるか、npx @accesslint/cli init を提案します。

その後、URL に移動し、テストの前にゲート（--wait-for が指定されていればその値、そうでなければターゲットの waitFor）を待ちます。

効率的な操作

スナップショットは1回、その後は範囲を絞って読み取ります。 待機ゲートの後にページ全体のスナップショットを1回取得します。これは、構造、名前、ロール、状態、N/A の判断の根拠になります。状態が変わった後は、ページのスナップショットを再取得せず、evaluate_script でセレクターを指定して、変更されたウィジェットだけを読み取ります（または、そのサブツリーのスナップショットを取得します）。操作のたびにページ全体のスナップショットを再取得するのは、このティアで避けられるコストとして最大のものです。

キーボードでのフォーカス移動は1回にまとめます。 フォーカス位置ごとに press_key とスナップショットを繰り返すのではなく、1回の evaluate_script 呼び出しでフォーカスをたどります。タブ移動可能な要素の順序を算出し、各要素を順番に focus() して、位置ごとにコンパクトな JSON を返します。内容はセレクター、ロール／名前、document.activeElement による確認、:focus 時の計算済み outline／box-shadow、境界ボックス（これにより 2.5.8 も追加コストなしで確認できます）、および要素が固定表示／オーバーレイの矩形領域の下にあるかどうか（2.4.11）です。この操作の結果は決定的な DOM の事実であり、●の根拠として引用できます。

この操作で候補を見つけ、実際のキーイベントで動作を確認します。スクリプトによる focus() ではアプリの keydown ハンドラーが実行されないため、操作性（Enter／Space／矢印キー）とトラップに関する主張には、引き続き press_key が必要です。ただし、確認するのは操作で見つかった疑わしい箇所のみです。複合ウィジェット（roving tabindex、aria-activedescendant）、ハンドラーが Tab／Esc を捕捉する可能性のある要素、操作で到達できなかった要素を対象とします。●のキーボードトラップの指摘には、そのウィジェットで実際に Tab／Esc を押す必要がありますが、ページ上のすべてのウィジェットで押す必要はありません。

リスクの高いパターン

ドラッグ＆ドロップ、リッチテキストエディター、ツリービュー、データグリッド、カスタムコンボボックスやメニュー、カルーセル、トーストやライブリージョンを多用する UI では、ヒューリスティックによるチェックの信頼性が低くなります。APG パターンを明記し、確認できる範囲を検証（●／◐）して、残りは実行すべき支援技術の手順とともに○で引き継ぎます。エンジンのルールには explain_rule を、ウィジェットの仕様には APG を使います。

レポート

検証の根拠ごとに指摘をまとめ、重大度をインラインで示します。レポートの冒頭で台帳を締めくくり、分母に含まれるすべての SC がちょうど1つの区分に入るようにします。簡潔にまとめ、件数の後に SC 番号だけを並べます。未実施の SC は、共通する理由ごとにまとめ、各グループに括弧書きの句を1つ付けます。SC ごとに1行ずつ記載することは避けます。

レポートでは、不適合、注意点、引き継ぎに文字数を割きます。適合は台帳内の SC 番号だけで示し、「適合した内容」の説明は、あっても1文までにします。また、指摘で既に示した修正内容を推奨事項で繰り返さないでください。

# Manual inspection — <target>  ·  semi-automated tier
Severity: <c> critical · <s> serious · <m> moderate    Basis: ● <v> · ◐ <f> · ○ <h>
Ledger: pass ● <SCs> · fail ● <SCs> · flagged ◐/○ <SCs> · engine-owned <SCs> · N/A <SCs>
        not exercised → undetermined: <SCs (shared reason)> · <SCs (shared reason)>

## ● Verified
- [serious] Keyboard trap in date picker — SC 2.1.2
    where: div.datepicker[role=dialog]   repro: Tab into grid, focus never exits via Tab or Esc
    fix: <mechanical> | NEEDS HUMAN

## ◐ Flagged
- [moderate] Focus indicator may be too faint — SC 2.4.7
    where: button.ghost   evidence: focus-ghost.png; outline = 1px rgba(0,0,0,.2)
    opinion: likely fails 3:1 non-text contrast — confirm visually

## ○ Human-required
- Live-region announcement on add-to-cart — SC 4.1.3
    aria-live="polite" present (●); actual NVDA/JAWS/VoiceOver output unverified
    needs: screen-reader users (blind / low-vision, per Section 508 FPC)
    flow: add-to-cart → toast (exercised above)

各項目はセレクターと表示テキストを根拠とします。accessibility-scan のソースマップに記載がある場合に限り、file:line (symbol) を追加します。推測で記載してはいけません。各○の項目は引き継ぎです。必要な機能と支援技術、および実施した操作フローを記載します。

注記

• a11y ツリーが示すのは機械の状態であり、スクリーンリーダーが読み上げる内容ではありません。aria-live が存在していても、読み上げられるとは限りません。
• ブラウザーのズーム率は取得できません。CSS のズームによる近似は◐です。
• 初回のスナップショットを取得する前に、非同期コンテンツの読み込みを待ちます。それ以降はスナップショットを再取得するより、セレクターを指定した読み取りを優先します。
• ティアの組み合わせ（accessibility-scan との重複排除、共有ブラウザーの利用）は accessibility-audit の役割です。このスキル単体では、チェックで見つかった内容を報告し、見つからなかった内容を台帳に示します。