Webアクセシビリティとは、障害の有無に関わらず、すべての人がWebサイトやアプリケーションを利用できるようにすることです。2024年4月の障害者差別解消法改正により、日本でも合理的配慮の提供が義務化され、Webアクセシビリティへの関心が急速に高まっています。
この記事では、Webアクセシビリティの基礎知識から実践的な実装方法まで、エンジニア・デザイナーが知っておくべきポイントを解説します。
なぜWebアクセシビリティが重要なのか
WHOの統計によると、世界人口の約16%にあたる13億人が何らかの障害を持っています。視覚障害、聴覚障害、運動障害、認知障害など、Webの利用に影響する障害は多岐にわたります。
しかしアクセシビリティは障害者だけのためのものではありません。高齢者、一時的なケガをしている人、明るい日差しの下でスマホを使う人、片手がふさがっている人など、誰もが恩恵を受けます。
ビジネス面でもメリットは大きいです。アクセシブルなサイトはSEOにも好影響を与え、ユーザー体験の向上がコンバージョン率の改善につながります。また法的リスクの回避にもなります。
WCAG 2.2の4原則を理解する
Web Content Accessibility Guidelines（WCAG）は、W3Cが策定したWebアクセシビリティの国際基準です。最新版のWCAG 2.2は4つの原則で構成されています。
第1原則「知覚可能（Perceivable）」は、情報やUIコンポーネントをユーザーが知覚できる方法で提示することです。画像にalt属性をつける、動画に字幕をつける、テキストと背景のコントラスト比を確保するなどが含まれます。
第2原則「操作可能（Operable）」は、UIコンポーネントやナビゲーションを操作できることです。すべての機能をキーボードだけで操作できること、十分な操作時間を確保すること、発作を引き起こすコンテンツを避けることなどです。
第3原則「理解可能（Understandable）」は、情報やUIの操作方法が理解できることです。テキストが読みやすいこと、Webページの動作が予測可能であること、入力エラーの修正を支援することなどです。
第4原則「堅牢（Robust）」は、さまざまな支援技術（スクリーンリーダーなど）で正しく解釈できることです。セマンティックなHTMLを使い、ARIA属性を適切に活用することが求められます。
実践：セマンティックHTMLの書き方
アクセシビリティの基本はセマンティックHTMLです。適切なHTML要素を使うだけで、多くのアクセシビリティ問題を解決できます。
見出しはh1〜h6を階層的に使いましょう。h1の次にh3が来るような飛ばし方は避けます。スクリーンリーダーのユーザーは見出しでページ内を移動するため、適切な見出し構造はナビゲーションの要です。
ナビゲーション部分にはnav要素、メインコンテンツにはmain要素、補足情報にはaside要素を使います。これらのランドマーク要素によって、スクリーンリーダーのユーザーはページの構造を素早く把握できます。
ボタンにはbutton要素、リンクにはa要素を使い、div要素やspan要素で代用しないようにしましょう。button要素はキーボードフォーカスやEnterキーでの実行が自動的にサポートされます。
画像とメディアのアクセシビリティ
すべての画像にはalt属性を設定しましょう。情報を伝える画像には内容を説明するテキストを、装飾目的の画像にはalt=””（空のalt）を設定します。「画像」「写真」といった冗長な記述は避けてください。
動画コンテンツには字幕と音声解説を提供します。自動再生は避け、再生・停止・音量調整などのコントロールをユーザーに委ねましょう。AI動画編集ツールの中には字幕を自動生成する機能を持つものもあります。
フォームのアクセシビリティ
フォームはアクセシビリティの問題が発生しやすい領域です。すべてのフォーム入力にはlabel要素を関連付けましょう。for属性とid属性を使って明示的に紐付けるか、label要素で入力をラップします。
エラーメッセージはテキストで明確に表示し、どのフィールドに問題があるかを具体的に伝えます。色だけでエラーを表現しない（赤枠だけでなくテキストも表示する）ことが重要です。
必須項目は「*」だけでなく「必須」とテキストで明記します。入力形式の例（例：2026-01-01）を表示することで、すべてのユーザーにとって使いやすくなります。
色とコントラストの基準
テキストと背景のコントラスト比はWCAG AA基準で4.5:1以上（大きなテキストは3:1以上）が必要です。WebAIMのContrast Checkerやブラウザの開発者ツールで確認できます。
情報を色だけで伝えないことも重要です。グラフの凡例、フォームのエラー表示、リンクの区別など、色覚特性を持つユーザーのために形状やテキストでも区別できるようにします。Figma入門ガイドで紹介しているコントラストチェックプラグインも活用してください。
キーボード操作とフォーカス管理
すべてのインタラクティブ要素がTabキーで移動でき、Enter/Spaceキーで操作できることを確認しましょう。フォーカスの移動順序は視覚的な配置と一致させます。
フォーカスインジケータ（フォーカスリング）は非表示にしないでください。デフォルトのoutlineを消す場合は、代わりに視認性の高いカスタムフォーカススタイルを設定します。
モーダルダイアログを開いたときは、フォーカスをダイアログ内に閉じ込め（フォーカストラップ）、Escキーで閉じられるようにします。ダイアログを閉じた後は、開いたトリガー要素にフォーカスを戻します。
テストツールと検証方法
アクセシビリティの検証には自動テストと手動テストの両方が必要です。自動テストツールとしてはaxe DevTools、Lighthouse、WAVE Evaluation Toolが定番です。これらはHTMLの構造的な問題を検出してくれます。
ただし自動テストでは検出できない問題も多いため、手動テストも欠かせません。キーボードだけで操作してみる、スクリーンリーダー（VoiceOver、NVDA）で読み上げを確認する、ブラウザのズーム機能で200%まで拡大して表示が崩れないか確認するなど、実際の利用シーンを想定したテストが重要です。
CI/CD入門ガイドで紹介しているGitHub Actionsにaxeの自動テストを組み込めば、デプロイ前にアクセシビリティの問題を検出できます。
まとめ：アクセシビリティは品質の証
Webアクセシビリティは特別な機能ではなく、Web開発の品質基準の一つです。セマンティックHTML、適切なコントラスト、キーボード操作、alt属性の設定など、基本を押さえるだけで大きく改善できます。
まずは既存サイトをLighthouseでチェックし、スコアの低い項目から改善していきましょう。アクセシビリティへの配慮は、すべてのユーザーにとって使いやすいサイトを作ることにつながります。
コメント