Webアクセシビリティとは、障がいのある方や高齢者を含むすべてのユーザーが、Webサイトの情報にアクセスし、操作できるようにすることを指します。視覚障がい、聴覚障がい、運動障がい、認知障がいなど、さまざまな特性を持つ方がWebを利用しており、こうした方々が不便なく利用できるサイト制作は、もはや「配慮」ではなく「必須要件」になりつつあります。
日本では障害者差別解消法の改正により、民間事業者にも合理的配慮の提供が義務化されました。Webサイトのアクセシビリティ対応は法的リスクの回避だけでなく、ユーザー層の拡大やSEO効果にもつながる重要な取り組みです。
この記事では、Webアクセシビリティの基本概念からWCAGの具体的な対応ポイント、実務で使えるチェック方法までを解説します。
WCAGとは？4つの原則と適合レベル
WCAGの概要
WCAG（Web Content Accessibility Guidelines）は、W3C（World Wide Web Consortium）が策定した国際的なWebアクセシビリティのガイドラインです。現在広く参照されているのはWCAG 2.1およびWCAG 2.2で、MDN Web Docsでも詳しい解説が公開されています。
WCAG 2.2は2023年10月にW3C勧告として公開され、認知障がいのある方やタッチ操作に依存する方への配慮を強化する9つの新しい達成基準が追加されました。
4つの原則（POUR）
WCAGは以下の4つの原則に基づいて構成されています。
- Perceivable（知覚可能）：情報やUIコンポーネントが、ユーザーに知覚できる形で提示されていること。画像にalt属性を付ける、動画に字幕を付けるなど
- Operable（操作可能）：UIコンポーネントやナビゲーションが操作可能であること。キーボードだけですべての操作ができる、十分な操作時間が確保されているなど
- Understandable（理解可能）：情報やUIの操作方法が理解できること。一貫したナビゲーション、エラーの特定と修正のサポートなど
- Robust（堅牢）：さまざまな支援技術（スクリーンリーダーなど）で正しく解釈できること。正しいHTMLマークアップ、WAI-ARIAの適切な使用など
3段階の適合レベル
WCAGには達成基準ごとにA、AA、AAAの3段階の適合レベルが設定されています。
- レベルA：最低限のアクセシビリティ。これを満たさないと、一部のユーザーがサイトをまったく利用できない可能性がある
- レベルAA：標準的なアクセシビリティ。多くの公的機関や企業が目標とするレベル
- レベルAAA：最高レベルのアクセシビリティ。サイト全体での準拠は難しいが、可能な範囲で目指す
一般的な企業サイトでは、レベルAAの準拠を目標にすることが推奨されています。デジタル庁もJIS X 8341-3:2016とWCAG 2.2の両方を指標として活用しています。
日本ではWCAG 2.2に対応するJIS規格はまだ整備されておらず、「JIS X 8341-3:2016」が利用されています。ただし、JIS X 8341-3:2016はWCAG 2.0をベースとしているため、WCAG 2.1や2.2の新しい達成基準は含まれていません。グローバルな基準に合わせるなら、WCAG 2.2を直接参照するのが確実です。
すぐに取り組めるアクセシビリティ対応
画像にalt属性を正しく設定する
画像のalt属性は、スクリーンリーダーが画像の内容を読み上げる際に使用されます。装飾目的の画像にはalt=””（空文字）を設定し、情報を伝える画像には適切な説明文を記述しましょう。
- 良い例：
alt="オフィスで会議中の3名のビジネスパーソン" - 悪い例：
alt="画像"alt="img001.jpg"
十分なカラーコントラストを確保する
テキストと背景色のコントラスト比は、WCAG 2.2のレベルAAでは以下の基準を満たす必要があります。
- 通常テキスト（18px未満）：コントラスト比4.5:1以上
- 大きなテキスト（18px以上、または14px以上で太字）：コントラスト比3:1以上
薄いグレーのテキストや淡い背景色の上のテキストは、見た目がおしゃれでもコントラスト比が不足している場合が多いため注意が必要です。
キーボード操作への対応
マウスを使用できないユーザーのために、Tabキーでのフォーカス移動、Enterキーでの実行、Escキーでの閉じる操作など、キーボードだけですべての機能にアクセスできるようにする必要があります。特に注意すべきポイントは以下の通りです。
- フォーカス順序が論理的であること（DOMの順序と視覚的な順序が一致していること）
- フォーカスインジケーター（アウトライン）が見えること。
outline: none;で消してしまうのはNG - カスタムコンポーネント（ドロップダウン、モーダルなど）もキーボードで操作できること
適切なHTML構造（セマンティックHTML）
見出しタグ（h1〜h6）を適切な階層で使用し、ナビゲーションには<nav>、メインコンテンツには<main>、補足情報には<aside>といったセマンティックなHTML要素を使うことで、スクリーンリーダーがページ構造を正確に把握できるようになります。
フォームのアクセシビリティ対応
ラベルとフォームコントロールの紐付け
すべてのフォーム入力要素には、対応するラベルを紐付ける必要があります。<label>要素のfor属性と<input>要素のid属性を一致させることで、スクリーンリーダーがフォームの入力内容を正しく読み上げられるようになります。
プレースホルダーをラベルの代わりに使用するのは避けましょう。プレースホルダーは入力を始めると消えてしまうため、何を入力すべきか分からなくなる問題があります。
エラーメッセージの伝え方
フォームのエラーは色だけで伝えてはいけません。赤い枠線だけでエラーを示すと、色覚特性のあるユーザーにはエラーが認識できません。テキストによるエラーメッセージ、アイコンの追加、エラー箇所へのフォーカス移動など、複数の手段でエラーを伝えましょう。
入力補助の提供
必須項目の明示、入力形式の説明（例：「半角英数字8文字以上」）、入力候補の表示（オートコンプリート）など、ユーザーが正しく入力できるための補助を提供することもアクセシビリティの重要な要素です。
アクセシビリティのチェック方法
自動チェックツール
手作業ですべてのアクセシビリティ基準をチェックするのは現実的ではありません。以下の自動チェックツールを活用して効率的に問題を検出しましょう。
- Lighthouse：Chrome DevToolsに内蔵されたパフォーマンス・アクセシビリティ監査ツール。アクセシビリティスコアと改善提案を表示してくれる
- axe DevTools：axe DevToolsはブラウザ拡張機能として利用でき、WCAG 2.2の達成基準に基づいた詳細なチェックが可能
- WAVE：Webページのアクセシビリティ問題を視覚的にハイライト表示するツール。エラー箇所とその理由が一目で分かる
手動チェックのポイント
自動ツールでは検出できない問題もあります。以下の手動チェックは必ず実施しましょう。
- キーボード操作テスト：マウスを使わず、Tab、Enter、Escキーだけでサイト全体を操作してみる
- スクリーンリーダーテスト：NVDAやVoiceOverを使って、ページの内容が正しく読み上げられるか確認する
- ズームテスト：ブラウザのズームを200%まで拡大し、テキストが重ならず読めるか確認する
自動チェックツールで検出できるアクセシビリティの問題は、全体の30〜40%程度と言われています。「ツールのスコアが100点だからアクセシビリティは完璧」と考えるのは危険です。キーボード操作やスクリーンリーダーによる実際の利用テストを組み合わせて、総合的に評価することが重要です。
アクセシビリティ対応のビジネスメリット
ユーザー層の拡大
日本には約964万人の障がい者がおり、高齢者を含めるとアクセシビリティの恩恵を受ける方はさらに多くなります。アクセシビリティ対応はユーザー層を広げ、サイトの利用者数を増やす施策として捉えることができます。
SEOへの好影響
アクセシビリティ対応の多くは、SEOの改善にも直結します。適切なalt属性の設定、セマンティックなHTML構造、見出しの階層構造、ページタイトルの適切な設定などは、検索エンジンがページの内容を正しく理解するためにも重要な要素です。
法的リスクの回避
海外ではアクセシビリティに関する訴訟が増加しており、日本でも障害者差別解消法の改正により事業者の対応義務が強化されています。先手を打ってアクセシビリティに対応しておくことは、法的リスクの回避につながります。
よくある質問（Q&A）
Q：アクセシビリティ対応はどこから始めればよいですか？
A：まずは画像のalt属性の確認、カラーコントラストのチェック、キーボード操作テストの3つから始めるのがおすすめです。Lighthouseでアクセシビリティスコアを測定し、指摘された問題を優先度の高いものから順に修正していくと効率的です。
Q：既存のサイトをアクセシビリティ対応にする場合、全ページを一度に修正する必要がありますか？
A：一度にすべてを対応する必要はありません。トップページ、問い合わせフォーム、主要なサービスページなど、利用頻度の高いページから段階的に対応を進めるのが現実的です。新しく作成するページからWCAG準拠を意識し、既存ページは計画的に改善していきましょう。
Q：WCAGのレベルAAAを目指すべきですか？
A：レベルAAAは非常に厳格な基準であり、サイト全体での準拠を目標にする必要はありません。まずはレベルAAの達成を目標にし、可能な部分でレベルAAAの基準も取り入れるという方針が現実的です。
Q：アクセシビリティ対応するとデザインの自由度が下がりませんか？
A：コントラスト比の確保など一定の制約はありますが、創造的なデザインとアクセシビリティは両立可能です。むしろ、制約の中で工夫することでデザインの質が向上するケースも多くあります。Appleの製品デザインがアクセシビリティと高いデザイン性を両立している良い例です。
Q：WAI-ARIAとは何ですか？
A：WAI-ARIA（Web Accessibility Initiative – Accessible Rich Internet Applications）は、HTMLだけでは伝えきれない情報を支援技術に伝えるための仕様です。カスタムコンポーネントの役割（role属性）、状態（aria-expanded、aria-selectedなど）、プロパティ（aria-labelなど）を定義することで、スクリーンリーダーが正しく解釈できるようになります。
まとめ
Webアクセシビリティの対応は、WCAGの4つの原則（知覚可能・操作可能・理解可能・堅牢）を理解するところから始まります。alt属性の設定、カラーコントラストの確保、キーボード操作への対応、セマンティックなHTML構造の採用は、すべてのWebサイトで実施すべき基本的な対応です。
アクセシビリティは「特定の人のため」ではなく「すべてのユーザーのため」の取り組みです。LighthouseやaxeDevToolsなどの自動チェックツールと手動テストを組み合わせて、継続的にアクセシビリティの品質を向上させていきましょう。
