accessibility

Webアクセシビリティ

アクセシビリティは品質特性であり、最後に付け足す機能ではありません。マークアップの最初の一行から考慮してください。アクセシブルなインターフェースは、視覚、運動、聴覚、認知に障害のある人が、アプリケーションを知覚し、操作し、利用できるようにします。また、キーボードを多用するユーザー、接続速度が遅い人、一時的なけがをしている人、制約のある環境にいるすべての人にも役立ちます。

アクセシビリティが重要な理由

観点	影響
法的	多くの地域の法律（ADA、EAA、Section 508、EN 301 549）では、デジタル製品にアクセシビリティを求めています。準拠しない場合、訴訟リスクや金銭的な罰則が生じます。
倫理的	世界人口のおよそ16％が何らかの障害を抱えて暮らしています。デジタルサービスから彼らを排除することは、避けられないことではなく、選択です。
ビジネス	アクセシブルな製品はより幅広いユーザーに届き、SEOを改善し（構造化されたコンテンツはクローラーに役立ちます）、サポートコストを削減します。また、総合的なユーザビリティスコアの向上とも相関しています。
技術的品質	アクセシビリティの制約によって、クリーンなマークアップ、適切なセマンティクス、関心の分離が促され、保守性が向上します。

---

WCAGの原則：POUR

Web Content Accessibility Guidelinesでは、すべての達成基準が4つの原則に分類されています。あらゆるアクセシビリティ要件は、少なくとも1つの原則に対応します。

原則	問いかける内容	例
知覚可能	ユーザーはコンテンツを感知できますか？	画像のテキスト代替、動画の字幕、十分な色のコントラスト、サイズ変更可能なテキスト
操作可能	ユーザーはすべてのコントロールを操作できますか？	キーボードでの操作、タスク完了に十分な時間、発作を引き起こすアニメーションがないこと、明確なナビゲーション
理解可能	ユーザーはコンテンツとUIの動作を理解できますか？	読みやすい言葉、予測可能なナビゲーション、入力支援とエラーメッセージ
堅牢	支援技術でも利用できますか？	有効なマークアップ、適切なARIAの使用、スクリーンリーダーなどのツールとの互換性

---

適合レベル

WCAGでは3つのレベルを定めています。上位のレベルには、それより下位のレベルの達成基準がすべて含まれます。

レベル	対象	典型的な要件
A	最低限の水準で、最も深刻な障壁を取り除きます	法的要件や調達要件の多くは、ここから始まります
AA	業界標準で、ほとんどのユーザーにとって大半の障壁に対処します	ADA、EAA、Section 508、およびほとんどの組織のポリシーで求められます
AAA	最高水準ですが、すべての種類のコンテンツで達成できるとは限りません	目標として掲げ、実現可能な範囲で選択的に適用します

ほとんどのプロジェクトでは、レベルAAを目標にしてください。現実のニーズの大半を満たし、一部のコンテンツ形式と相反する要件を避けられます。

---

セマンティックHTMLの基本

ネイティブHTML要素には、組み込みのセマンティクス、キーボード操作、スクリーンリーダーによる読み上げがあります。適切な要素を使うことは、最も効果的なアクセシビリティ手法です。

代わりに	使用する	理由
<div onclick="...">	<button>	ボタンはフォーカス可能で、役割が読み上げられ、EnterキーとSpaceキーに反応します
<span class="link">	<a href="...">	リンクは「リンク」と読み上げられ、中クリックに対応し、リンク一覧にも表示されます
<div class="header">	<header>、<nav>、<main>、<footer>	ランドマーク要素を使うと、スクリーンリーダーのユーザーはページ内の領域間を移動できます
<div class="list">	<ul> / <ol> と <li>	リストでは項目数と位置（「7項目中3番目」）が読み上げられます
<div class="table">	<th>を含む<table>	表の見出しは、データセルとそのラベルを関連付け、スクリーンリーダーで認識できるようにします
入力用にスタイルを設定した<div>	<input>、<select>、<textarea>	ネイティブのフォームコントロールには、ラベルとの関連付け、入力検証、支援技術への対応が組み込まれています

見出しの階層

見出しは目次のようなアウトラインを作成し、スクリーンリーダーの利用者はそれを使って移動します。

• ページの目的を説明する<h1>をページごとに1つだけ使用します
• 階層を飛ばさないでください（<h2>から<h4>へ移動しないでください）
• 見出しは構造を示すために使用し、見た目を整えるためには使用しないでください。外観はCSSで調整します

---

よくあるアクセシビリティの問題

問題	影響	対処法
画像の代替テキストがない	スクリーンリーダーがファイル名を読み上げるか、何も読み上げません	説明的なaltを追加します。装飾のみの画像にはalt=""を使用します
色のコントラストが不十分	弱視の利用者がテキストを読めません	通常のテキストでは4.5:1、大きなテキストでは3:1の比率（AA）を満たします
インタラクティブ要素をキーボードで操作できない	キーボードやスイッチを使う利用者は完全に操作できません	ネイティブのインタラクティブ要素を使用するか、tabindex="0"とキーイベントハンドラーを追加します
フォームのラベルがない	スクリーンリーダーが入力欄の用途を読み上げられません	for／idで関連付けるか、ラベルで囲んで、すべての入力欄を<label>に関連付けます
メディアが自動再生される	スクリーンリーダーの利用者を混乱させ、認知障害のある利用者に害を及ぼす可能性があります	自動再生は使用しないでください。避けられない場合は、視認できる一時停止／停止コントロールを用意します
スキップリンクがない	キーボード利用者はページごとにナビゲーション全体をTabキーで移動する必要があります	最初にフォーカス可能な要素として、メインコンテンツへのスキップリンクを追加します
フォーカスインジケーターがない	キーボード利用者はページ上の現在位置を見失います	目に見える独自の代替表示を用意せずにoutlineを削除しないでください
ページの言語が指定されていない	スクリーンリーダーがコンテンツを誤って発音することがあります	<html>にlang属性を設定します（例：lang="en"）
動的コンテンツがアクセシブルでない	スクリーンリーダーは、ページ読み込み後に発生した変更を読み上げません	ARIAライブリージョンを使用して動的な更新を読み上げます
ドキュメントタイトルがない	スクリーンリーダーの利用者は、タブを切り替えたときにページを特定できません	すべてのページに固有で説明的な<title>を設定します
タッチターゲットが小さすぎる	運動機能に障害のある利用者は、小さなコントロールを確実にタップできません	最小サイズは24x24 CSSピクセル（AA）です。快適に操作できるよう、44x44を推奨します
動きやアニメーション	めまい、吐き気、発作を引き起こすことがあります	prefers-reduced-motionメディアクエリに従い、1秒間に3回を超えて点滅させないでください

---

アクセシブルなフォーム

アクセシビリティの問題が最も深刻な影響を及ぼすのはフォームです。利用者が購入、登録、その他の重要なワークフローを完了できなくなる可能性があります。

ラベルの関連付け

すべてのフォームコントロールに、プログラムから関連付けられたラベルが必要です。

<label for="email">Email address</label>
<input type="email" id="email" name="email" required>


<label>
  Email address
  <input type="email" name="email" required>
</label>

エラー処理

• エラーはフォームの先頭だけでなく、該当するフィールドの横にインラインで表示します
• aria-describedbyを使用して、エラーメッセージを入力欄に関連付けます
• バリデーションに失敗したフィールドにはaria-invalid="true"を使用します
• 明確で具体的なエラーテキストを記述します（「入力が無効です」ではなく、「[email protected]の形式でメールアドレスを入力してください」）

必須フィールド

• 必須フィールドにはrequired属性（ネイティブのバリデーション）またはaria-required="true"（カスタムバリデーション）を設定します
• 必須であることを色やアスタリスクだけで示さないでください。「（必須）」などのテキストを追加します

---

色とコントラスト

情報を伝える際に、色だけに頼ってはいけません。テキスト、アイコン、パターン、その他の視覚的な手がかりと組み合わせてください。

コントラスト比（WCAG AA）：

要素	最低比率
通常のテキスト（18pt未満／太字14pt未満）	4.5:1
大きなテキスト（18pt以上／太字14pt以上）	3:1
UIコンポーネントと図形オブジェクト	3:1

すぐにできる改善策：

• ブラウザーの開発者ツールでコントラストを確認します（Chrome DevToolsではホバー時に比率が表示されます）
• ダークモードに対応するため、prefers-color-schemeに従います
• 色覚シミュレーション（1型色覚、2型色覚、3型色覚）を使ってデザインをテストします

---

リファレンスファイル

リファレンス	内容
ARIA パターン	ARIA を使用するタイミング、ロールとプロパティ、ウィジェットのパターン（タブ、モーダル、アコーディオン、ドロップダウン）、ライブリージョン、ランドマークロール
キーボードとフォーカス	Tab の順序、矢印キーによるナビゲーション、フォーカストラップ、スキップリンク、フォーカスの復元、視認可能なフォーカスインジケーター、タッチターゲット
テスト戦略	自動化ツール、手動テストのチェックリスト、スクリーンリーダーのテスト、コントラストの検証、アクセシビリティツリー、CI との統合

---

他のスキルとの連携

状況	推奨スキル
アクセシブルなエラーレスポンスを備えた REST API または GraphQL API の構築	api-design
アクセシビリティに影響するセキュリティヘッダー（CSP、iframe の制限）	security
ユニットテストと統合テストによるアクセシブルなコンポーネントのテスト	testing
アクセシビリティを損なわないパフォーマンス最適化	performance