frontend-a11y

フロントエンドのアクセシビリティ

コードはできるだけ少なく書きます。ARIA 属性や JavaScript ライブラリを使う前に、ネイティブの HTML 要素を使いましょう。ブラウザーにはアクセシビリティ機能がすでに備わっており、書かずに済む属性が一つ増えるたびに、壊れる可能性も一つ減ります。

---

プロジェクトの技術スタックに合わせる

ここに記載するルールはすべてフレームワークに依存しません。フレームワークは HTML にコンパイルされるため、ソースが JSX、Vue テンプレート、Svelte、Angular、生の HTML のどれであっても、<button> と <div role="button"> の違い、コントラスト比、WCAG の基準、ランドマークのルールは同じです。以下の HTML/CSS の例が標準となる唯一の基準です。概念は変わらず、構文だけが変わります。

そのため、このファイルを書き換える必要はありません。コードを書く前に少し立ち止まり、出力をプロジェクトに合わせてください。

1. 技術スタックを確認します。 package.json、ファイル拡張子（.jsx／.tsx、.vue、.svelte）、フレームワークの設定を確認します。不明な場合は、リポジトリ内の既存コンポーネントの書き方に合わせます。
2. 例を置き換えます。 意味を変えずに、各スニペットをプロジェクトの慣習に沿って書き直します。属性名（React では class → className、for → htmlFor）、イベントバインディング、ID の生成方法などが対象です。
3. 落とし穴に注意します。 フレームワークには、プレーンな HTML にはない危険が再び持ち込まれることがあります。フォーカスを移動しないクライアントサイドルーティング、XSS を可能にするテンプレートのエスケープ回避機能、ネイティブのセマンティクスを覆い隠すコンポーネントライブラリなどです。以下のリファレンスに該当する技術スタックを使っている場合は、まずそのファイルを読んでください。HTML を基準とした場合の差分だけを説明しています。

技術スタック	参照先
React / Next.js / Preact	react.md
Vue / Nuxt	vue.md
Svelte / SvelteKit	svelte.md
Angular	angular.md
Web components / Lit / Stencil	web-components.md

プレーンな HTML、またはここに記載されていない技術スタックですか？以下の例をそのまま適用できます。

---

HTML ガイドライン

ネイティブ要素を使う

ブラウザーにはアクセシブルな要素がすでに用意されています。それらを使いましょう。

<div role="button" tabindex="0" onclick="submit()">Submit</div>


<button type="submit">Submit</button>

冗長なロールを追加しない

ランドマーク要素には、すでに暗黙のロールが設定されています。重ねて指定しないでください。

<header role="banner">...</header>
<nav role="navigation">...</nav>
<main role="main">...</main>
<footer role="contentinfo">...</footer>


<header>...</header>
<nav>...</nav>
<main>...</main>
<footer>...</footer>

ランドマークの名前にロール名を重ねて含めない

スクリーンリーダーはランドマークをロールで読み上げます。「navigation（ナビゲーション）」、「banner（バナー）」、「main（メイン）」、「content info（コンテンツ情報）」などです。その単語をアクセシブルな名前に繰り返すと、読み上げが重複します（「navigation、navigation」）。名前は、ランドマークが何であるかを言い直すのではなく、同じ種類のほかのランドマークと 区別する ために付けます。

• <nav> の aria-label に「navigation」を含めてはいけません。何をナビゲートするのかに基づいて「Primary」、「Footer」、「Breadcrumb」のように名前を付けます。そうすれば「Primary、navigation」と読み上げられます。
• <header>（banner）、<main>、<footer>（contentinfo）に aria-label は不要です。ページに各要素は一つずつしかないため、区別すべき同種の要素はありません。同じロールのランドマークが複数ある場合（例：<nav> が二つ）に限り、名前を付けます。

<nav aria-label="Main navigation">...</nav>
<header aria-label="Header">...</header>
<main aria-label="Main content">...</main>


<nav aria-label="Primary">...</nav>
<nav aria-label="Footer">...</nav>
<header>...</header>
<main>...</main>

実際の見出しがある場合にのみリージョンに名前を付ける

<section> がランドマーク（暗黙の role="region"）になるのは、アクセシブルな名前がある場合のみです。その場合、スクリーンリーダーのランドマークメニューに表示されます。ランドマークはナビゲーションのショートカットなので、明確に区別できる名前付きの領域を示す場合にのみ役立ちます。「Cards」や「Updates」のような一般的な名前のリージョンは、メニューを見づらくする ノイズ です。

• 実際に画面に表示される見出しがある場合にのみリージョンを追加し、見出しの id を指定した aria-labelledby で名前を付けます。こうするとアクセシブルな名前は画面上のテキストそのものになり、文章の変更に応じて同期する唯一の情報源になります。
• リージョンを成立させるために、人工的な aria-label を決して作らないでください。見出しがない場合は、プレーンな <div> のラッパーを使います。同じスタイルを適用でき、ランドマークにはなりません。

<section aria-label="Article cards">...</section>


<section aria-labelledby="latest-heading">
  <h2 id="latest-heading">Latest articles</h2>
  ...
</section>


<div class="cards">...</div>

div より意味のある要素を使う

汎用的なコンテナーを、意味のある要素に置き換えます。

<div class="header">
  <div class="nav">...</div>
</div>


<header>
  <nav>...</nav>
</header>

ボタンのタイプを設定する

フォーム内にある <button> は、type が指定されていない場合、デフォルトで submit となり、クリックすると送信されます。必ず type を明示的に設定してください。

<button onclick="toggle()">Toggle</button>


<button type="button" onclick="toggle()">Toggle</button>
<button type="submit">Submit</button>

ボタンを無効にせず、aria-disabled を使う

ネイティブの disabled 属性を使うと、<button> はタブ移動の対象から除外されるだけでなく、アクセシビリティツリーからも取り除かれます。そのため、キーボードやスクリーンリーダーを使うユーザーは、ボタンが存在することや、_なぜ_利用できないのかを知るためにフォーカスすることができず、回避可能なアクセシビリティの低下を招きます。

• 非送信のコントロールに非アクティブな状態が必要な場合 → aria-disabled="true"。 フォーカス可能な状態を保ち、「薄く表示」／「利用不可」と読み上げられます。操作は JavaScript で抑制します。代表例はカルーセルの矢印などのナビゲーションコントロールです。コントロールが消えてしまうのではなく、ユーザーがそのコントロールを_見つけて_、非アクティブだと認識できる必要があります。
• 送信ボタン → 常にアクティブにします。 disabled も aria-disabled も指定しません。何が不足しているのか説明しないまま操作できないボタンを置くのではなく、押したときにバリデーションを実行してエラーを読み上げます。
• フォームの_フィールド_（<input>、<select>、<textarea>）→ ネイティブの disabled が適切です。 これらの要素では、値を送信するかどうかを制御します。コントロールの操作性とは別の問題です。

<button type="submit">Submit</button>


<button
  type="button"
  aria-label="Scroll to next"
  aria-disabled="true"
  onclick="scrollNext()"
>
  <svg aria-hidden="true">...</svg>
</button>

切り替わるボタンの名前は一定に保つ

aria-expanded を持つトグルボタンは状態をすでに読み上げます。「メニュー、ボタン、折りたたみ」→「メニュー、ボタン、展開」のようにです。_名前_はボタンが制御するものを説明し、どちらの状態でも一定に保ってください。「メニューを開く」／「メニューを閉じる」に切り替えると、状態を名前にも重複して含めることになり、読み上げられる状態と矛盾する場合さえあります。

<button aria-expanded="false" aria-label="Open menu">...</button>


<button aria-expanded="false" aria-controls="menu" aria-label="Menu">
  ...
</button>

アイコンのみのコントロールにはアクセシブルな名前が必要

コンテンツがアイコンだけのコントロールには、スクリーンリーダーが読み上げるテキストがありません。aria-label で名前を指定し、装飾用のアイコンをアクセシビリティツリーから隠してください。

<button type="button" aria-label="Close">
  <svg aria-hidden="true">...</svg>
</button>

画像は種類ではなく内容を説明する

スクリーンリーダーは <img> をすでに「画像」（または「グラフィック」）と読み上げるため、alt はカテゴリではなく_内容_を説明するためのものです。alt に「画像」、「写真」、「グラフィック」、「アイコン」、「ロゴ」といった語を入れても、役割を繰り返すだけです。

• ブランドロゴの alt には「ロゴ」ではなくブランド名を指定します。隣接するテキストと重複し、情報を追加しない装飾用ロゴには alt="" を指定して読み上げを省略します。
• コンテンツ画像では、被写体を説明します。

<img src="logo.svg" alt="Acme logo" />
<img src="team.jpg" alt="photo of a family" />


<img src="logo.svg" alt="Acme" />
<img src="team.jpg" alt="Family reviewing plan options at a table" />

リンク画像の alt はリンクの名前

<img> がリンクの唯一のコンテンツ（ホームへリンクするロゴ、カードのサムネイルなど）の場合、画像の alt がそのリンクのアクセシブルな名前になります。外側の <a> に aria-label を指定すると、その名前が上書きされて画像の意味が失われ、画像が実質的に存在しないものとして扱われます。リンク先は alt で説明し、リンクにはラベルを付けないでください。名前を伝えられる画像が実際にない場合に限り、_代替手段_としてリンクに aria-label を追加します。

<a href="/" aria-label="Home page"><img src="logo.svg" alt="" /></a>


<a href="/"><img src="logo.svg" alt="Acme" /></a>


<a href="/"><span class="brand">Acme</span></a>

視覚的に隠すテキストは名前に使い、ヒントには使わない

visuallyhidden ユーティリティ（sr-only と呼ばれることもあります）を使って、要素にスクリーンリーダー専用のアクセシブルな名前を付けます。たとえば、表示される見出しがロゴだけのパネルにも、名前を付ける見出しが必要です。しかし、操作可能なコントロールの_内部_にある visuallyhidden テキストは、そのコントロールの名前の一部になります。そのため、「新しいタブで開きます」のような補足的な_ヒント_には適していません。次のセクションを参照してください。

<span class="visuallyhidden">Main navigation</span>

.visuallyhidden:not(:focus):not(:active) {
  position: absolute;
  clip-path: inset(50%);
  overflow: hidden;
  block-size: 1px;
  inline-size: 1px;
  white-space: nowrap;
}

補足情報は名前ではなく aria-describedby に記述する

コントロールには異なるアクセシブルな文字列が二つあり、これらを混同すると実際の不具合につながります。

• アクセシブルネーム — ユーザーが操作する際の、短く主要なラベルです（「Facebook でシェア」）。要素内の表示テキスト、visuallyhidden テキスト、または aria-label から構成されます。
• アクセシブルディスクリプション — 名前の後に間を置いて読み上げられる補足情報です（「新しいタブで開きます」）。aria-describedby から構成されます。

ヒントを名前に含めると、三つの問題が生じます。aria-label は内部コンテンツを上書きするため、要素に aria-label がある場合、visuallyhidden のヒントは通知されずに失われます。また、音声コントロールにも支障が出ます（ユーザーはコントロールを操作する際に 名前 を発話するため、長くなった名前が一致しなくなることがあります）。さらに、読み上げが毎回冗長になります。名前は簡潔に保ち、ヒントは aria-describedby で関連付けてください。

<button aria-label="Share on Facebook">
  <svg aria-hidden="true">...</svg>
  <span class="visuallyhidden">opens in a new tab</span>
</button>


<a href="..." target="_blank" rel="noopener" aria-describedby="new-tab-hint"
  >Share on Facebook</a
>


<span id="new-tab-hint" hidden>opens in a new tab</span>

同じヒントを多くのコントロール（ページ内のすべての外部リンクなど）に適用する場合は、説明をグローバルに非表示の要素として 一度だけ 出力し、コントロールごとに span を複製するのではなく、共通の id で各コントロールから参照してください。ここでは hidden を使っても問題ありません。aria-describedby は非表示の参照先も解決できます。

title 属性は使わない

title 属性は十分にサポートされていません。<iframe> にのみ使用してください。

<button title="Submit form">Submit</button>


<iframe src="..." title="Video player"></iframe>

---

コンポーネントのパターン

必要な動作をすでに備えているネイティブ要素を使用してください。コンボボックス、タブ、スイッチなど、ネイティブ HTML では対応できないウィジェットについては、APG の参考資料とこのプロジェクトで推奨する方法をまとめた patterns.md を参照してください。

アコーディオン

ネイティブの <details> と <summary> を使用してください。JavaScript は不要です。

<div class="accordion">
  <button aria-expanded="false" aria-controls="panel-1">Section</button>
  <div id="panel-1" hidden>Content</div>
</div>


<details>
  <summary>Section</summary>
  <p>Content</p>
</details>

モーダルダイアログ

ネイティブの <dialog> と showModal() を使用してください。フォーカスのトラップと Escape キーの処理は組み込みで備わっています。

<div role="dialog" aria-modal="true" aria-labelledby="title">
  <h2 id="title">Title</h2>
  <p>Content</p>
</div>


<dialog id="my-dialog" aria-labelledby="my-dialog-title">
  <h2 id="my-dialog-title">Title</h2>
  <p>Content</p>
  <button type="button" onclick="this.closest('dialog').close()">Close</button>
</dialog>

<button
  type="button"
  onclick="document.getElementById('my-dialog').showModal()"
>
  Open dialog
</button>

showModal() メソッドは次の処理を自動的に行います。

• ダイアログ内にフォーカスをとどめる
• Escape キーで閉じる
• ::backdrop 疑似要素を追加する
• 背後のコンテンツを inert にする

ダイアログには、必ずアクセシブルネームが必要です。見出しを付けて aria-labelledby で参照するか、表示される見出しがない場合は aria-label を使用してください。

ナビゲーション

ドロップダウンには <nav> と <button>、および aria-expanded を使用してください。ページに <nav> が複数ある場合は、それぞれが 何へ案内するのか を名前に付けてください。「navigation」という語は含めないでください（「ランドマークに冗長な名前を付けない」を参照）。

<nav aria-label="Primary">
  <ul>
    <li>
      <button aria-expanded="false" aria-controls="submenu">Products</button>
      <ul id="submenu" hidden>
        <li><a href="/product-1">Product 1</a></li>
      </ul>
    </li>
  </ul>
</nav>

ナビゲーションに role="menu"、role="menuitem"、aria-haspopup は 使用しないでください。

スキップリンク

スキップリンクを使うと、キーボードやスクリーンリーダーのユーザーは、繰り返し表示されるブロックを飛ばしてメインコンテンツに直接移動できます（WCAG 2.2 — 2.4.1 ブロックのバイパス）。大きなメニュー、多階層のドロップダウン、検索バーなど、サイト全体で 複雑なナビゲーションをページ間で繰り返す 場合に有効です。そうでなければ、ユーザーはページを読み込むたびに、そのすべてをもう一度タブ移動する必要があるためです。リンクが一つか二つあるだけなら、飛ばすべきものは実質的にないため、追加しても利点はほとんどありません。

これを 最初にフォーカス可能な要素 にし、<main> の id（または主要コンテンツのコンテナー）を参照させ、フォーカスされるまでは非表示にしてください。タブ移動でフォーカスしたときに表示される必要があります。そうすることで、視覚的にページを見るキーボードユーザーも、移動先を確認できます。

<body>
  <a class="skip-link" href="#main-content">Skip to main content</a>
  <header>...</header>
  <nav aria-label="Primary">...</nav>
  <main id="main-content">...</main>
</body>

.skip-link {
  position: absolute;
  inset-block-start: 0;
  inset-inline-start: 0;
  transform: translateY(-100%);
}

/* Reveal it when a keyboard user tabs to it */
.skip-link:focus-visible {
  transform: translateY(0);
}

display: none や .visuallyhidden パターンで非表示にしないでください。これらはフォーカスされても非表示のままなので、視覚的にページを見るキーボードユーザーには移動先が見えません。画面外に配置しつつ、画面内へ戻るアニメーションが可能な状態にする必要があります。

アラート

緊急メッセージには role="alert"（assertive）を、緊急ではない更新には role="status" または aria-live="polite" を使用してください。テキストを挿入する前に、その領域がすでに DOM 内に存在している必要があります。また、role="alert" に aria-live／aria-atomic を手動で追加しないでください。これらは暗黙的に指定されます（WCAG 2.2 — 4.1.3 ステータスメッセージ）。マークアップ、丁寧さの全段階、発火時の注意点については patterns.md を参照してください。

フォームのエラー

検証エラーを aria-live で通知するのではなく、ユーザーをエラーの位置へ移動させます。インラインメッセージは aria-invalid="true" と aria-describedby で該当フィールドに関連付け、送信に失敗したら、フォームの先頭にあるエラー概要（tabindex="-1"）へフォーカスを移動します。マークアップとその理由については、patterns.md を参照してください。

カルーセル／スクロール可能なコンテンツ

カルーセルはネイティブ HTML で構築し、カルーセルライブラリを使ったり、カルーセル用の ARIA を独自に実装したりしないでください。overflow-x: auto と CSS のスクロールスナップを設定した <ul> を優先し、キーボードやタッチによるスクロールはブラウザーに任せます。矢印ボタンがそれ以上進めない場合は、ネイティブの disabled ではなく aria-disabled を使います。このプロジェクトでは、role="region" と aria-roledescription よりも、ネイティブなリスト／スクロールのセマンティクスを標準としています。スクロールスナップのトラックと単一スライドの切り替えに関するマークアップと理由については、patterns.md を参照してください。

---

CSS ガイドライン

以下の CSS の選択は、アクセシビリティに直接影響します。各ルールのコード例と理由の詳細は、css.md を参照してください。

絶対値の px ではなく相対長さ単位を使う

ピクセルによる固定サイズ指定は、ユーザーのフォントサイズ設定を無視し、200％のズーム時やリフロー時に表示を崩します（WCAG 2.2 — 1.4.4 Resize Text、1.4.10 Reflow）。文字、余白、レイアウトには rem、要素自身に応じて拡大縮小する値には em、流動的なレイアウトには %／ch／ビューポート単位を標準として使い、px は細い境界線と視覚上の微調整に限定してください。

論理プロパティを使う

レイアウトを右から左へ書く言語や縦書きに、書き直さずに対応できるよう、物理プロパティ（width、margin-left、top）よりも論理プロパティ（inline-size、margin-inline、inset-inline-start）を優先してください。

ARIA 属性をスタイル指定のフックとして使う

並行する修飾クラスを追加するのではなく、ARIA の状態（[aria-expanded="true"]、[aria-current="page"]、[aria-disabled="true"]）を直接スタイル指定に使ってください。これにより、アクセシビリティツリーとの不整合が生じない、単一の信頼できる情報源を保てます。

カーソルで操作可能かどうかを示す

操作可能なコントロールには cursor: pointer、操作できないコントロールには cursor: not-allowed を指定してください。ボタンではネイティブの disabled ではなく aria-disabled で「オフ」の状態を示すため（「ボタンを無効化しない」を参照）、その状態を明示的にスタイル指定してください。カーソルはポインターを使うユーザーへの補助にすぎません。実際のセマンティクスと併用するものであり、その代わりにはなりません。

HTML で大文字だけのテキストを書かない

通常の大文字・小文字で記述し、CSS（text-transform: uppercase）で大文字にしてください。これにより、スクリーンリーダーが文字を一つずつ読み上げるのを防げます。

色のコントラスト要件を満たす

テキストは WCAG 2.2 AA の最低コントラスト比を満たす必要があります。これは特に不適合になりやすいチェック項目の一つです。WebAIM Contrast Checker で色の組み合わせを確認してください。最低基準は次のとおりです。

• 通常のテキスト（18pt 未満／太字で 14pt 未満）：4.5:1
• 大きなテキスト（18pt 以上／太字で 14pt 以上）：3:1
• UI コンポーネントとフォーカスインジケーター：隣接する色に対して 3:1

css.md には、計算しなくてもこれらの基準を満たす安全なデフォルトのカラーパレットがあります。

一貫したフォーカスアウトラインを作る

すべての操作可能な要素に、:focus-visible で視認性の高いフォーカスインジケーター（例：outline: 2px solid; outline-offset: 2px）を設定してください。これにより、マウスクリック時には表示せず、キーボードを使うユーザーにはリングを表示できます。

動きと透明度の低減設定を尊重する

アニメーションは @media (prefers-reduced-motion: no-preference) の条件下でのみ有効にし、ガラスのような半透明の効果は @media (prefers-reduced-transparency: no-preference) の条件下でのみ有効にしてください。これにより、これらの効果を望まないユーザーには表示されません。

コンテンツを安全にフェードインする

フェードイン前にコンテンツを隠すために opacity: 0 だけを使わないでください。スクリーンリーダーは不透明度を無視するため、目の見えるユーザーに表示される前に要素が読み上げられます。非表示の状態は JS 準備完了クラスで制御し、IntersectionObserver でアニメーションを開始してください。これにより、スクリーンリーダーの仮想カーソルで要素が表示範囲にスクロールされたときにアニメーションが始まります。

ローカルの参照仕様（references/）

引用に必要な情報はすべて、オフラインで利用できる信頼できる情報源として references/ に含まれています。wcag.json は WCAG 2.2 の仕様全体を構造化データにしたものです。必ず適合基準の ID で検索し、全体を読み込まないでください。 aria.md は仕様をそのまま大規模に書き出したものです。最初から最後まで読み込まず、必要な用語を grep で検索してください。 standards.md には正式なオンライン情報源の索引があり、patterns.md にはネイティブ HTML では対応できないコンポーネントパターンが記載されています。

スタック別のファイル（react.md、vue.md、svelte.md、angular.md、web-components.md）は、上記の「プロジェクトのスタックに合わせる」のもう半分です。検出されたフレームワークに対応するファイルを読んでください。それぞれ短く、HTML の基本ルールとの差分（属性の変換、ID の生成、ルーティング時のフォーカス、テンプレートの XSS 回避策、コンポーネントライブラリに関する注意事項）のみを扱い、共通ルールは扱いません。

wcag.json で WCAG の適合基準を検索する

wcag.json は 4 つの原則からなる JSON 配列です。各原則には guidelines がネストされ、各ガイドラインには success_criteria がネストされています。各ノードには ref_id（"1"、"1.4"、"1.4.3"）、title、description、url が含まれています。適合基準にはさらに level（A／AA／AAA）、special_cases、notes、references が含まれています。行番号ではなく ref_id で適合基準を検索し、jq で該当するオブジェクトを正確に取り出してください。

jq '.. | objects | select(.ref_id? == "1.4.3")' references/wcag.json

名称しかわからない場合は、タイトル（'Contrast (Minimum)'、'Bypass Blocks'）を grep で検索してください。レベル AAA までの適合基準がすべて含まれているため（2.5 Input Modalities、2.4.2 Page Titled、2.4.6 Headings and Labels を含む）、ref_id が見つからない場合、その適合基準は WCAG 2.2 に存在しません。

aria.md で ARIA 仕様を grep する

aria.md は仕様をそのまま Markdown に書き出したものです。見出しを推測するのではなく、内容に含まれるキーワードで grep してください。ロールまたは属性そのもの（aria-expanded、Name, Role, Value）を検索すれば必ず見つかります。その後、該当箇所の前後、または以下の表にある既知の範囲を読んでください。

ファイル	仕様（サイズ）	参照するタイミング	主なセクション（行範囲）
standards.md	外部リンクの一覧（約 1 KB）	引用するための正式なオンライン情報源が必要な場合 — WCAG Understanding、クイックリファレンス、WAI-ARIA 仕様、APG、WebAIM、W3C バリデーター	全体を読む。短いファイルです
react.md · vue.md · svelte.md · angular.md · web-components.md	スタックごとのアクセシビリティ上の差分（各約 2〜3 KB）	プロジェクトでそのフレームワークを使用している場合 — HTML の例をそのフレームワークに合った記述に置き換え、固有の落とし穴（ルーティング時のフォーカス、テンプレートの XSS、ID／シャドウ境界のルール）を避けるとき	該当するスタックのファイルを全体的に読む。それぞれ短いファイルです
patterns.md	コンポーネントのパターン（約 5 KB）	本文で概要を説明するコンポーネント（カルーセル、ライブリージョンとアラート、フォームエラー）の完全なマークアップや根拠に加え、コンボボックス、タブ、スイッチ、APG へのリンクが必要な場合	全体を読む。短いファイルです
css.md	CSS のアクセシビリティパターン（約 6 KB）	本文で概要を説明する CSS ルール（相対単位、論理プロパティ、ARIA のスタイリングフック、カーソル、コントラストパレット、フォーカスアウトライン、動き／透明度の軽減、安全なフェードイン）のコードと根拠が必要な場合	全体を読む。短いファイルです
wcag.json	WCAG 2.2 の構造化 JSON — AA がプロジェクトの基準	コントラスト、フォーカス順序、ラベル、エラー処理、ステータスメッセージなど、達成基準を確認する場合	原則 1〜4 の配列 → guidelines → success_criteria。各ノードには ref_id がキーとして付与されています。jq／grep で ref_id または title を検索してください。全体を読む必要はありません。レベル AAA までのすべての達成基準が含まれています。
aria.md	WAI-ARIA 1.2（515 KB）	ARIA を手動で記述する必要がある場合に限ります（まれです。ネイティブ要素にはそれぞれロールと状態が備わっています）。属性を追加する前に、そのロールが属性をサポートしていることを確認してください	4. Using WAI-ARIA 464–568 · 5. The Roles Model 569–2804（ロール定義は 800 行目から） · 6. Supported States & Properties 2805–4344（aria-* の定義は 2916 行目から） · 7. Accessibility Tree 4345–4373 · 8. Implementation in Host Languages 4374–4472
チュートリアル形式のガイダンスやキーボード操作のパターンについては、仕様書そのものより、オンラインのWCAG 2.2 UnderstandingやARIA APGのほうが読みやすいです。WebAIM Contrast Checkerで色の組み合わせを確認してください。