accessibility

アクセシビリティ — レビュースキル

W3C Web Accessibility Initiative（WAI）を基盤とした、Web UI のアクセシビリティレビューの観点です。 目標は WCAG 2.2、適合レベル AA です。これは EN 301 549、ADA、 Section 508、European Accessibility Act の根拠となる技術基準です。

基盤となるスキル。 architecture-and-design と、ルールの背景にあるフレームワークの仕組みを扱う react、angular、または vue です。 タスクがそのレイヤーに関わる場合にのみ、関連するスキルを読み込みます。読み込まれていない場合は、一般知識に基づいてそのレイヤーを適用し、作業を止めないでください。

この SKILL.md だけで利用できます。以下の ルールセット が、完全かつ適用可能なルール一覧です。各 references/<topic>.md には、そのグループの根拠と ❌ / ✅ のコード例が記載されています。また、 references/worked-example.md にはレビュー全体の例があります。実行環境で可能な場合は、詳しく確認するために開いてください。

WCAG は、次の 4 つの原則（POUR）で構成されています。

原則	コンテンツに求められること
知覚可能	感覚で認識できること。テキストによる代替、キャプション、コントラスト、スタイル変更後も維持される構造が必要です。
操作可能	キーボードなどの入力手段で使えること。十分な時間があり、発作を引き起こす要素がなく、ナビゲーションが明確であることが必要です。
理解可能	読みやすく、予測しやすいこと。ラベルとエラーへの対処方法が必要です。
堅牢	ブラウザーや支援技術で正しく解析でき、今後の変化にも対応できること。

---

このスキルの使い方

タスクに合ったモードを選び、手順に沿って進めてください。

モード	手順
生成 — コンポーネントまたはページを作成する	1. まずネイティブ要素を使います。 2. すべてのコントロールにアクセシブルな名前を付けます。 3. キーボードで操作でき、フォーカスインジケーターが見えることを確認します。 4. axe のチェックを実行します。 5. チェックリストとしてルールセットを適用します。引き渡す前に、失敗項目をすべて修正してください。
レビュー — プルリクエストまたは差分を確認する	1. 差分にルールセットを適用します。 2. 失敗項目ごとに、以下の出力形式で指摘を 1 件記載します。要件がより明確になる場合は WCAG 達成基準を追加します。 3. 指摘は must-fix を先に、その後に consider の順で並べます。 4. 失敗項目がない場合は、その旨を 1 行で伝えます。指摘を捏造しないでください。
監査 — 既存の UI を評価する	1. 自動チェック（axe-core）を実行します。検出できるのは全体の約 30〜40％です。 2. 重要な操作経路をすべてキーボードのみで確認します。 3. スクリーンリーダーで重要なフローを確認します（Chrome では NVDA または JAWS、Safari では VoiceOver）。 4. 各指摘を WCAG 2.2 AA の達成基準に対応付けます。

実際のサイトで多く見られる問題を優先し、次の順でトリアージしてください。コントラストの低いテキスト、alt がない画像、アクセシブルな名前のないリンクやボタン、ラベルのないフォームフィールド、lang の欠落です。実環境で発生する問題の大半は、これらが原因です（WebAIM Million）。

出力形式

指摘は 1 件につき 1 行で記載します。

<severity> · <topic> · <file>:<line> — <what is wrong>. <the fix as an action>. [WCAG <criterion>]

• <severity> は must-fix（WCAG 2.2 AA の達成基準に違反する、またはユーザーの利用を妨げる）または consider（AA の基準には達しないが実際の障壁となる、または堅牢性に関するリスクがある）です。
• <topic> はルールセットのトピックスラッグ（structure、keyboard-focus、forms など）です。
• [WCAG <criterion>] は任意です。達成基準に要件が明記されている場合は追加してください（例：[WCAG 1.4.3]）。

すべてのモードに共通するルール

• ARIA の 5 つのルールの最初のルール（w3.org/TR/using-aria）に従います。ネイティブ要素がすでに役割、状態、キーボード操作、フォーカスを備えている場合は、その要素を使います。誤った ARIA より、ARIA を使わないほうが適切です。
• アクセシビリティは、機能ではなく正しさの要件です。後から対応するものではありません。
• プロダクトオーナーがより高い基準を設定していない限り、基準は WCAG 2.2 レベル AA です。

---

ルールセット

structure → references/structure.md

• インタラクティブな要素には、イベントハンドラーを設定した <div> ではなく、<button>／<a href>／<input> などのネイティブ要素を使用します。リンクはページ遷移、ボタンは操作を行い、互いの役割を装うことはありません。[WCAG 4.1.2, 2.1.1]
• 各ページに <h1> は1つだけ設けます。見出しのレベルは1つずつ下げ、スタイル設定のためにレベルを飛ばしてはいけません。[1.3.1, 2.4.6]
• リージョンはランドマーク（header／nav／main／aside／footer）で囲みます。<main> は正確に1つとし、同じ種類のランドマークには区別できる aria-label を付けます。[1.3.1]
• リストはリストとしてマークアップし、表形式のデータは <th> と scope を含む <table> としてマークアップします。
• <html> に lang を設定し（外国語の要素にも設定します）、各ページに固有で内容を説明する <title> を付けます。[3.1.1, 2.4.2]
• 新しいタブを開くリンクやファイルをダウンロードするリンクには、表示テキストまたはスクリーンリーダー向けテキストでその旨を示します。
• ヘルプ機能（問い合わせリンク、チャットの入り口）があるページでは、すべて同じ場所に配置します。[3.2.6]

names-aria → references/names-aria.md

• すべてのインタラクティブ要素にアクセシブルな名前（表示テキスト、aria-label、または aria-labelledby）を付けます。アイコンのみのボタンも対象です。表示ラベルがテキストの場合、アクセシブルな名前にもそのテキストを含めます。[4.1.2, 2.5.3]
• リンクとボタンのテキストは、それだけで意味が伝わるようにします。「こちらをクリック」や「詳細はこちら」だけの表現は避けます。[2.4.4]
• ネイティブのロールを上書きせず、要素がすでに持つロールを追加しません。ARIA の状態（aria-expanded、aria-selected、aria-checked、aria-pressed）は UI と一致させます。
• カスタムウィジェット（メニュー、コンボボックス、タブ、開閉パネル、スライダー）は、ロールとキーボード操作の両方について、ARIA APG のパターンに従います。
• モーダルは、aria-modal="true" と見出しを参照する aria-labelledby を設定した role="dialog"（または <dialog> と showModal()）にします。Esc キーで閉じられ、背景は inert にします。
• フォーカス可能な要素を aria-hidden のサブツリー内に配置しません。

keyboard-focus → references/keyboard-focus.md

• すべてのインタラクティブ要素にキーボードだけで移動して操作でき、どの手順でもフォーカスが閉じ込められないようにします。[2.1.1, 2.1.2]
• Tab キーの移動順序は読み上げ順に従わせます。正の tabindex は使用せず、DOM の順序を視覚的な順序と一致させます（Tab キーの順序や読み上げ順に従えなくなる CSS の order や位置指定は使いません）。[2.4.3, 1.3.2]
• スワイプ／ピンチ／パスジェスチャーとドラッグ＆ドロップには、すべて単一ポインターで操作できる代替手段を用意します。[2.5.1, 2.5.7]
• 時間制限がある場合は、期限切れの前に警告し、延長または無効化できるようにします。[2.2.1]
• :focus-visible でスタイルを設定した視認可能なフォーカスインジケーターを用意し、コントラスト比を3:1以上にします。outline: none を指定する場合は、同等以上の代替表示を用意します。[2.4.7, 1.4.11]
• 固定ヘッダーやフッターが、フォーカスされた要素を覆わないようにします。[2.4.11]
• 「メインコンテンツへスキップ」リンクを最初にフォーカス可能な要素として配置し、フォーカスを受けるまでは視覚的に隠します（display: none は使用しません）。[2.4.1]
• クライアントサイドのルート変更時は、新しいビュー（その <h1> または tabindex="-1" を設定したコンテナー）にフォーカスを移します。ダイアログ内ではフォーカスをトラップし、閉じたときに起動元へ戻します。
• 複合ウィジェット（グリッド、リストボックス、ツールバー、タブリスト）には、roving tabindex または aria-activedescendant を使用します。Tab キーの停止位置は1つにし、ウィジェット内は矢印キーで移動できるようにします。
• インタラクティブなターゲットのサイズは、CSS ピクセルで少なくとも24×24にするか、周囲に24 px以上の余白を設けます。[2.5.8]

forms → references/forms.md

• すべてのフィールドに、プログラムで関連付けられた<label>（for/id、またはフィールドを囲む形式）があること。プレースホルダーをラベルとして使用しないでください。[1.3.1, 3.3.2]
• 関連するフィールドは<fieldset> + <legend>でグループ化します。説明と形式のヒントはフィールドの前に置き、aria-describedbyで関連付けます。[1.3.1, 3.3.2]
• エラーはテキストで示し、aria-describedbyで関連付け、フィールドにaria-invalidを設定して、修正方法を提案します。色だけで示してはいけません。[3.3.1, 3.3.3, 1.4.1]
• 送信に失敗した場合は、フォームの先頭にエラーサマリー（見出しの後に、各エラーから該当フィールドへのリンクを配置）を表示し、サマリーにフォーカスを移します。
• フォームが無効であることを示すために送信ボタンを無効化しないでください。送信を実行し、サマリーを表示します。
• 必須フィールドであることを、表示されるラベルとaria-requiredで示します。アスタリスクだけで示してはいけません。[3.3.2]
• ID情報や連絡先情報のフィールドにautocompleteトークンを設定し、同じ情報を1つのフロー内で2回尋ねないでください。[1.3.5, 3.3.7]
• ログインで貼り付けとパスワードマネージャーを使用できるようにし、autocomplete="current-password" / "one-time-code"を設定して、パスキーまたはメールリンクによる方法を用意します。パズル形式のCAPTCHAには、認知負荷のない代替手段を用意します。[3.3.8]
• 法的、金銭的、または破壊的な結果を伴う送信は、確定前に取り消し可能にするか、確認するか、承認を求めます。[3.3.4]

perceivable → references/perceivable.md

• 意味のある画像には内容を伝えるaltを設定します。装飾画像にはalt=""を設定し、ラベル付きコントロール内のアイコンにはalt=""またはaria-hiddenを設定します。 [1.1.1]
• 動画には字幕を付け、音声には文字起こしを用意します。3秒を超えて自動再生される音声には、一時停止／停止コントロールと独立した音量調整を用意します。[1.2.1, 1.2.2, 1.4.2]
• 意味を色、形、位置だけで伝えてはいけません。[1.4.1]
• 本文テキストのコントラスト比は4.5:1以上、大きなテキスト（約24 px、または太字の19 px）、UIコンポーネントの境界、およびフォーカスインジケーターは3:1以上にします。[1.4.3, 1.4.11]
• 200%のズームで使用でき、320 CSS pxでコンテンツや機能を失わずにリフローし、テキスト間隔の上書きにも対応します。画面の向きを固定してはいけません。[1.4.10, 1.4.12, 1.3.4]
• prefers-reduced-motionを尊重します（視差効果、自動再生動画、大きな動きを使用しない）。1秒間に3回を超えて点滅するものを設けてはいけません。[2.3.1]
• 5秒を超えて移動、スクロール、または自動更新するコンテンツには、表示された一時停止／停止／非表示コントロールを用意します。[2.2.2]
• 強制カラー表示モードに対応します。background-imageで意味を伝えず、アイコンはcurrentColorまたはシステムカラーで描画し、@media (forced-colors: active)でテストします。
• ホバーまたはフォーカスで表示されるコンテンツは、閉じることができ、ホバーでき、閉じられるまで表示され続けます。[1.4.13]

live-regions → references/live-regions.md

• 非同期の結果（トースト、入力検証のサマリー、結果件数、保存状態）はライブリージョンを通じて通知します。エラーにはrole="status" / aria-live="polite"、role="alert"を使用します。[4.1.3]
• 更新前にライブリージョンの要素がすでにDOM内に存在していること。リージョンとそのメッセージを同時に挿入せず、テキストを変更します。
• assertive / alertは実際のエラーにのみ使用します。重要なメッセージの場合は、通知に頼るのではなく、そのメッセージにフォーカスを移します。
• クライアントサイドナビゲーションでは<title>を更新し、新しいビューにフォーカスを移します（keyboard-focusを参照）。
• 読み込み状態はスピナーだけでなくテキストで通知し、読み込み完了も通知します。[4.1.3]

テスト → references/testing.md

• CI で自動チェックを実行します。axe-core に加え、（React では）eslint-plugin-jsx-a11y、（Angular では）angular-eslint のテンプレートアクセシビリティルール、または （Vue では）eslint-plugin-vuejs-accessibility を使用します。これらで検出できるのは、およそ3分の1です。
• すべての重要な操作経路を、キーボードのみ（Tab、Shift+Tab、Enter、Space、矢印キー、Esc）で操作します。
• スクリーンリーダーで重要なフローを実行します。Chrome では NVDA または JAWS、Safari では VoiceOver を使用し、ウィジェットをブラウズモードとフォーム／フォーカスモードの両方でテストします。
• ブラウザーのズームを400％に設定し、OSの文字サイズを大きくした状態でもテストします。200％だけでは不十分です。[1.4.10]
• ユニットテストでは、ロールとアクセシブルネームで要素を取得します（getByRole('button', { name: 'Save' })）。
• コントラストは機能ごとではなく、デザインシステムで一度確認します。
• カスタムウィジェットは、アクセシブルなプリミティブ（Radix、React Aria、Angular CDK）を基盤として構築し、ゼロから作らないようにします。

---

対象範囲の制限

このスキルでは、Web UI のアクセシビリティを扱います。次の内容は対象外です。

• ATAG（オーサリングツール）または UAAG（ブラウザー）。これらはツールやユーザーエージェントの開発者向けの WAI 規格であり、アプリ開発者向けではありません。
• ネイティブモバイルのアクセシビリティ（iOS の UIAccessibility、Android のアクセシビリティ API）と、ドキュメントのアクセシビリティ（PDF、Office）。
• 法的助言。適合性の方針と法的リスクについては、法律顧問に相談してください。
• AA を超える WCAG レベル AAA の達成基準、および策定中の WCAG 3 と認知アクセシビリティ（COGA）の取り組み。動向は追跡しますが、草案に合わせて構築しないでください。WCAG 3 では、コントラスト比 4.5:1 が知覚モデル（APCA）に置き換わる可能性が高いですが、置き換わるまでは 2.2 の数値が要件です。
• 知覚に関する要件を満たす CSS（コントラストトークンの組み合わせ、prefers-reduced-motion、強制配色、rem による文字サイズ）については、styling-and-design-tokens を参照してください。
• ロケールに基づく lang と dir の設定、および双方向テキストの分離については、i18n-and-localization を参照してください。このスキルでは、lang と言語部分の指定要件を扱います。
• 各ルールを実装するフレームワークの仕組み（useId、refs、portals、CDK の a11y パッケージ、SFC テンプレート）については、react ／ angular ／ vue を参照してください。

---

参考資料

このスキルは、次の資料と連携します。

• architecture-and-design — その frontend-practices ルールが確認するのは、セマンティックな要素とラベルの有無のみです。フォーカス、ARIA、ライブリージョン、アクセシビリティテストについては、このスキルに委ねます。
• react — React の実装方法：useId、ref に基づくフォーカス制御、createPortal、プリミティブライブラリ（Radix、React Aria）。
• angular — Angular の実装方法：CDK の a11y パッケージ（cdkTrapFocus、FocusMonitor、LiveAnnouncer）と template/accessibility の lint ルール。
• vue — Vue の実装方法：セマンティックな SFC テンプレート、useId()、プリミティブライブラリ（Reka UI、Headless UI）。
• styling-and-design-tokens — このスキルの知覚可能性に関するルールを満たすトークンとクエリ（テーマごとのコントラストの組み合わせ、prefers-reduced-motion、強制配色、rem に基づく文字サイズ）を配置します。このスキルが要件を決め、もう一方のスキルが CSS を決めます。
• i18n-and-localization — ロケールに基づいて lang と dir を設定し、双方向テキストを分離します。このスキルでは、lang と言語部分の指定要件を扱います。

規範資料：

• WCAG 2.2 — w3.org/TR/WCAG22
• WAI-ARIA 1.2 と ARIA Authoring Practices Guide — w3.org/WAI/ARIA/apg
• Using ARIA（5つのルール）— w3.org/TR/using-aria
• ARIA in HTML（各要素で有効な ARIA）— w3.org/TR/html-aria

実務者向け資料：

• MDN Accessibility — ブラウザーでの ARIA と HTML の動作
• The A11Y Project checklist — a11yproject.com/checklist
• WebAIM — コントラストチェッカー、年次の WebAIM Million レポート、スクリーンリーダー調査
• GOV.UK Design System — ユーザーテスト済みのコンポーネントとパターンに関する注記、エラーサマリーパターン

競合がある場合は、このスキルがアクセシビリティ要件を決定し、フレームワークスキルが要件を満たす API を決定します。