ultra11y — WCAG 2.2 AA 監査とアクセシブルなマークアップ作成

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 の good/bad パターン）は AI に取り込まれ、pack check でゲートされるため、偽のマッピングが通過することはありません — references/packs.md および references/guidance.md を参照。

作業のほとんどはあなたのものです。 55 の WCAG 2.2 AA 達成基準のうち、エンジンが直接判断できるのは 3 つです。14 はレンダリング済みページ（scan）を必要とし、38 はエージェントが判断する判断項目です。したがって、エンジンのクリーンな実行は出発点であり、最終的な判断ではありません — references/adjudication.md が、実際に作業するページです。

中核ルール:

1. 非準拠をでっち上げない: すべての NC は、実際に解決可能な要素を引用します（check で検証）。
2. ネイティブ HTML を優先し、ARIA は最後の手段。暗黙のセマンティクスを決して重複させない。
3. 同様に準拠をでっち上げない: C も NC とまったく同様に引用されます — クリアした収集済み証拠を citations[] に列挙し、各アンカーは解決可能で、その基準が実際に示された証拠から引き出されます。証拠なしで提示された基準は、C になることはできません。manual のままです。また、読み取りが INCOMPLETE（evidenceComplete: false）であった基準も同様です：一部しか示されなかった基準は、見たものに対して不合格になることはあっても、見なかったものに対して合格になることは決してありません。そして、判断された C はエンジンで決定されたものと決してマージされません。レポートはそれを別個にリストし、自動合格率から除外します。 3b. あなたに示されるのは、1 つの異なるものにつき 1 回だけ言及された、全体の母集団です。 証拠はコンテンツクラスごとに 1 つの代表であり、occurrences、alsoAt 内の他のアンカー、およびそれが現れる pages を持ちます — 38 のキャプチャされたページにわたる 887 のリンクは、97 の異なる (text, href) ペアです。代表を判断することは、そのすべてを判断することであり、それが誠実な C に到達することを可能にします。また、基準が保持するクラスのいずれかの出現を名前付ける引用は受け入れられるため、実際に開いたものを引用してください。
4. 残差は明示的であり、決して黙示的に準拠ではありません: AI エージェントは判断基準のすべてを自身で評価します（verify --manual、ゲート付き）。レンダリング基準は 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）。それは、C を獲得するためにまだ判断が必要な基準の数を教えます — 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 / references/rendered.md を参照。
7. 言語: ユーザーとの会話の言語に一致する --lang を常に渡してください。曖昧な場合はユーザーに確認してください。フラグがない場合、CLI は自動検出します（リポジトリの <html lang> → アクティブな標準のデフォルトロケール → 英語） — これはスクリプト/CI のフォールバックであり、--lang を自分で渡す代わりにはなりません。
8. 技術トークンはフランス語の散文でも英語のままにします。 フランス語で作成する成果物（レポートのコメント、PRD、トラッカーチケット、判断の評決）では、属性/要素/ロール名とその値はコードであり、散文ではありません — 決して翻訳しないでください：aria-live は aria-live のまま（「région live」とはしない）、tabindex、alt、role="alert"、ランドマークロール名も同様です。エンジン自身の fr カタログもこれに従います。それに合わせてください。規範的な標準語彙（RGAA の「lien d'évitement」のような表現）は、公式のフランス語を保持します。

リファレンスライブラリ

まずドメイン知識、次にツール。あなたの前にある質問に一致するものを読んでください。

アクセシビリティ知識
references/adjudication.md	エンジンが渡す 52 の基準のそれぞれを判断する方法 — 判断ルール、NA が適切な場合、質問事項
references/naming.md	アクセシブルな名前の計算、2.5.3 label-in-name、visually-hidden 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
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 基準ごとに 1 つの auditor conformance block — 同じブロックを 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 を読んでください。
• 「クロスファイル分析（ツリー + 依存関係）、JSX/TSX を真の AST として」 → audit --graph はインポートを解決し、クロスファイルルールを適用します

…

[truncated for translation]