wcag-accessibility

WCAG アクセシビリティ（EN 301 549／欧州規格）

規格

**欧州アクセシビリティ法（EAA）**では、EU 内のデジタル製品およびサービスに対し、技術的な基準として WCAG 2.2 レベル AA を参照する EN 301 549 への準拠が求められています。これは任意ではなく、EU 市場で事業を展開する製品に対する法的要件です。

デフォルトでは、常に WCAG 2.2 AA に準拠して構築します。 逸脱する場合は、明示的かつ文書化された正当な理由が必要です。スケジュールの逼迫やデザイン上の好みを理由に、アクセシビリティ要件を省略してはいけません。

WCAG 2.2 AA の要件は、次の 4 つの原則にまとめられています。知覚可能、操作可能、理解可能、堅牢。

---

知覚可能

ユーザーがすべてのコンテンツと UI コンポーネントを知覚できる必要があります。

色のコントラスト

コンテキスト	最小比率	強化（AAA）
通常のテキスト（< 18pt ／ < 14pt 太字）	4.5 : 1	7 : 1
大きなテキスト（≥ 18pt ／ ≥ 14pt 太字）	3 : 1	4.5 : 1
UI コンポーネントおよび図形オブジェクト	3 : 1	—

仕様ではなく、実際にレンダリングされたページでコントラストを確認してください（dembrandt engine、任意）。 実際のテキストが実際の背景、グラデーション、オーバーレイに載ると、デザイン時の色見本は当てになりません。get_findings ／ render_report は実際の DOM を対象に実行され、コントラスト比を測定したうえで、基準に満たないテキストと背景の組み合わせを示します。静的なカラーパレットの確認では見落とす組み合わせをすばやく見つける方法です。詳細は extract-design を参照してください。

無効な要素は対象外です。 WCAG では、非アクティブな UI コンポーネントをコントラスト要件の対象から明示的に除外しています（WCAG 1.4.3 の例外）。無効なボタンにコントラストの低いテキストを使うのは意図的であり、利用できない状態を伝えるものとして適切です。

情報を伝える手段として色だけを使わないでください（例：エラーを示すのに赤い枠線だけを使うのではなく、アイコンやテキストラベルを追加します）。

ウェイトも読みやすさを左右しますが、コントラスト比では考慮されません。 コントラストの計算式が測るのは、文字色と背景色の差だけです。同じ色相なら、極細のウェイトも太いウェイトも同じ評価になりますが、実際の読みやすさは色とウェイトの両方で決まります。そのため、パレットで最も淡くても読める色と、文字サイズ体系で最も細いウェイトを同じテキストに使ってはいけません。キャプション、ラベル、補助テキストに使うミュートカラーやセカンダリトークンは、本文のデフォルトがレギュラーまたはライトで表示される場合、少なくとも 500 のウェイトを使います。この下限はチーム内のルールであり、WCAG の要件ではありません。 規格はウェイトについて何も定めていないため、まさにその理由で監査をすり抜けます。暗い背景で同じことが起きる仕組みについては [[color-mode-and-theme]] を参照してください。ミュートカラーはすでにパレットの中で最も控えめな選択肢であり、それに最も細いウェイトを組み合わせると、どちらも「目立たなくする」方向の選択が重なります。その結果、キャプションサイズのテキストは、監査では合格と報告されても、読者が意識して努力しないと読めないものになります。

テキストによる代替

• 意味のある画像には、その内容または機能を説明する alt テキストが必要です
• 装飾用画像には alt="" を指定し、スクリーンリーダーが読み飛ばせるようにします
• ボタンとして使うアイコンには、aria-label または視覚的に隠したテキストによるアクセシブルなラベルが必要です
• グラフやデータビジュアライゼーションには、テキストによる概要または代替となるデータテーブルが必要です

字幕とトランスクリプト

• 動画コンテンツには字幕が必要です
• 音声のみのコンテンツにはトランスクリプトが必要です

---

操作可能

ユーザーがすべての UI コンポーネントを操作できる必要があります。

キーボードナビゲーション

すべてのインタラクティブ要素に、キーボードだけで移動して操作できる必要があります。

• すべてのボタン、リンク、入力欄、コントロールは、Tab キーでフォーカスできる必要があります
• フォーカス順序は、ページの視覚的な読み取り順に沿う必要があります
• キーボードトラップを設けてはいけません。ユーザーがどのコンポーネントからも移動できる必要があります
• モーダルダイアログは、開いている間はフォーカスを内部に閉じ込め、閉じるときは起動元の要素にフォーカスを戻す必要があります

フォーカスの可視性

すべてのインタラクティブ要素には、視認できるフォーカスインジケーターが必要です（WCAG 2.2では、フォーカスの可視性に関する要件が強化されています）。

/* Minimum: do not remove focus outline without a replacement */
:focus-visible {
  outline: 2px solid var(--color-focus);
  outline-offset: 2px;
}

カスタムのフォーカススタイルを用意せずに、outline: noneを使用しないでください。フォーカスリングは取り除くべきデザイン上の問題ではなく、ナビゲーションのためのツールです。

タッチターゲットのサイズ

タッチデバイス上のインタラクティブ要素は、少なくとも24×24px（WCAG 2.2）にする必要があります。快適に操作できる推奨最小サイズは44×44pxです（Apple HIG、Material Design）。小さなアイコンボタンは、表示されるアイコンが小さくても、このサイズを満たすようにパディングが必要です。

発作を誘発しない

画面上で、1秒間に3回を超えて点滅するものがあってはなりません。

スキップリンク

ナビゲーションが繰り返し表示されるページでは、キーボードユーザーが各ページのナビゲーションをスキップできるように、最初にフォーカス可能な要素として「メインコンテンツへスキップ」リンクを用意する必要があります。

---

理解しやすさ

ユーザーがコンテンツとUIの操作方法を理解できる必要があります。

言語

• <html>要素にlang属性を設定します：<html lang="fi">または<html lang="en">
• インラインコンテンツの言語が異なる場合は、その要素にlangを指定します

ラベルと説明

• すべてのフォーム入力には、プレースホルダーだけでなく、視認できるラベルが必要です（プレースホルダーは入力すると消えます）
• 必須フィールドを明示する必要があります。色だけに頼らず、アスタリスクと凡例を追加してください
• エラーメッセージはaria-describedbyを使って該当する入力に関連付ける必要があります

予測可能性

• 同じように見えるコンポーネントは、同じように動作する必要があります（「一貫性と規格」を参照）
• ナビゲーションはすべてのページで同じ位置に表示する必要があります
• 新しいタブやウィンドウを開く場合は、事前に伝える必要があります

エラーの特定

• フォームの検証エラーでは、どのフィールドに問題があったかを特定する必要があります
• エラーは、色やアイコンだけでなく、テキストで説明する必要があります

---

堅牢性

支援技術がコンテンツを確実に解釈できる必要があります。

セマンティックHTML

目的に合ったHTML要素を使用します。セマンティクスによって、スクリーンリーダーに役割、状態、構造が自動的に伝わります。

<button>Save</button>
<nav aria-label="Main navigation">...</nav>
<h1>Page title</h1>


<div onclick="save()">Save</div>
<div class="nav">...</div>
<div class="heading">Page title</div>

ARIA — 必要最小限に使用

ARIAは、ネイティブ要素だけでは不十分な場合にHTMLのセマンティクスを補います。壊れたHTMLを修正するものではありません。

ルール：誤ったARIAを使うより、ARIAを使わないほうが適切です。 誤ったARIAは、スクリーンリーダーの出力を実際に損ないます。

必要なパターン：

• 視認できるテキストラベルがないコンポーネントには、aria-labelまたはaria-labelledbyを指定します
• トグル、アコーディオン、ドロップダウンにはaria-expandedを指定します
• 動的コンテンツの更新（トースト通知、検索結果）にはaria-live領域を使用します
• モーダルオーバーレイには、aria-modal="true"を指定したrole="dialog"を使用します
• 現在のナビゲーション項目にはaria-current="page"を指定します

ステータスメッセージ

動的な更新（成功トースト、読み込み状態、エラー数）は、aria-liveまたはrole="status"を使ってスクリーンリーダーに通知する必要があります。フォーカス中の要素が変化しない限り、自動的には通知されません。

---

無効な要素の例外

WCAG 1.4.3には、次のように明記されています。「非アクティブなユーザーインターフェースコンポーネントの一部であるテキストまたは文字画像には、コントラスト要件はありません。」

つまり、次のとおりです。

• 無効なボタン、入力、リンクには、コントラストの低いテキストや色を使用できます
• 無効状態を視覚的に薄く表示することは適切であり、基準にも準拠しています
• 無効な要素に人為的にコントラストを加えないでください。コントラストを下げることで、「利用できない」ことを伝えます

---

レビューチェックリスト

領域	確認事項
コントラスト	アクティブなテキストはすべて、コントラスト比が 4.5:1 以上（通常サイズ）または 3:1 以上（大きな文字／UI）である
コントラスト	無効な要素は対象外です。意図的にコントラストを低くしても問題ありません
色	色だけで情報を伝えていない
キーボード	すべてのインタラクティブ要素にキーボードでアクセスし、操作できる
フォーカス	すべてのインタラクティブ要素に視認できるフォーカスインジケーターがある
タッチ	タッチ操作面で、インタラクティブなターゲットのサイズが 44×44px 以上である
ラベル	すべての入力欄に視認できるラベルがある（プレースホルダーだけではない）
エラー	検証エラーで対象のフィールドを特定し、問題をテキストで説明している
HTML	セマンティック要素を正しく使用し、ARIA は必要な場合にのみ使用している
言語	<html> に lang 属性が設定されている
スキップリンク	「メインコンテンツへスキップ」が最初にフォーカス可能な要素である
ライブリージョン	動的な更新が aria-live または role="status" で通知される