アクセシビリティとインクルーシブデザイン

アクセシビリティ——WCAG 2.1・コントラスト比・キーボード操作・スクリーンリーダー

アクセシビリティ（Accessibility）とは、障害の有無・年齢・環境を問わず、すべての人がウェブサイトやアプリを利用できる状態を実現することです。日本では2024年施行の改正障害者差別解消法により、民間企業にも合理的配慮の提供が義務化されました。アクセシビリティへの対応は「優しさ」ではなく、法的義務かつビジネス機会です。このレッスンでは、WCAG 2.1の構造、コントラスト比の測定方法、キーボード操作の実装、スクリーンリーダー対応、ARIA属性の実践的な使い方まで体系的に学びます。

---

アクセシビリティ対応全体図

アクセシビリティ — WCAG 2.1 / コントラスト比 / ARIA / キーボード操作

WCAG 2.1はLevel A・AA・AAAの3段階で構成されます。法的要件・実務的な対応目標としてはLevel AAが基準となります。

---

WCAG 2.1の4つの原則

WCAG（Web Content Accessibility Guidelines）は「知覚可能・操作可能・理解可能・堅牢」の4原則（POUR）に基づいています。

1. 知覚可能（Perceivable）

情報とUIコンポーネントを、ユーザーが知覚できる方法で提示しなければなりません。

主な達成基準

• ◆1.1.1 テキストによる代替（Level A）: 画像・アイコン・グラフなどの非テキストコンテンツには適切なalt属性を設定する
• ◆1.3.1 情報及び関係性（Level A）: 視覚的な構造（見出し・リスト・表）はHTMLセマンティクスで表現する
• ◆1.4.3 コントラスト（Level AA）: テキストと背景のコントラスト比を4.5:1以上にする
• ◆1.4.4 テキストのサイズ変更（Level AA）: ブラウザの文字サイズ設定を200%に変更しても内容が失われないようにする

2. 操作可能（Operable）

UIコンポーネントとナビゲーションは操作可能でなければなりません。

主な達成基準

• ◆2.1.1 キーボード操作（Level A）: すべての機能をキーボードのみで操作できるようにする
• ◆2.4.3 フォーカス順序（Level A）: フォーカスが意味のある順序で移動する
• ◆2.4.7 フォーカスの可視化（Level AA）: フォーカスがあたっている要素を視覚的に示す（outline を消してはいけない）
• ◆2.5.3 ラベルを名前に含める（Level A）: ボタンの表示テキストとアクセシブルな名前が一致する

3. 理解可能（Understandable）

情報とUIの操作方法は理解可能でなければなりません。

主な達成基準

• ◆3.1.1 ページの言語（Level A）: lang属性でページの言語を指定する（例：lang="ja"）
• ◆3.3.1 エラーの特定（Level A）: 入力エラーを自動検出し、ユーザーにテキストで通知する
• ◆3.3.2 ラベルまたは説明（Level A）: 入力フィールドには適切なラベルを関連付ける

4. 堅牢（Robust）

コンテンツは支援技術（スクリーンリーダー等）を含む多様なユーザーエージェントが確実に解釈できなければなりません。

主な達成基準

• ◆4.1.2 名前・役割・値（Level A）: UIコンポーネントの名前・役割・値はプログラムで判断可能にする
• ◆4.1.3 ステータスメッセージ（Level AA）: フォーカスを受け取らずに表示されるステータスメッセージもARIAで伝える

---

コントラスト比の設計と測定

コントラスト比はテキストと背景の明暗差を数値化したものです。数値が大きいほど見やすく、WCAG Level AAでは通常テキストに4.5:1以上が必要です。

コントラスト比の計算

コントラスト比 = （明るい色の輝度 + 0.05）÷（暗い色の輝度 + 0.05）

最大値は21:1（白地に黒文字）、最小値は1:1（同色）です。

WCAG AA基準の早見表

コントラスト確認ツール

⚠️ グレーテキストとプレースホルダーに注意: デザインでよく使われる薄いグレーのテキスト（#999999）を白背景に置くとコントラスト比は2.85:1でAAを満たしません。#767676以上の暗さが白背景でのAA達成の目安です。プレースホルダーテキストはWCAGの対象外ですが、高齢者やロービジョンのユーザーへの配慮として4.5:1を目指してください。

---

キーボード操作の実装

キーボードのみでウェブサイトを使うユーザーには、手や腕に障害のある方、マウスを使わない上級者（スクリーンリーダーユーザーを含む）などが含まれます。

フォーカス管理の基本

Tabキーでのフォーカス移動 Tabキーでフォーカスを前方移動、Shift+Tabで後方移動します。フォーカスの順序はDOM順（HTMLの記述順）に従うため、CSSで表示順を変えても実際のTab順はHTML構造に依存します。

フォーカス可視化の義務 CSSで「outline: none」を設定するとフォーカスが視覚的に消えます。これはLevel AAの達成基準2.4.7違反です。デザインと両立させるには独自のフォーカスリング（focus-visible CSS）を設計してください。

:focus-visible {
  outline: 3px solid #005fcc;
  outline-offset: 2px;
}

フォーカストラップ モーダルダイアログが開いている間は、Tabキーのフォーカスがモーダル外に出ないよう制御する必要があります（フォーカストラップ）。モーダルを閉じた後はモーダルを開いたボタンにフォーカスを戻してください。

キーボード操作パターン一覧

---

スクリーンリーダー対応

スクリーンリーダーは画面の内容を音声で読み上げるソフトウェアです。視覚障害のあるユーザーだけでなく、運転中・料理中など手がふさがっている状況でも使われます。

主要スクリーンリーダー

セマンティックHTMLが最強の武器

スクリーンリーダー対応の基本はARIA属性より先にセマンティックHTMLの正しい使用です。

• ◆見出しはh1〜h6の階層構造を守る（h1を複数使わない）
• ◆リストはul/ol/liで記述する
• ◆表にはcaption・thのscope属性を設定する
• ◆ナビゲーションはnav要素で囲む
• ◆フォームのラベルはlabel要素でfor属性により入力フィールドと関連付ける

---

ARIA属性の実践的な使い方

ARIAはセマンティックHTMLでは表現できない状態・役割・プロパティをスクリーンリーダーに伝えるための補助属性です。ARIAの原則は「No ARIA is better than bad ARIA」です。不正確なARIAは正確な情報を持たないよりも有害になる場合があります。

よく使うARIA属性

aria-label 要素のアクセシブルな名前を直接指定します。アイコンのみのボタン（閉じるボタン、検索ボタン）に必須です。

<button aria-label="検索">
  <svg>...</svg>
</button>

aria-labelledby 別の要素のIDを参照してアクセシブルな名前を設定します。ダイアログのタイトルに使います。

aria-expanded アコーディオン・ドロップダウンの開閉状態（true/false）をスクリーンリーダーに伝えます。JavaScriptで動的に更新してください。

aria-live 動的に変化するコンテンツ（トースト通知・検索結果の件数など）をスクリーンリーダーが自動で読み上げるよう指示します。aria-live="polite"は現在の読み上げが終わってから通知、aria-live="assertive"は即座に割り込んで読み上げます。

aria-hidden スクリーンリーダーに読み上げさせない要素（装飾アイコン・重複テキスト）に使います。aria-hidden="true"を設定します。

role属性 HTMLの意味と異なる役割を付与します。カスタムコンポーネント（divで作ったボタンなど）にrole="button"を指定しますが、可能な限り本来のbutton要素を使うことを優先してください。

ARIAデザインパターン（WAI-ARIA Authoring Practices）

W3CはARIAを使った主要コンポーネント（ダイアログ・タブ・アコーディオン・コンボボックスなど）の実装パターンを公式に公開しています（WAI-ARIA Authoring Practices Guide）。カスタムコンポーネントを実装する際は必ずこのガイドを参照してください。

💡 アクセシビリティ自動テストツールの限界: axe・Lighthouse等の自動テストで検出できるアクセシビリティ問題は全体の30〜40%に留まります。残りの60〜70%はキーボード操作の手動テストとスクリーンリーダーを使った実際の確認が必要です。自動テストに合格しても完全なアクセシビリティが保証されるわけではありません。

---

アクセシビリティ監査の手順

自動テスト

1. ◆Chrome DevToolsのLighthouseでアクセシビリティスコアを計測
2. ◆axe DevTools（ブラウザ拡張）でHTMLの問題点を検出
3. ◆Wave（ウェブアクセシビリティ評価ツール）でページ全体を視覚化

手動テスト

1. ◆マウスを使わずTabキーだけでページ全体のインタラクションを実行できるか確認
2. ◆VoiceOver（Mac）またはNVDA（Windows）を起動してページを読み上げさせ、重要情報が正確に伝わるか確認
3. ◆ブラウザのズームを200%に設定してレイアウトが崩れず内容が読めるか確認
4. ◆カラーブラインドネスシミュレーター（Figma Sim Daltonism等）で色だけに依存した情報伝達がないか確認

---

🏋️実践ワーク

以下のワークを実施してください。

1. ◆コントラスト比監査: 担当しているか普段使っているウェブサイトを開き、Chrome DevToolsのアクセシビリティパネルまたはaxeを使ってコントラスト比の問題を3つ見つけ、WCAGに準拠した代替カラーを提案する
2. ◆キーボードテスト: 任意のウェブサイトをマウスなしでTabキーだけ操作し、「フォーカスが見えない・Tabの順序がおかしい・キーボードで到達できない要素がある」の3種類の問題をそれぞれ1件ずつ探してスクリーンショットで記録する
3. ◆ARIA実装: Figmaで設計したモーダルダイアログのHTMLをコーディングし、role="dialog"・aria-labelledby・aria-modal・フォーカストラップ・Escキーで閉じる動作を実装してVoiceOverで読み上げを確認する
4. ◆アクセシビリティチェックリスト作成: このレッスンで学んだ内容をもとに、自分が今後のデザイン業務で使う「アクセシビリティデザインチェックリスト」を15項目作成し、各項目に「確認方法」を添える

📝まとめ

アクセシビリティは後付けで対応できるものではありません。設計の最初から「すべての人が使える」ことを前提とすることで、初めて本物のアクセシビリティが実現します。WCAG 2.1のLevel AAを基準とし、コントラスト比・キーボード操作・セマンティックHTML・ARIA属性の4本柱を押さえることで、障害のあるユーザーだけでなく、高齢者・スマートフォンユーザー・低速回線ユーザーを含むすべての人にとって使いやすいプロダクトが生まれます。アクセシビリティへの投資はユーザー全体の体験品質への投資です。