ultra11y

ultra11y — WCAG 2.2 AA を監査し、アクセシブルなマークアップを記述する

アクセシビリティに関して、自動化ツールが確認できるのは問題の一部にすぎません。ultra11y は役割分担によってこの問題に対処します。決定論的でインストール不要のエンジン（node scripts/ultra11y.mjs <command> — npm install もキーも不要。JSX/TSX パーサーはバンドルに組み込まれています）が、機械的な作業、つまり機械でチェック可能な不適合を検出し、それぞれを適切な WCAG 達成基準に結び付けます。そして実行中のコーディングエージェントが、判断基準そのもの（代替テキストの適切さ、文脈におけるリンクの目的、読み上げ順序）を、エンジンが収集した証拠から静的に判定し（verify --manual）、各判定を verify／check でゲートします。真にレンダリング済み DOMが必要な基準（算出されたコントラスト、フォーカスの可視性、ズーム／リフロー、ホバー時のコンテンツ）のみが scan 層（実際のブラウザーで axe-core を使用）の対象となります。人による確認は、必要に応じて行う任意の監督にすぎません。ゲートによって、ハルシネーションによる不適合が残るのを防ぎ、「適合」と黙って判定されることは決してありません。

ルールと基準を混同しないでください。 バンドルには静的チェックが 93 件含まれています。WCAG AA の達成基準は 55 件、RGAA の基準は 106 件です。複数のルールが 1 つの基準の根拠となる場合も、1 つのルールが複数のパックの基準に関係する場合もあり、ほとんどの基準はスキャンまたは判定が行われるまで未確定のままです。実行ごとのカバレッジを正直に示す唯一の方法は、グリッドに表示されるリアルタイムの根拠別集計（moteur + scan + agent に、未判定として名前が示された項目を加えたもの）です。「エージェントが判定する基準は 48 件」のような固定の約束ではありません。そのため GitHub のサマリーには、判定済みの少数項目に対する割合ではなく、decided/total が表示されます。

WCAG 2.2 レベル AA は、世界共通の中核です。 各国の規格であるフランスの RGAA、米国の Section 508、EU の EN 301 549 は、基準を WCAG に対応付ける、追加可能な規格パックです。--standard rgaa を追加すると、audit を含むすべてのコマンドとすべての出力が再構成され、検出結果などもすべて対象になります。--pack ./pack.json（または .ultra11yrc.json）を使えば、再ビルドせずに実行時に外部パックを追加できます。または、各国の規格を追加してください（references/standards.md を参照）。パックと、その具体的な実装ガイダンス（RGAA SocialGouv／etalab の適切／不適切なパターン）はAI に取り込めます。pack check でゲートすることで、架空の対応付けが通過しないようにします。references/packs.md と references/guidance.md を参照してください。

作業の大部分はあなたが担います。 WCAG 2.2 AA の 55 件の達成基準のうち、エンジンだけで判定できるのは3 件です。14 件はレンダリングされたページ（scan）を必要とし、38 件はエージェントが判定する必要のある判断事項です。そのため、エンジンで問題が見つからなくても、それは出発点にすぎず、最終判定ではありません。実際に作業するページは references/adjudication.md です。

基本ルール：

1. 不適合を捏造しない：すべての NC は、実在し、解決可能な要素を示します（check で検証します）。
2. まずネイティブ HTML を使い、ARIA は最後に使う。暗黙のセマンティクスを重複させてはいけません。
3. 適合も捏造しない：C も NC と同じように根拠を示します。citations[] には、基準を満たすと判断した収集済みの根拠を記載します。各アンカーは解決可能で、その基準について実際に提示された根拠から選ばれている必要があります。根拠がまったく提示されていない基準を C にすることはできず、manual のままです。読み取りが INCOMPLETE（evidenceComplete: false）だった基準も同様です。一部しか提示されなかった基準は、見た範囲で不適合と判定することはできますが、見ていない範囲まで適合と判断することはできません。また、判定者が決定した C をエンジンが決定した C と統合してはいけません。レポートでは別々に記載し、自動合格率には含めません。 3b. 提示されるのは母集団全体で、同じものは一度だけです。 根拠はコンテンツクラスごとに代表例を1つ示し、occurrences、その他のアンカーを示す alsoAt、出現する pages を含みます。キャプチャされた38ページにある887個のリンクは、異なる（テキスト、href）の組み合わせが97個です。代表例への判定はそのクラス全体への判定となるため、誠実な C を付けられます。また、その基準に該当するクラスの出現箇所なら、どの箇所を示す引用でも受け入れられるため、実際に開いた箇所を引用してください。
4. 未確定の項目は明示し、暗黙に適合扱いしない：AI エージェントはすべての 判断 基準を自ら判定します（verify --manual、ゲート付き）。一方、レンダリング 基準は scan に委ねます。対象範囲内の全ページで、その基準に関わるすべてのルールが実行され、何も検出されなかった場合、scan は C（decidedBy: "scan"）と判定します。ページのシグナルが1つでも不完全なら、判定せずにそのままにします。証明されていない基準は「手動で評価する」のままです。記録され、根拠が示された判定なしにステータスを付けてはいけません。これを期待ではなくゲートにするには、未評価の項目が残っていると check --in <audit.json> --require-decided は失敗します。また、--allow-undecided <file> には、本当に判定できない基準とその理由を指定します（しきい値ではなく、明示したリストです）。--require-decided=pages を指定すると、各ページのグリッドすべてに同じ基準を適用します。あるルートで不適合となった基準は実行全体では確定しますが、検出されなかったルートでは、誰の判定も付いていないままの場合があります。ページごとの成果物では、これが実際に評価される内容です。 出力された作業リストが正式なものです。 他のページでは基準の判定に至らなかったため、実行全体のステータスがすでに NC となっている基準が、意図的に含まれることがあります。その項目は重複ではありません。根拠に基づく判定を返すか、明示的な manual の理由を記載してください。全体集計で判定済みに見えるからといって、空欄のままにしてはいけません。
5. 基準は検索し、記憶に頼らないでください。 criteria [--standard <pack>] <id> — または MCP 経由の ultra11y_criteria — を使うと、基準の原文、番号付きテスト、および各テストで参照される用語集の定義が得られます。RGAA 8.3 は「ページに lang 属性が必要」という基準ではありません。2つの代替条件を持つテスト 8.3.1 であり、用語の意味は用語集で決まります。8.3.1 を読んだうえで引用する監査者の記述には根拠がありますが、記憶を頼りに引用するのは、参照を装った推測です。国の標準に照らして監査する前に、プランを実行してください（ultra11y_method）。適合と判断するために、まだ判定が必要な基準の数がわかります。RGAA の場合は、106件中104件です。references/mcp.md を参照してください。
6. 最終的にレンダリングされたセマンティック HTML が正しい必要があります。 エンジンが認識するのはソースだけです。コンポーネントライブラリ（DSFR/MUI…）や .vue／.svelte／.astro SFC では実際のマークアップが隠れるため、ソース監査が合格でも証明にはなりません。生成されたセマンティック HTML を検証してください。ゼロタッチの capture ハーベスターをインストールすると（render --setup）、テストでレンダリングされるすべてのコンポーネントが .ultra11y/captures にシリアライズされて監査されます。さらに audit --require-captures を使って、見落としがないようにゲートを設定してください。references/automation.md／rendered.md を参照してください。
7. 言語：ユーザーとの会話の言語に合った --lang を必ず指定してください。曖昧な場合はユーザーに確認してください。このフラグを指定しない場合、CLI は自動検出します（リポジトリの <html lang> → 有効な標準のデフォルトロケール → 英語）。これはスクリプト／CI 用のフォールバックであり、自分で --lang を指定する代わりにはなりません。
8. 技術トークンは、フランス語の文章中でも英語のままにします。 作成するフランス語の成果物（レポートの説明、PRD、トラッカーチケット、判定結果）では、属性名、要素名、ロール名とその値は文章ではなくコードです。翻訳してはいけません。aria-live は aria-live のままです（「live 領域」と訳さないでください）。tabindex、alt、role="alert"、ランドマークのロール名も同様です。エンジン独自のフランス語カタログもこの方針に従っています。これに合わせてください。規範となる標準の用語（「lien d'évitement」などの RGAA の表現）は、公式のフランス語表記のままにします。

リファレンスライブラリ

まずはドメイン知識を確認し、その後にツールを確認してください。目の前の質問に合ったものを読んでください。

アクセシビリティの知識
references/adjudication.md	エンジンから提示される52項目の基準をそれぞれどう判断するか — 判定ルール、NAが正当となる場合、確認事項
references/naming.md	アクセシブルネームの算出、2.5.3 ラベル・イン・ネーム、視覚的に隠すCSS、画像／SVG／図の命名
references/widgets.md	ARIA APGの複合ウィジェットパターン、キーボード操作の要件、フォーカス管理、SPAのルート変更、ライブリージョン
references/forms-and-errors.md	ラベルと説明、autocompleteトークンの一覧、エラーの特定／提案／防止、重複入力、アクセシブルな認証
references/structure.md	見出し、ランドマーク、リストとdl、シンプルな表と複雑な表、意味のある順序
references/media-and-motion.md	キャプション／音声解説／トランスクリプト、ポインタージェスチャー、ターゲットサイズ、画面の向き、リフロー、視差効果の低減
references/forbidden-patterns.md	15のアンチパターン：悪い例 → 理由 → ネイティブな修正方法 → 基準
references/focus-and-logic.md	担当するフォーカス／キーボード操作の基準と、その考え方
references/criteria.md	55項目の基準：レベル、自動化可能性の分類、エンジンのルール、パックの対応付け（自動生成）
references/rgaa-automation.md	RGAA 4.1.2：106項目の基準／258項目のテストのマトリクス（自動生成）、決定的なルール、候補シグナル、報告を控える方針
references/act.md	エンジンが検出できるよう測定されていることと、明らかに検出できないこと（自動生成）
ツールの実行
---	---
references/runbook.md	確実に実行する方法：唯一の手順、使用するトランスポートとその理由、合格にかかるコストを説明します。判定に費用をかける前にお読みください
references/claude-code-report.md	Claude Code の詳細な公開手順：レンダリングされた対象範囲、直接判定、敵対的検証、Markdown + HTML + ページごとのエビデンス
references/audit.md	監査の全プロセスと、規範的なページサンプル
references/judgment.md	判定と反証の作業リスト、判定用語、フェイルクローズ方式の統合
references/verify.md	check／verify のゲート
references/false-positives.md	指摘が誤りである可能性のある箇所と、反証方法
references/rendered.md · references/automation.md	生成された HTML、キャプチャ、フック、CI の監査
references/harnesses.md	実行環境：Claude Code、Codex CLI、OpenCode、AGENTS.md のフォールバック
references/orchestrators.md	ワークフローエンジン／GitHub 以外の CI からエンジンを実行する方法：ピン留め、6 ステップのパイプライン、終了コード、任意のトラッカー向け JSON チケットセット
references/ci.md	--format sarif|github：インライン PR アノテーション、コードスキャン、ジョブのサマリー
references/pages.md	ページスナップショットとページごとの基準グリッド（pages）、およびその正確性を保つためのルール
references/e2e.md	render --e2e：Playwright／Cypress の実行中にページを監査する方法
references/devtools.md	dev：開発中に表示するライブオーバーレイと、ページごとのダッシュボード
references/extension.md	ブラウザー拡張機能：サイドカーを通じて、表示中のページを監査
references/dynamic.md	scan 階層：ランタイム、プローブ、認証が必要なページ
references/scale.md	大規模なリポジトリに対する監査の絞り込み
references/fix.md · references/correction.md	リグレッションを起こさず、優先順位に沿って修正を適用する方法
references/prd.md	バックログ（Markdown）としての監査ブロック
references/tickets.md	バックログをチケットとして登録する方法：GitHub、GitLab、Jira、および適切な粒度
references/standards.md · references/packs.md · references/guidance.md	国別の標準、パックの作成、実装ガイダンス
references/mcp.md	ルールエンジンとしての標準：基準を暗記する代わりに検索して確認できます。番号付きテスト、定義する用語、修正方法、作業計画を参照できます。MCP ツールや std:// リソースとして、または同じデータを CLI から利用できます
references/methodology.md	ステータス、合格率、重大度、レポート形式
references/cross-file.md	--graph：インポートとファイル横断ルール
references/orchestration.md	判定フェーズを複数のサブエージェントに分散する方法

状況に応じて選ぶ

• 「Claude Code で詳細な監査レポートを作成する」 → アクティブな Claude セッションを監査担当として使い、レンダリング済みの基準と判定基準を確定し、その主張を検証してから、日付入りの Markdown レポート、印刷可能な HTML、根拠を示したページごとのドシエを公開します。 references/claude-code-report.md をお読みください。これは対話型の公開プロファイルです。最後に成果物一式を完成させてください。簡易サマリーは、以下の CI 分岐を参照してください。
• 「監査／コンプライアンスレポート」 → node scripts/ultra11y.mjs audit … --json を実行し、続けて report（統合表＋NC 基準ごとの 監査担当者適合ブロック。prd と tickets が使うものと同じブロック）、最後に check を実行します。references/audit.md をお読みください。
• 「ライブラリがレンダリングするコード（DSFR、MUI など）、.vue／.svelte／.astro の SFC、または誤検知を避ける」 → ソーステンプレートではなく、生成された HTML を監査します。最も簡単なのは、ゼロタッチの capture ハーベスター（render --setup）をインストールする方法です。テストでレンダリング済みのすべてのコンポーネントが .ultra11y/captures にシリアライズされます（自動取り込みされ、検出結果はソースコンポーネントに帰属します。render --coverage と audit --require-captures で見落としを追跡できます）。または render（ビルド→監査のレシピ、あるいは SSR スナップショットの --scaffold）を実行してから出力を audit し、計算済みのレンダリングには scan を使います。SFC ソースの検出結果には preliminary とフラグが付きます（scope.sourceTemplate の注記）。references/rendered.md をお読みください。
• 「コンポーネントの検出結果が誤っているように見える／誤検知がある」 → エンジンは、コンポーネントに関する誤検知の大半を自動的に抑制し（スロット／プロップから注入された名前、コンポーネントの子要素、動的バインディング、条件付き見出し）、SFC／ライブラリのソースに関する検出結果には preliminary とフラグを付けます。残りは verify --apply で確認または反証します。references/false-positives.md をお読みください。
• 「大規模リポジトリ／効率よく監査する」 → --changed（git diff）、テンプレートの優先順位付け、重複排除、--max-files を活用します。references/scale.md をお読みください。
• 「ファイル間分析（ツリー＋依存関係）、実際の AST としての JSX／TSX」 → audit --graph はインポートを解決し、ファイルをまたぐルール（名前なしで使われているアイコンのみのコンポーネント、別ファイルにあるアンカーターゲットなど）を適用します。ブラウザーは不要です。references/cross-file.md をお読みください。
• 「修正用 Markdown／PRD を生成する」 → prd（report の NC セクションでレンダリングされるものと同じ監査担当者適合ブロック――有効な標準の語彙に沿ったテーマ／基準／テスト／WCAG＋レベル／検出結果／期待される状態／検証方法――をバックログとして出力します）。--split criterion、製品要件ドキュメントには --format doc、従来の開発バックログには --format remediation を指定します。Markdown のみを書き出します。references/prd.md をお読みください。
• 「この件のチケット／課題を作成する（GitHub・GitLab・Jira）」 → tickets は監査結果を読み込み、登録する独立したコマンドで、Markdown は書き出しません。--grain でチケット 1 件の単位を指定します。基準ごと（デフォルト）、ページごと、ページ＋基準ごと、ファイルごと、または全件をまとめた 1 件です。完全一致するタイトルで重複排除されるため、再実行しても重複しません。必ず最初に --dry-run を実行してください。references/tickets.md をお読みください。
• 「標準パックを導入または作成する（RGAA など）、外部ルールを AI に取り込む」 → --pack／.ultra11yrc.json で実行時に読み込み、pack check でゲート（ハルシネーション対策のガードレール）を設定し、pack scaffold で作成を開始します。具体的な実装前後の指針が検出結果／PRD に付加されます。references/packs.md と references/guidance.md をお読みください。
• 「判定基準を裁定する（判定フェーズ）」 → verify --manual --in audit.json は裁定用作業リスト（ADJUDICATE.todo.json＋ADJUDICATE.md）を出力します。未解決の基準ごとに 1 項目があり、エンジンが収集した根拠（すべての代替テキスト、リンクテキスト＋コンテキスト、文字どおりの色の組み合わせ、コントロールのラベル、見出しのアウトライン、ARIA の状態、tabindex、部分の言語）が事前に読み込まれています。AI エージェントが各 verdict を入力します。C／NA の場合は justification、NC の場合は根拠を示せる検出結果、manual の場合は reason が必要です。その後 verify --apply … --in audit.json で取り込み、FAIL-CLOSED で確定します。references/judgment.md をお読みください。
• 「裁定／検証する項目が多い（裁定をサブエージェントに分担する）」 → orchestrate --run <dir> は、実行時の最新の作業リストをもとに、準備ができたフェーズごとの起動可能なマルチエージェントワークフロー、agents/<role>.md のディスパッチ契約、順次実行用の RUNBOOK.md を出力します。サブエージェントに対応したハーネスでのデフォルトの実行方法です。以下の Orchestration — harness ごとのルーティング を参照してください。
• 「フォーカス、キーボード、インタラクションロジック（インタラクションロジック部分）」 → エンジンは、フォーカス順序／可視性／トラップ、およびフォーカス時／入力時の基準を未解決のリスクとしてマークします。AI エージェントがコンポーネントのソース全体を読み、キーボード／フォーカスの動作を裁定します（可視フォーカスとその他のレンダリング済み基準は scan に渡します）。references/focus-and-logic.md をお読みください。
• 「修正を適用する」 → fix（デフォルトはドライラン。--write を指定すると安全なコード変換を適用し、それ以外は何もでっち上げずに提案します）。references/fix.md をお読みください。
• 「優先度順に修正し、リグレッションを防ぐ（修正フェーズ）」 → fix（--write、--iterate）と prd バックログを使い、blocking→major→minor の順に進めます。references/correction.md をお読みください。
• 「リポジトリの自動ゲート（フック／CI）」 → init --hook は、ステージ済みの厳密なスナップショットを対象とする git pre-commit ゲートを書き出します（正確なインデックスの blob を監査し、安全な修正を自動適用して再ステージし、判定上の問題のみでブロックします）。init --baseline／--ci は、任意で有効にできる「新たな不適合のみをブロックする」方式です。Claude Code プラグインとしてインストールすると、3 つ目のゲートで、保留中の commit／push／PR に対して review-a11y スキル（エンジンだけではありません）を実行します。これはプラグインに含まれるもので、init では提供されません。ライブラリ／SFC のコードでは、レンダリング済みの captures（render --setup）をコミットしてステージし、実際のセマンティック HTML をチェック対象にします（audit --require-captures）。references/automation.md をお読みください。
• 「ページの構築中に問題を表示する」 → dev --next は 1 行のオーバーレイコンポーネントを書き出し、dev はループバックのサイドカーを起動します。フローティングパネルに現在のページの不適合が一覧表示され、それぞれをクリックするとエディターで該当する file:line が開きます。また、ページを閲覧するにつれて http://127.0.0.1:4111 にページごとのグリッドが蓄積されます。開発時以外には何もレンダリングしません。references/devtools.md をお読みください。
• 「E2E テスト中にページをチェックする」 → render --e2e は Playwright／Cypress のフィクスチャを書き出し、テストを終えた時点の状態（ログイン済み、フォーム入力済み、モーダル表示中）でページを監査します。これは別途実行する scan では得られない状態です。また、チェックした各ページをスナップショットとして保存します。failOn でテストをゲートします。failOn: false は失敗させずに記録する設定で、既存のバックログに導入する際に使います。references/e2e.md をお読みください。
• 「コンポーネントではなく、実際のページを監査する」 → ページスナップショット（.ultra11y/pages/<id>/）には、レンダリングされたドキュメント全体と、ブラウザーでのみ得られる情報（計算済みスタイル、ボックス、a11y ツリー、スクリーンショット）が含まれ、audit に自動で取り込まれます。完全なドキュメントであるため、ページスコープのルールを適用できます。RGAA 8.3（lang）、8.5／8.6（title）、12.6 の判定が可能になるのは、ここだけです。references/pages.md をお読みください。
• 「CI でブラウザーを使わずにレンダリング基準を判定する」 → ページスナップショットがあれば、レンダリング済みティアが通常の audit の中で実行されます。計算済みスタイルのコントラスト（RGAA 3.2／10.5）、グラデーション／画像上のテキストのスクリーンショット測定によるコントラスト（axe-core にもある CSSOM の死角）、色だけに依存したリンクの識別（RGAA 10.6、以前は判定不能）をチェックします。測定できない場合は各基準を推測せず manual のままにします。references/pages.md をお読みください。
• 「RGAA のグリッドをページごとに確認する」 → pages --in audits/audit-latest.json --standard rgaa（report にも組み込まれています）：基準ごとに 1 行、ページ URL ごとに 1 列の表を、コミット済みの audit.json のみから再構築します。次の 2 つのルールがあります。検出結果は、ページに該当すると明記されている場合に限りページに帰属し、明記されていなければ帰属先不明として報告し、他のページに割り振ることはありません。また、黙っていることで C と判定されるのは、実際の DOM を監査したページに限られます。ソースのみのページでは、未判定の基準は « à évaluer » のままです。references/pages.md をお読みください。
• 「マトリックスではなく、ページごとのレポートが欲しい」 → pages --in audits/audit-latest.json --standard rgaa --format report --split page --out audits/pages：ページごとに 1 件のドシエを出力します。ページの識別情報、スクリーンショット、適合率、そのページでの全基準のステータス、続いて各不適合を通常の監査担当者ブロックで記載します。再判定は行わず（グリッドと同じ投影）、新しい形式も作りません（report と同じ監査担当者ブロック）。そのため、ページシートとコンプライアンスレポートが食い違うことはありません。ほかのレポートと同様、check で基準の捏造をチェックします。references/pages.md をお読みください。
• 「そもそも、どのページを監査すればよいか」 → pages discover --crawl http://localhost:3000 --write（または --sitemap <url>）を実行すると、各ページの配信された <title> から名前を取得し、既に宣言されている auth／storageState／notes を上書きせずに、sample.pages ブロックを書き出します。続いて sample check でカバレッジを検査し、scan --sample でスキャンとスナップショット作成を行います。クライアント側でレンダリングされる SPA は、配信された HTML にルートを公開しません。その場合はサイトマップを使ってください。references/dynamic.md をお読みください。
• 「CI で URL をページごとに監査する」 → 提供されている Action は urls、sitemap、crawl、または sample を受け取り、アクセスしたすべてのページのスナップショットを作成し、各ページの各基準のステータスをジョブサマリーと audits/pages-status.md の両方に書き出します。ステータスのみのパッケージには pages-report: compact を指定します。この場合、Markdown、ページ JSON、ソース監査、判定台帳のみが含まれます（裁定用作業リスト、修正レポート、HTML、クロップは含まれません）。詳細なページドシエも必要な場合は、デフォルトの true のままにします。プルリクエストにも同じグリッドを表示する場合は、pages／full の PR コメントをリクエストしてください。references/ci.md をお読みください。
• 「判定基準を裁定する人がいない」 → judge --in audits/audit-latest.json --standard rgaa [--apply] は、実行ループにコーディングエージェントがいない場合（CI、拡張機能、E2E 実行）にモデルで裁定します。これは呼び出し元であり、2 人目の判定者ではありません。同じ作業リスト、同じ根拠、同じプロンプトを使い、判定結果にはユーザーの場合と同じ fail-closed ゲートが適用されます。API キーを使う場合は --runner api、ローカル CLI の既存のサブスクリプションログインを使う場合は --runner claude|codex を指定します（--runner cli は引き続き Claude のエイリアスです）。エージェント内では verify --manual を使い、自分で作業リストを裁定してください。references/judgment.md をお読みください。
• 「赤いジョブにするだけでなく、検出結果をプルリクエストに表示する」 → --format sarif（コードスキャンにアップロードし、該当する file:line にインライン注釈を表示）または --format github（::error:: ワークフローコマンド＋$GITHUB_STEP_SUMMARY の表）を指定します。WCAG ではなくパックの基準が必要な場合は、report --standard rgaa から実行します。references/ci.md をお読みください。
• 「このコードをアクセシブルにする／レビューする」 → スニペットを監査します（audit - < component.html）。ネイティブ対応を優先します。references/authoring.md と references/forbidden-patterns.md をお読みください。
• 「基準 X の意味を知りたい」 → criteria を使います（例：criteria 1.4.3、または criteria --standard rgaa 8.3）。references/criteria.md を参照してください。
• 「特定のチェックの信頼性はどの程度か／エンジンが検出できないものは何か」 → エンジンは W3C ACT-Rules テストコーパス（サードパーティーの例約 1,100 件）でスコア化されています。どのチェックが一貫しているか、再現率が部分的なのはどこか、意図的な相違はどれか、静的に判定可能でありながら未対応のルールはどれかを確認できます。references/act.md をお読みください。裁定に進む前に、基準のどの程度をエンジンが実際に判定できるかを把握するために使ってください。
• 「国別標準（RGAA、Section 508、EN 301 549）」 → report／prd／criteria／check／verify に --standard <pack> を指定します。references/standards.md と references/methodology.md を参照してください。国別標準の監査では、デフォルトでスキャンを提案してください。この種の監査は、宣言されたページサンプルに対して規範上定義されており、スキャンしていない --standard rgaa レポートは partial とマークされます。完全なカバレッジがあるかのように示さず、その旨を伝えてください。サンプルのワークフロー（sample check、scan --sample、--merge）は references/audit.md に記載されています。
• 「高保証の監査」 → verify --report … --semantic を使います。references/verify.md を参照してください。
• 「コントラスト／レンダリングをチェックする（動的ティア）」 → scan <url> --merge … はヘッドレスブラウザーで axe-core を実行します。ローカルのランタイムでは、フォーカスの可視性、200％ズーム、テキスト間隔、ホバー時のコンテンツも、状態変化を伴う範囲限定のインタラクションおよび認証済みページで調べます。references/dynamic.md をお読みください。
• 「needs-rendered-dom になった基準を確定する」 → より優れたモデルが必要だったのではなく、ブラウザーが必要だったということです。scan は、測定した内容をスナップショットと併せて保存します（probes.json、axe.json）。そのため、ズーム、リフロー、Tab キーでの移動を実施したページは、「à évaluer」ではなく 適合と判定される場合があります。RGAA 3.2／3.3／10.4／10.11／10.12 は測定に基づいて確定し、10.1／12.8 は実際の DOM から裁定できるようになります。verify --manual は無駄な判定作業に入る前に警告し、check --require-rendered はレンダリングされていない場合に拒否します。クロールはデフォルトで上限なし（--max 0／--depth 0）で、アクセスするすべてのページを通知します。references/dynamic.md と references/pages.md をお読みください。

オーケストレーション — ハーネスに応じたルーティング

判定フェーズは並列処理に対応しています。ADJUDICATE.todo.json（残存する各基準につき1項目）と VERIFY.todo.json（NC の各主張につき1エントリー）は項目ごとに独立した作業リストであり、 orchestrate --run <dir> は、現在存在する作業リストをもとに、実行可能なワークフロー、ロールごとのディスパッチ契約、 順次実行する RUNBOOK を生成します。並列処理は最適化であり、必須ではありません。ゲートはハーネスに依存せず、すべてのフェーズに同じアーティファクトを生成する順次実行のフォールバックがあり、フェイルクローズする verify --apply の集約は常にあなたが行います。ルーティング表とルールについては references/orchestration.md を参照してください。

コマンド早見表

全機能は --help に記載されています。ここでは、よく使うコマンドを紹介します。

node scripts/ultra11y.mjs audit "src/**/*.tsx" --graph --out audits --json   # the default audit (AST + cross-file, persisted)
node scripts/ultra11y.mjs audit - < component.html                           # a snippet via stdin
node scripts/ultra11y.mjs audit --changed --json                             # only the git diff (large repo)
node scripts/ultra11y.mjs audit --staged --fail-on blocking                  # gate EXACTLY the staged snapshot (pre-commit)
node scripts/ultra11y.mjs audit "dist/**/*.html"                             # the RENDERED HTML (reliable for DSFR/MUI…)
node scripts/ultra11y.mjs render --setup                                     # install the capture harvester (tests → .ultra11y/captures)
node scripts/ultra11y.mjs audit --require-captures                           # gate the components with no rendered capture
node scripts/ultra11y.mjs scan http://localhost:3000 --runtime local --cwd . --merge audits/audit-latest.json
node scripts/ultra11y.mjs check --in audits/audit-latest.json --require-rendered              # gate: a rendering criterion left open by a run that rendered nothing
node scripts/ultra11y.mjs pages --in audits/audit-latest.json --standard rgaa --json --out audits  # the per-page grid, for a machine (audits/pages.json)
node scripts/ultra11y.mjs verify --report audits/wcag-YYYY-MM-DD.md --in audits/audit-latest.json --manual --out audits
node scripts/ultra11y.mjs verify --apply audits/ADJUDICATE.todo.json --in audits/audit-latest.json --out audits
node scripts/ultra11y.mjs orchestrate --run audits                           # fan the judgment phases out (--eco for the sequential path)
node scripts/ultra11y.mjs report --in audits/audit-latest.json --out audits  # → audits/wcag-YYYY-MM-DD.md
node scripts/ultra11y.mjs prd     --in audits/audit-latest.json              # the same auditor block as a backlog
node scripts/ultra11y.mjs tickets --in audits/audit-latest.json --dry-run    # file it: GitHub/GitLab/Jira
node scripts/ultra11y.mjs check  --report audits/wcag-YYYY-MM-DD.md          # integrity gate
node scripts/ultra11y.mjs criteria 1.4.3                                     # one success criterion (--list for all)
node scripts/ultra11y.mjs fix "src/**/*.html" --write --iterate               # apply the safe codemods to a fixpoint
node scripts/ultra11y.mjs init --hook                                        # pre-commit gate (--baseline for the regression variant)
node scripts/ultra11y.mjs pack check ./packs/section508.json                  # gate an (AI-)authored standards pack

--standard rgaa は audit にも指定でき、その後はすべて RGAA に準拠した出力になります。 audit／scan／fix だけでなく、report／prd／tickets／criteria／check／verify／judge にも適用されます。また、.ultra11yrc.json { "standard": "rgaa" } を設定すると、これらすべてのコマンドで既定値になります。この場合、audit はテーマ別に表形式でまとめた RGAA の見出し付きサマリーを出力し、検出事項には [3.1.1] ではなく [8.4] のように、パック固有の言語でタグを付けます。--json と --out は、パイプライン用に core 内に WCAG の中核情報を含む、パックをキーとしたドキュメント（106 基準、13 テーマ）を書き出します。また、CI アノテーション、SARIF、レポート、PRD、ページごとのシートでは RGAA 基準のみを表記し、パックの成果物内に WCAG との相互参照は一切含まれません。エンジンは内部で引き続き達成基準をキーとして処理します。これは、パック基準が達成基準の投影として定義されているためです。これは内部の仕組みであり、読者の目に触れることはありません。--pack ./pack.json を追加すると、実行時に標準を読み込めます。また、機械可読な出力にはどのコマンドでも --json を指定できます。 --lang は会話の言語に従います（明示的に指定してください — Core rule 7）。

ループ：audit → render → judge → fix → 再監査

一度の実行で終わらせず、適合に向けて収束させるには、エージェントに判定とコンテンツの各段階を進めさせながら、手順をつなげます。

1. ソースを audit … --graph で監査して、最初のマップを作成します。ライブラリによってレンダリングされるコードでは、信頼できる判定を行うために、レンダリング結果を監査します（render → build/SSR → audit）。そうしない場合は、スコープリスクの注記でその旨が示されます。 1b. 判定する前にレンダリングしてください — レンダリング基準が未確定の場合、この手順は必須です。 scan <url|file> --runtime local --merge audits/audit-latest.json --out audits （または scan --sample）を実行すると、実際のブラウザーが起動し、測定内容（probes.json、axe.json）とともに各ページが .ultra11y/pages/<id>/ に保存され、監査結果に取り込まれます。この手順を省略しても、該当基準が単に未確定のままになるわけではありません。誰にとっても判定不能になります。ソースを読んでも、計算後のコントラスト、200 % のズーム、320 px でのリフロー、テキスト間隔は確定できないため、これらの基準を判定するたびにモデルのコストが発生し、needs-rendered-dom が返されます。2 ファイルのフィクスチャで実施した RGAA の実行例では、ソースだけから判定する基準は 80 件、1 ページをスキャンすると 41 件でした。そして、3 パスで $24.90 のカスケードが保留した 7 件のうち、6 件は測定によって確定しました。verify --manual は、何かを消費する前にこのことを通知するようになりました。また、check --in <audit.json> --require-rendered で必須条件にできます。
2. verify を使って判定と反証を行います。ワークリストは 2 種類あります。（a）verify --manual --in audit.json は ADJUDICATE.todo.json を出力します。これは、エンジンが収集した証拠をあらかじめ読み込んだ、残りの判断基準ごとの項目で、AI エージェントが判定します（C／NC／NA、または本当に needs-rendered-dom の場合は reason を指定した manual）。各判定には justification または根拠を示せる所見が含まれます。verify --apply … --in audit.json はそれらを FAIL-CLOSED 方式で取り込みます（エージェントが出した NC は実際の agent:<sc> の所見となり、§2 で再レンダリングされます）。（b）verify --report … [--semantic] は VERIFY.todo.json を作成し、両方向から検証します。レンダリングされた DOM によって否定された preliminary／SFC／ライブラリソース由来の不適合を反証します。また、判定台帳が存在する場合（これがデフォルトです）は、台帳でエージェントが判定した適合も検証対象にします。引用ごとに 1 項目を作成し、問いを逆にします。この証拠は基準を満たすことを立証しているのか、それとも対象が存在することしか示していないのか？ C に異議を唱える検証がなかったため、対象が正しいからではなく存在するからという理由でクリアされた基準が、適合の主張として出荷されていました。判定結果は同じです（supported／partial／refuted／unsupported）。verify --apply は反証済み／裏付けのない不適合を取り除き、反証された適合の基準を « 評価対象 » に戻します。適合を反証しても基準に対する反証にはならないため、NC にはしません。オプトアウトするには --no-conformities を指定します。これにはフォーカスとインタラクションのロジック（コンポーネントのソース全体を確認してください。キーボード操作、フォーカス順序／可視性、トラップ、フォーカス時／入力時の変更については references/focus-and-logic.md を参照）と、references/false-positives.md に記載されたルールごとの注意点も含まれます。どちらのワークリストも分散実行できます（orchestrate --run <dir> --phase adjudicate|verify-report — オーケストレーション — ハーネスに応じた振り分けを参照）。--apply による取り込みは常にユーザー自身が行います。 各基準は、記憶ではなく、その基準自身の文面に照らして判定してください。 verify --manual は、基準の公式文面、番号付きテスト、国別規格の場合はその規格独自のテスト方法（RGAA は 258 件すべてのテストについて公開しています）、さらに用語集の用語、技術注記、個別のケースを含む、基準ごとの簡潔な説明も出力します（adjudicate/<criteriaId>.md）。この説明を読んでください。--standard rgaa の場合、判定基準となるのは RGAA であり、その背景にある WCAG 達成基準ではありません。各説明には基準の公式ページも記載されています。文面が曖昧なままで、ウェブツールが使える場合は、そのページを確認してもかまいません。ただし、同梱されている文面と矛盾してはなりません。また、ウェブページを normativeRef として使うことはできません（--no-web で提示を無効にできます。CI ではデフォルトで無効です）。
3. 優先順位に沿って修正します。機械的な修正には fix --write --iterate（回帰防止ゲート）を使い、続いて references/correction.md を参考に、判断が必要な修正やコンテンツの修正（代替テキスト、ラベル、構造）を手作業で適用します。
4. 再監査します（該当する場合はレンダリング結果を対象にします）。その後、繰り返します。
5. 監査人向けブロックを提出します。 report（適合性ドキュメント：概要と、NC の基準ごとの監査人向け適合ブロック 1 件。テーマ／基準／テスト／WCAG+レベル／所見／期待される内容／検証）と prd（同じブロックを実行可能なバックログとして提示。tickets は同一のブロックを含む GitHub issue を基準ごとに 1 件作成）は、同じ構成要素を異なる形で提示します。この会話で使われている言語で出力されます（明示的に --lang を指定してください — コアルール 7）。
6. review-a11y にサブエージェントとして引き継ぎます。 成果物ができた後も、修正したコードは変更としてレビューする必要があります。それがもう一方のスキルの役割です。詳しくは以下の review-a11y への引き継ぎ を参照してください。

check と verify --apply が再び成功し、明示的に名前を挙げた残存リスクだけになったら、停止します。（外側のサイクルを自動化するには、ハーネスの /loop コマンドでこのサイクルを再実行できます。）

review-a11y への引き継ぎ

このスキルは、監査、レンダリング、判定、修正、再監査、成果物の提示まで、分析を端から端まで行います。修正を完了したら、変更対象のコードを review-a11y にサブエージェントとして渡し、その結果を報告してください。

ホスト固有のサブエージェント機能を使います。Codex では以下のプロンプトでサブエージェントを呼び出し、Claude Code では Agent(...) を使用できます。ホストがどちらも提供していない場合は、以下の逐次処理の手順に従ってください。

Use the review-a11y skill on the working diff. Return its report verbatim.

2 つのスキルには、それぞれ異なる対象範囲があります。この分担は見かけだけのものではありません。

	対象範囲	問い
ultra11y（このスキル）	リポジトリ、ページのサンプル、標準	この製品は適合しているか。証拠はどこにあるか。
review-a11y	変更対象のコードのみ（ステージ済みの変更、差分、またはマージベースとの差分に対するブランチ）	この変更は安全にマージできるか。

インラインでレビューするのではなく、サブエージェントに渡す理由。 完全な監査を行うと、3 MB のエンジンの出力、数十個の参照ファイル、ページのサンプルでコンテキストが埋まります。一方、レビューではそれらに邪魔されず、差分を細かく読む必要があります。引き継ぐことで、レビューの判断を直前に行った監査から独立させられます。これは、verify が検出結果を信頼するのではなく反証しようとするのと同じ理由です。ハーネスにサブエージェントツールがない場合は、review-a11y を直接呼び出してください。フォールバックは references/orchestration.md のルーティング表に記載されており、どちらの方法でもレビュー内容は同じです。

判定を言い換えないでください。 返される成果物は、重要度順に並び、file:line と一行の判定を含むレビューです。これは要約ではなく、そのまま提示すべき成果物です。

エンジン、判断、残存リスクの組み合わせ

audit は、静的に評価できる範囲の各基準を C／NC／NA に分類し、それ以外は manual に分類します。それぞれには、手動評価が必要な理由と解決方法を示す automatability クラスが付きます。static（エンジンが判定）、needs-rendering（scan）、judgment（収集した証拠と判定プロトコルに基づくあなたの判断）です。エンジンが出した NC は、file:line が示された確認候補です。preliminary: true の検出結果（SFC／ライブラリのソース）は暫定的なもので、レンダリングで確認するか、反証してください。基準が黙って適合とマークされることはありません。レポートが完成するのは、適用可能なすべての基準が、正当な理由のある C／NC／NA となり、すべての残存リスクに名前が付けられた場合だけです。詳しくは references/methodology.md を参照してください。

助言的な推奨事項は、別の分類です。 不適合となる規範的なテストがない場合、ベストプラクティスに関するシグナルは専用のセクションに表示され、基準を NC に変更したり、conformancePct に含めたりすることはありません。NC には normativeRef が必要ですが、推奨事項には必要ありません。一方を他方に格上げしないでください。詳しくは references/false-positives.md を参照してください。

禁止事項

• エンジンが検出しておらず、自分でも確認できない不適合をでっち上げないでください（インラインのリテラル色のコントラストは静的に判定されます。計算後のコントラスト（外部 CSS、変数）は scan（Docker ティア）で確認するか、適合と宣言する前にレンダリング時に検証します）。
• ネイティブのセマンティクスと重複する ARIA を追加しないでください。
• 記録され、ゲートを通過した根拠なしに、レンダリング／判断が必要な基準を「適合」とマークしないでください（verify --manual によるエージェントの判定、または scan の証拠が必要です）。
• references/criteria.md を手動編集しないでください（criteria --generate を使い、WCAG データセットから生成されています）。

対象範囲

静的エンジン：オフラインで動作し、決定論的で、インストール不要です。入力は HTML と JSX/TSX（実際の AST、--graph によるファイル間解析）および stdin です。レンダリング基準（計算後のコントラスト、リフロー）は、オプションの scan ティア（axe-core、Docker または --runtime local）でカバーされます。ローカルランタイムではさらに、フォーカスの可視性（2.4.7）、テキストの 200% 拡大（1.4.4）、テキスト間隔（1.4.12）、ホバー時のコンテンツ（1.4.13）をプローブします。レンダリングされたページで確認し、失敗が確認された場合にのみ NC として報告します（問題のないプローブでも SC は manual のままであり、暗黙に適合とすることはありません）。読み上げ順序と代替テキストの関連性は AI エージェントが判断し、収集した証拠に基づいて裁定されます。さらに、verify --manual によるゲートが適用されます。 データ：WCAG 2.2 © W3C（W3C 文書ライセンス）；RGAA パックは RGAA 4.1.2 © DINUM、Licence Ouverte / Etalab 2.0（NOTICE を参照）。