behavioral-a11y

動作的なアクセシビリティ自動化スキル

正規のソース：mgifford/ACCESSIBILITY.md の examples/BEHAVIORAL_ACCESSIBILITY_AUTOMATION.md このスキルはそのファイルを基にしています。判断に迷う場合は、そちらの記述を優先してください。

静的なマークアップや単一の計算済みアクセシビリティツリーを調べるだけでなく、レンダリングされたページを操作する自動チェックを作成、実行、または解釈する際は、以下のルールを適用してください。

---

重大度スケール（このスキル）

レベル	意味
重大	このスキルの前提条件を満たしていないのに、動作に関する結果を確認済みの失敗として報告、またはゲート判定に使用している
深刻	指標、cantTell、確認済みの失敗という結果が、1つの合否シグナルにまとめられている
中程度	大規模な対象群での検出結果が、報告やトリアージの前に根本原因ごとに分類されていない
軽微	チェックに既知の偽陽性／偽陰性の制約があることが文書化されていない

---

重大：動作チェックが必要な理由

静的解析や、ブラウザーのルールを単一のスナップショットでスキャンするツール（axe-core など）が答えるのは、「この属性は有効か」「この要素にはアクセシブルな名前があるか」といった問いです。ページを利用している間にしか存在しない問いには答えられません。狭いビューポートでもレイアウトは機能するか、キーボードを使うユーザーに視認できるフォーカスの表示があるか、サイズ変更や間隔の拡大でコンテンツが切り取られないか、動的なUI状態（開いたメニュー、入力検証エラー、読み込み中のインジケーター）でも初期ページ状態と同じ保証が保たれるか、といった問いです。

動作チェックでは、サイズ変更、Tabキーによる移動、ホバー、待機など、ユーザーが行う操作を実際に実行し、その結果を観察してこうした問いに答えます。そのため、動作チェックは静的チェックよりコストが高く、環境要因（アニメーション、フォント、タイミング）による不安定さの影響も受けやすくなります。また、動作チェックを行っても、適合性テストになるわけではありません。

---

重大：結果の用語

すべての動作チェックでは、以下の結果カテゴリのいずれかを使用する必要があります。これらを一貫して使うことで、自動化による結果が、実際に確認できた内容を正確に示せます。

カテゴリ	意味
指標	障壁の可能性と相関するシグナルを観測しましたが、正当な説明（SCの例外、意図的なデザイン、偽陽性が生じやすいエッジケース）を排除できていません。人によるレビューに回してください。
確認済みの失敗（テストした個別のケースについて）	そのケースで一般的な偽陰性の原因を排除するために必要なすべての前提条件を満たしたことを確認しました。それでも、SCへの適合性を全面的に主張するものではありません。
cantTell	信頼できる判定に至りませんでした。ページが安定しなかった、スクリーンショットの網羅範囲を確認できなかった、フォーカスの解決がサポート対象外のケースに当たった、などです。合格とも失敗とも異なります。
テストエラー	チェック自体を実行できませんでした（ナビゲーションの失敗、予期しない例外など）。ページの動作が曖昧だったことを意味するcantTellとは異なります。
手動レビューが必要	自動化では解決を試みないカテゴリです。SC 1.4.10の例外が正当に適用されるか、指標に十分なコントラスト（SC 1.4.11）またはサイズ（SC 2.4.13）があるか、フォーカス順序が論理的か、などが該当します。

問題が検出されなかった結果は、適合性の主張ではありません。 no-overflow-detectedというリフローの結果が示すのは、このチェックで、このビューポートにおいて、このページの読み込み時に、ページレベルの水平方向のはみ出しが見つからなかったことだけです。コンテンツが切り取られているか、重なっているか、別の箇所にSC 1.4.10の例外が適用されるかについては、何も示しません。confirmed-no-visible-changeというフォーカス可視化の結果が示すのは、そのページの読み込み時に、フォーカスが対象コンポーネントへ確実に移動した後、コンポーネント周囲のパディングを含む比較領域内で、設定されたしきい値を超えるピクセル差が検出されなかったことだけです。視認できるフォーカスインジケーターが存在しないと無条件に主張するものではありません。

重要：サイトや大規模な対象群における誤検出

1 つの対象では無視できるほど小さく見える誤検出確率でも、同じチェックを多数の対象で実行すると、誤警告が頻発する可能性があります。例：対象ごとの誤検出確率が 0.5% で、結果が独立している場合、200 件の対象のうち少なくとも 1 件で誤警告が発生する確率は 1 − (1 − 0.005)²⁰⁰ ≈ 63% です。これは、独立性を仮定した場合に対象ごとの確率がどのように累積するかを示す例であり、実測結果ではありません。また、実際のウェブサイトでは、この仮定が成り立つことはほとんどありません。

通常は独立ではなく、相関があります。 ページ間でコンポーネント、テンプレート、スタイルシート、アプリケーションシェルが共有されるため、ウェブサイトの検出結果には相関があることがよくあります。共有ボタンコンポーネントにフォーカス時のスタイルが 1 つ欠けているだけで、そのコンポーネントを使用するすべてのページで同じ指摘が発生することがあります。根本原因によるクラスタリングが必要です。共有コンポーネントに原因を特定できる不具合は、無関係な N 件の不具合ではなく、影響を受ける箇所が N 件ある 1 件のシステム全体に及ぶ指摘として報告してください。

誤検出は不安定さとは異なります。 誤検出とは、テストが完了して結果を出したものの、指摘内容が誤っていることです。不安定さとは、同じ対象に対してテストを繰り返すと結果に一貫性がない状態で、通常はタイミング、アニメーション、または環境への依存が原因です。誤検出にはチェックの主張範囲を狭めることが必要です。不安定さにはテストの安定性を高めること（レイアウト／視覚的安定性を待つこと）が必要です。

適合率は推測せず、測定する必要があります。 公称の誤検出確率だけから適合率を推定しないでください。この数値は規模について考える際には役立ちますが、レビュー済みの結果と照合して測定するまでは、実際のチェックに関する主張にはなりません。

影響：

• 指標レベルの結果からは、レビュー可能な証拠を提示するようにし、ビルドを自動的にブロックしないでください。
• ビルドのブロックは通常、決定論的に確認された失敗、レビュー済みベースラインに対する再現可能な回帰、および以前に確認された不具合の再発に限るべきです。
• cantTell、テストエラー、リスク指標、レビュー済みの例外は、確認済みの失敗とは区別してください。上記の用語を簡便さのために「失敗」にまとめると、その用語を定義した目的が損なわれます。
• これらの結果は、個別でも集計でも、WCAG への適合を証明するものではありません。

これに伴う CI のゲートポリシーについては、skills/ci-cd/SKILL.md を参照してください。

---

詳細：リフローのリスク（SC 1.4.10）

このチェックの内容： CSS ピクセル単位で 320×720 のビューポートを設定し、レイアウトが安定するまで待機します（load、document.fonts.ready、および scrollWidth／scrollHeight に変化がない静穏期間）。水平スクロールを試みて、その結果生じたスクロール移動量を読み取ります（符号ではなく絶対値を比較するため、右から左に記述する文書でも動作します）。clientWidth／scrollWidth を測定し、ビューポートからはみ出している要素を可能な範囲で特定します。

返される内容： no-overflow-detected、potential-reflow-barrier、cant-tell、test-error のいずれかの verdict に加え、寸法、スクロールデータ、はみ出している可能性のある要素が返されます。

検出できないこと：

• スクロールバーのないコンテンツの切り取り — overflow: hidden によってコンテンツが表示されないまま切り詰められても、スクロール可能なオーバーフローは発生しないため、scrollWidth と clientWidth に差は生じません。これは文書化されている誤検知ではなく、見逃しのリスクであり、解決済みのケースではありません。
• SC 1.4.10 の例外が適用されるかどうか — はみ出している要素がデータテーブル、地図、図表、または意味を成すうえで二次元レイアウトを必要とする別のコンポーネントであるかどうかは、このチェックでは判断できません。
• 設定された静穏期間より短い、遅延したレイアウト変更。

SC 1.4.10 の例外の正確な意味： この例外が適用されるのは、ページ全体ではなく、使用または意味のために二次元レイアウトを必要とするコンテンツの一部分です。規範的な例には、データテーブル、地図、図表、ビデオプレーヤー、ゲーム、プレゼンテーション、常に表示されているツールバーを必要とするインターフェースがあります。自動化では判断できないため、レビュアーが確認しなければならない点は次のとおりです。

• 例外の対象となるコンポーネントがあっても、ページの残りの部分は例外の対象にはなりません。その周囲にある見出し、導入段落、フィルター、検索、ページネーションは、通常どおりリフローする必要があります。
• 例外の対象となるコンポーネント内でも、個々のセクションはリフローが必要な場合があります。テーブル全体のグリッドに二次元レイアウトが必要でも、個々のセル内のテキストコンテンツにその例外が自動的に適用されるわけではありません。
• 「必要とする」とは意味に関する判定であり、利便性に関する判定ではありません。リフローしても情報や機能が失われないのに、幅が固定されたレイアウトのほうが見栄えがよいというだけのコンポーネントは、例外の対象ではありません。

自動オーバーフロー検出では、候補を指摘できます。このテストを適用して例外を確認できるのは、人間のレビュアーだけです。

---

重大：フォーカス可視化のリスク（SC 2.4.7）の詳細

Tab の各停止位置で行うこと： Tab キーを押す前にアクティブな要素を記録します。実際の Tab キー押下を送信します（プログラムによる .focus() 呼び出しでは同じコードパスが実行されないため、使用しません）。フォーカスが移動し、ドキュメント内にとどまっていることを確認します。開いているシャドウルートをたどって最も深い階層のアクティブ要素を特定し、その要素がビューポート内にあることを確認します。要素のバウンディングボックス周辺に余白を設けた領域のスクリーンショットを取得し、フォーカスを外した状態で同じ領域の比較用スクリーンショットを取得します。フォーカスを復元し、2 枚の領域スクリーンショットを比較します。設定可能な最大停止数まで繰り返します。

ページ全体ではなく領域ごとに比較する理由： ページ全体を対象としたピクセルチェックでは、フォーカスインジケーターとページ内の別の場所で発生した無関係なアニメーションを区別できません。また、「この要素のインジケーターが消えた」ことと、「前の要素のインジケーターが消え、現在の要素にもインジケーターがない」ことも区別できません。テスト開始前にページ全体の視覚的な安定性を別途追跡しつつ、領域ごとに比較することで、どちらの誤判定も回避できます。

検出できないこと：

• インジケーターの十分なコントラスト、サイズ、使いやすさ — visible-change-detected という判定が意味するのはピクセルに変化があったことだけであり、変化が十分だったことではありません（コントラストツールによる確認または手動レビューが必要です）。
• 他のコンテンツによる隠蔽 — スティッキーヘッダー、Cookie バナー、その他の固定位置コンテンツが実際のインジケーターに重なることがあります。ピクセル比較だけでは重なりを検出できません。ジオメトリ比較モジュールが実装されるまでは、現在の「合格」判定は隠蔽（SC 2.4.11）について何も示さないものとして扱ってください。
• クロスオリジン iframe、および cant-tell-no-coverage の確認を超える同一オリジン iframe。
• 余白を設けた比較領域の外側に表示されるインジケーター — 領域ごとの比較に伴う、実際に存在する制約です。オフセット表示のインジケーターを使うことが分かっているコンポーネントでは、余白を広げてください。
• Tab によって引き起こされないフォーカスの変化（マウスまたはスクリプトによって、Tab の順次移動順序外で発生するフォーカス）。

confirmed-no-visible-change の結果が実際に示すこと： 対象コンポーネントの周囲に余白を設けた領域内で、設定されたしきい値を超えるピクセル差分が、そのページ読み込み時に検出されなかったことを示します。また、次のすべてが成立している必要があります。フォーカスが対象に移動したことが明確であること、対象が該当し、描画され、ビューポート内にあること、ページがテスト中を通して視覚的に安定していることです。これは意図的に「可視のフォーカスインジケーターが存在しない」という主張よりも限定的です。実際のインジケーターが検出されない場合もあります（余白を設けた領域の外にある、ピクセル差分のしきい値に達しない、または隠蔽されている場合）。また、コントラスト（SC 1.4.11）、最小サイズ（SC 2.4.13）、隠蔽（SC 2.4.11）について述べるものでもありません。

フォーカス順序の証拠： このチェックで使う同じ Tab による移動を利用して、訪問した要素の順序を記録できますが、その順序がページのコンテンツやタスクに対して論理的かどうかは判定できません。記録された停止位置の順序は、人間のレビュアー向けの証拠として扱い、判定結果としては扱わないでください。

---

中程度：文書化された未対応項目（自動化は未実装）

これらのチェックは、Reflow／Focus Visible の測定方法を応用できるものとして文書化されていますが、再利用可能なモジュールとしてはまだ実装されていません。自動チェックへの対応を主張する場合は、これらが対象外であることを明記してください。

• フォーカスの隠蔽（SC 2.4.11） — フォーカスされた要素のバウンディング矩形を、スティッキー／固定位置の祖先要素または重なり合う要素と比較します。
• テキストのサイズ変更とクリッピング（SC 1.4.4 テキストのサイズ変更） — Reflow と同じオーバーフロー／クリッピングの兆候を調べますが、320 CSS ピクセルではなく 200% のズームで行います。テキストのサイズ変更と Reflow は別個のチェックであり、混同しないでください（skills/manual-testing/SKILL.md を参照）。
• テキスト間隔（SC 1.4.12） — WCAG で指定されたユーザースタイルの上書き（行の高さ 1.5 倍、段落間隔 2 倍、文字間隔 0.12em、単語間隔 0.16em）を適用し、オーバーフロー／クリッピングの検出を再利用します。
• ホバー時またはフォーカス時に表示されるコンテンツ（SC 1.4.13） — ホバー／フォーカスをきっかけに表示されるコンテンツについて、閉じることができるか、ホバーで操作できるか、表示が持続するかを確認します。

---

中程度：大規模なフリートでこれらのチェックを実行する

大規模に結果を報告またはトリアージする際は、次の用語を一貫して使用してください。

• 固有の指摘事項 — 表示されるページやコンポーネントの数に関係なく、独立して説明される特定の不具合です。
• 影響を受けたインスタンス — 固有の指摘事項が発生している箇所です。1 回のテスト実行における、1 つの状態の、1 ページ上の 1 つのコンポーネントを指します。
• 影響を受けたページ — 1 つ以上の固有の指摘事項について、影響を受けたインスタンスを少なくとも 1 つ含むページです。
• 推定される根本原因のクラスター — 影響を受けたインスタンスのうち、単一の修正ですべてをまとめて解決できる可能性が高いほど、十分なコンテキスト（同じコンポーネント、テンプレート、スタイルシートのルール、生成されたマークアップのパターン）を共有するグループです。レビュー担当者が共通の原因を確認するまでは、「推定」にとどまります。

ページ単位の生の件数は、独立した不具合の数ではありません。「200 ページで失敗しました」よりも、「固有の指摘事項 1 件（共通ヘッダーにフォーカスインジケーターがない）、影響を受けたインスタンス 200 件、根本原因クラスター 1 件」のほうが、はるかに対応につなげやすい表現です。

推奨される実行頻度：

範囲	実行タイミング	目的
コンポーネントのフィクスチャ	すべてのプルリクエスト	既知のパターンを対象にした、高速で決定論的な回帰テスト
変更されたページと、影響を受けるアプリケーションの状態	すべてのプルリクエスト	実際の差分に合わせたカバレッジ
代表的なテンプレート	すべてのプルリクエスト	共有コンポーネントの回帰が、そのテンプレートを使うすべてのページに及ぶ前に検出
サイト全体またはフリートの全体調査	定期実行（毎晩／毎週）。各プルリクエストでは実行しない	プルリクエスト単位の実行では対応できない範囲をカバーし、ドリフトやプルリクエストの差分外にあるページを検出
根本原因クラスターごとに代表的な指摘事項を手動でレビュー	新しいインジケーターが出た各スキャンの後	影響を受けたインスタンスごとではなく、クラスターごとに 1 回、確認または棄却
問題なし（指摘事項なし）の結果を定期的にサンプリング	定期実行（頻度は低め）	偽陰性のリスクを推定

指摘事項なしと報告されたからといって、偽陰性がゼロであることが示されたわけではありません。問題なしの結果を定期的にサンプリングし、手動または別のチェックでレビューしてください。

---

完了の定義チェックリスト

• チェックに、ビューポート、タイミング、安定化に関する前提が記載されている
• 結果で、インジケーター、このインスタンスで確認済みの失敗、cantTell、テストエラーが区別されている
• チェックを再実行せずに指摘事項を特定できるだけの、機械可読な証拠（セレクター、rect、HTML 抜粋）が結果に含まれている
• 文書化された制限事項に、チェックで確認されている具体的な偽陽性と偽陰性のリスクが明記されている
• チェック自体の出力に、WCAG への適合を証明するものではないと記載されている
• CI との統合で、インジケーターと確認済みの失敗が別々に報告され、すべてのインジケーターが暗黙のうちにブロッキングエラーに変換されない
• フリート規模では、指摘事項が推定される根本原因のクラスターにまとめられ、影響を受けたページごとに制限なく項目を列挙するのではなく、影響を受けたインスタンスの件数を添えて固有の指摘事項として報告される
• ブロッキングポリシーを設ける場合は、決定論的な失敗、またはレビュー済みベースラインに対する再現可能な回帰に限定されている。初回検出のインジケーターは対象としない

---

WCAG の主な達成基準

• 1.4.4 テキストのサイズ変更（AA） — ここではまだ自動化されていません。「中程度」の課題を参照してください
• 1.4.10 リフロー（AA） — リフローのリスクを示すインジケーター
• 1.4.12 テキストの間隔（AA） — ここではまだ自動化されていません
• 1.4.13 ホバーまたはフォーカスで表示されるコンテンツ（AA） — ここではまだ自動化されていません
• 2.4.7 フォーカスの可視化（AA） — フォーカス可視性のリスクを示すインジケーター
• 2.4.11 フォーカスが隠されないこと（最低限）（AA） — ここではまだ自動化されていません
• 2.4.13 フォーカスの外観（AAA） — 動作に基づくピクセル比較だけではカバーされません

---

参考資料

• 正式版ガイド全文
• リフローリスクの実装
• フォーカス可視性リスクの実装
• Playwright の例とテスト
• CWAC (GOVTNZ) — このリポジトリのチェックは、CWAC が文書化した手法を独自に再実装したものです。CWAC は GPLv3、正式版リポジトリは MIT であり、CWAC のコードはコピーも翻訳もしていません。
• skills/manual-testing/SKILL.md — リフロー、ズーム、フォーカスインジケーターの手動テスト
• skills/ci-cd/SKILL.md — リスクインジケーター／ビルドゲートの CI ポリシー

標準の適用範囲： これらのルールは WCAG 2.2 AA を対象としています。 監視対象：https://www.w3.org/TR/wcag-3.0/