Webアクセシビリティ対応ガイド｜WCAG準拠の進め方と具体的な改善ポイント

Webアクセシビリティとは

Webアクセシビリティとは、障がいのある人や高齢者を含む、すべての人がWebサイトやWebアプリケーションを利用できるようにすることです。

「アクセシビリティ＝障がい者対応」と思われがちですが、実際にはもっと広い概念です。スマホの小さな画面で操作する人、騒がしい場所で動画を見る人、腕を骨折してマウスが使えない人——こうした一時的・状況的な制約も含めて、誰もがコンテンツにアクセスできる状態を目指します。

なぜ今アクセシビリティが重要なのか

• 法的義務の拡大 — 2024年4月の障害者差別解消法改正で、民間企業にも合理的配慮の提供が義務化
• 市場の拡大 — 日本の65歳以上人口は約3,600万人（総人口の約29%）。高齢者にも使いやすいサイトは市場を広げる
• SEOとの親和性 — Googleはアクセシビリティの高いサイトを評価。alt属性、見出し構造、セマンティックHTMLはSEOにも有効
• ブランド価値 — アクセシビリティへの取り組みは企業の社会的責任（CSR）として評価される

WCAG 2.2の基本 — 4原則と達成基準

WCAG（Web Content Accessibility Guidelines）は、W3C（World Wide Web Consortium）が策定するWebアクセシビリティの国際基準です。最新版はWCAG 2.2（2023年10月勧告）です。

4つの原則

達成基準のレベル

• レベルA — 最低限の基準。これを満たさないと一部のユーザーが全く使えない
• レベルAA — 推奨レベル。多くの国や企業がこれを目標にしている。JIS X 8341-3でも「適合レベルAA」を推奨
• レベルAAA — 最も厳しい基準。サイト全体での達成は現実的でないため、可能な部分で対応

中小企業のWebサイトでは、まずレベルAAを目標にするのが現実的です。

障害者差別解消法の改正と企業の対応

2024年4月に施行された改正障害者差別解消法のポイントは以下のとおりです。

• 改正前 — 民間企業の合理的配慮は「努力義務」
• 改正後 — 民間企業の合理的配慮が「法的義務」に格上げ

「合理的配慮」とは、障がいのある人から求められた場合に、過重な負担にならない範囲で対応することです。Webサイトに関しては、代替手段の提供（電話対応等）や、段階的なアクセシビリティ改善が求められます。

現時点でWebサイトのWCAG準拠が直接義務付けられているわけではありませんが、総務省は「みんなの公共サイト運用ガイドライン」でJIS X 8341-3（WCAG 2.0ベース）のレベルAA準拠を推奨しており、今後の法制化も見据えて対応を進めるのが賢明です。

具体的な改善ポイント

画像のアクセシビリティ

• alt属性を必ず設定 — 装飾画像は alt=""（空）、情報を伝える画像は内容を説明するaltを設定
• グラフ・図解 — alt属性だけでなく、テキストでもデータの要約を提供
• テキストの画像化を避ける — 見出しや本文をテキストではなく画像にすると、スクリーンリーダーで読めない

色とコントラスト

• 文字と背景のコントラスト比 — 通常テキストは4.5:1以上、大きな文字は3:1以上（WCAG AA基準）
• 色だけで情報を伝えない — 「赤い項目はエラー」ではなく、アイコンやテキストも併用する
• リンクの識別 — リンクテキストを色だけでなく、下線や太字でも区別可能にする

キーボード操作

• Tabキーで全要素にアクセス可能 — フォーム、ボタン、リンク、メニューをキーボードだけで操作できるか
• フォーカスインジケーター — 現在フォーカスされている要素が視覚的に分かるようにする（outlineを消さない）
• キーボードトラップの回避 — モーダルやドロップダウンに入ったら出られない、という状態を防ぐ
• スキップリンク — ページ先頭に「本文へスキップ」リンクを設置。キーボードユーザーがナビゲーションを飛ばせる

フォーム

• ラベルの紐付け — label要素とinput要素をfor属性で紐付ける
• エラーメッセージ — エラーの内容と修正方法を具体的に伝える。「入力エラー」ではなく「メールアドレスの形式が正しくありません」
• 必須項目の明示 — 「*」だけでなく「必須」とテキストで表示。色だけで必須を示さない
• 入力補助 — autocomplete属性の設定で、ブラウザの自動入力を支援

見出し・構造

• 見出しの階層を正しく使う — h1→h2→h3の順序を守る。見た目の大きさだけで見出しレベルを選ばない
• ランドマーク — header、nav、main、footer等のHTML5セマンティック要素を使い、ページの構造を明確にする
• リスト — 箇条書きにはul/ol/liを使う。div+CSSで見た目だけリストにしない

動画・音声

• 字幕の提供 — 動画には必ず字幕（クローズドキャプション）を付ける
• 音声解説 — 映像だけで伝えている情報を音声でも説明（レベルAA）
• 自動再生の禁止 — 音声を含むメディアの自動再生を避ける。再生する場合は停止ボタンを用意

アクセシビリティチェックツール

自動チェックツール

自動チェックで検出できるのはWCAG違反の約30〜40%と言われています。残りは人手によるチェックが必要です。

手動チェックのポイント

• キーボードだけで操作テスト — マウスを使わずにサイト全体を操作してみる
• スクリーンリーダーでの確認 — VoiceOver（Mac/iOS）やNVDA（Windows、無料）で読み上げテスト
• ブラウザの拡大表示 — 200%拡大でもレイアウトが崩れないか確認
• カラーコントラストチェッカー — WebAIM Contrast Checkerで色の組み合わせを確認

アクセシビリティ対応の進め方

1. 現状の把握 — Lighthouseとaxe DevToolsで現在のスコアと問題を把握
2. 優先順位の決定 — レベルAの項目から着手。影響度の高い問題を優先
3. ガイドラインの策定 — 社内のコーディングルールにアクセシビリティ基準を組み込む
4. 改善の実施 — 新規開発は最初からアクセシビリティ対応、既存サイトは段階的に改善
5. 定期的な監査 — 四半期ごとにアクセシビリティスコアを計測し、改善を継続

まとめ

• Webアクセシビリティは「特別な対応」ではなく「品質の一部」。すべてのユーザーが使えるサイトを目指す
• WCAG 2.2のレベルAAが現実的な目標。レベルAから段階的に対応
• 障害者差別解消法の改正で民間企業も対応が義務に。早期の対応が望ましい
• まずは3つから：画像のalt属性、色のコントラスト、キーボード操作
• 自動ツール＋手動チェックで品質を確保。Lighthouse・axe DevToolsは無料で使える
• 新規開発は最初から対応、既存は段階的に改善。完璧より継続

Webアクセシビリティ対応やUI/UX改善のご相談は、お問い合わせからお気軽にどうぞ。FUNBREWでは、アクセシビリティを考慮したWeb制作・システム開発をサポートしています。