フレームワーク活用ガイドひとことで言うと#
視覚・聴覚・運動機能・認知機能などの多様な特性を持つすべてのユーザーがプロダクトを問題なく使えるように設計するアプローチ。特別な配慮ではなく、すべての人にとって使いやすくなる「ユニバーサルな品質向上」。
押さえておきたい用語#
- WCAG（Web Content Accessibility Guidelines）
- W3Cが策定するWebアクセシビリティの国際基準。レベルA・AA・AAAの3段階があり、一般的にはAAの達成を目標にする。
- ARIA（Accessible Rich Internet Applications）
- スクリーンリーダーなどの支援技術に対し、UIの役割や状態を補足情報として伝えるための属性群。HTMLだけでは不足する情報を補完する。
- コントラスト比
- テキストと背景色の明度差を数値化した比率。WCAG AAでは通常テキスト4.5:1以上、大きいテキスト3:1以上が必要。
- フォーカスインジケーター
- キーボード操作時にどの要素が選択中かを示す視覚的なハイライト表示を指す。枠線や背景色の変化で実装する。
- 支援技術（Assistive Technology）
- スクリーンリーダーや音声入力、スイッチデバイスなど、障害のあるユーザーが情報にアクセスするための技術の総称である。
アクセシビリティデザインの全体像#
こんな悩みに効く#
- アクセシビリティ対応が必要だと聞くが、何から始めればいいかわからない
- 色覚多様性のあるユーザーへの配慮ができていない
- キーボードだけでサイトを操作できない
基本の使い方#
Webアクセシビリティの国際基準WCAG 2.1は4つの原則に基づいている。
- 知覚可能（Perceivable）: 情報がすべてのユーザーに知覚できる（テキスト代替、キャプション）
- 操作可能（Operable）: キーボードやスイッチなどあらゆる手段で操作できる
- 理解可能（Understandable）: コンテンツと操作が予測しやすく理解できる
- 堅牢（Robust）: 多様なブラウザや支援技術で正しく動作する
まずはレベルAA（中程度）を目標にする。完璧を求めず、今日からできることを始める。
最もインパクトが大きく、すぐに対応できる領域から始める。
- コントラスト比: テキストと背景のコントラスト比4.5:1以上（大きいテキストは3:1以上）
- 色だけに頼らない: エラーを赤色だけで示さず、アイコンやテキストも併用する
- テキスト代替: すべての画像に
alt属性。装飾画像は空のalt="" - フォントサイズ: ユーザーが拡大できるよう、rem/emで指定（px固定にしない）
ツール: コントラストチェッカー、Lighthouseのアクセシビリティ監査を定期的に実行。
マウスが使えないユーザーのために、すべての操作をキーボードだけで完了できるようにする。
- Tab/Shift+Tabでフォーカスが論理的な順序で移動する
- フォーカスインジケーター（枠線やハイライト）が視覚的に明確
- モーダルやドロップダウンにもキーボード操作を実装
- ARIAラベル: スクリーンリーダー向けにUI要素の役割と状態を伝える
実際にキーボードだけでサイトを操作してみると、多くの問題が見つかる。
具体例#
Before（未対応）:
- 入力欄にplaceholderしかなく、ラベルがない
- エラーが赤い枠線だけで示される
- 送信ボタンがdiv要素（キーボードで押せない）
- フォーカスの順序が見た目と異なる
After（対応済み）:
- ラベル:
<label for="email">メールアドレス</label>を各入力欄に紐付け - エラー表示: 赤色＋エラーアイコン＋テキスト「メールアドレスの形式が正しくありません」。
aria-invalid="true"とaria-describedbyでスクリーンリーダーにも通知 - 送信ボタン:
<button type="submit">に変更。Enterキーで送信可能 - フォーカス順: 名前→メール→内容→送信ボタンの論理的な順序
- コントラスト: エラーテキストの赤色をコントラスト比7:1以上に調整
この対応によりフォーム完了率が58%→71%に向上（+22%）。特に65歳以上のユーザー層で完了率が32ポイント改善した。
状況: 自治体のWebサイトに月800件の電話問い合わせがあり、その半数が「サイトで情報が見つからない」という内容だった。
主な改善施策:
- 見出し構造を正規化: h1→h2→h3の階層を正しく設定し、スクリーンリーダーで見出しジャンプを可能に
- リンクテキストの改善: 「こちら」「詳しくはこちら」を「ごみ収集カレンダーのダウンロード」のように具体化
- PDF→HTML化: 重要な申請書類のPDFをHTMLフォームに変換し、スクリーンリーダーで読み取り可能に
- サイト内検索のARIA対応: 検索結果件数をaria-liveで自動通知
アクセシビリティ対応は「特別なユーザーへの配慮」ではなく、全利用者の情報到達率を底上げする施策だった。月間電話問い合わせが800件→480件に減少し、視覚障害のあるユーザーからの好意的な声がSNSで拡散した。
状況: BtoB SaaSのダッシュボードツールが大手企業の導入検討で「アクセシビリティ要件を満たさない」として不採用になった。
対応内容:
- キーボードナビゲーション: すべてのインタラクティブ要素にTabで到達できるよう修正（対象要素287個）
- スキップリンク: ページ先頭に「メインコンテンツへスキップ」リンクを追加
- ドラッグ&ドロップ代替: ダッシュボードのウィジェット配置をキーボードの矢印キーでも操作可能に
- ライブリージョン: データ更新時にaria-live=“polite"でスクリーンリーダーに変更を通知
Lighthouse アクセシビリティスコアが42点→96点に改善。再提案で大手企業のアクセシビリティ監査をクリアし、年間契約額1,200万円のエンタープライズ契約を獲得した。
やりがちな失敗パターン#
- 「後からアクセシビリティ対応」と先送りする — 完成後に対応するとコストが何倍にもなる。設計段階から組み込むのが最も効率的
- 視覚だけに注力する — コントラストや色だけでなく、キーボード操作・スクリーンリーダー・認知的負荷も重要
- チェックツールだけに頼る — 自動ツールで見つかる問題は全体の30%程度。実際にキーボードで操作し、スクリーンリーダーで聞いてみることが不可欠
- ARIAを過剰に使う — セマンティックHTMLで表現できるものにARIAを追加するのは冗長で、かえって支援技術の挙動を壊す。「ARIAなしで済むなら使わない」が原則
まとめ#
アクセシビリティデザインは「特別な人のための特別な対応」ではなく、「すべてのユーザーの使いやすさを底上げする品質基準」。WCAG 4原則を理解し、コントラスト・キーボード操作・テキスト代替の3点から始めれば、今日からでもアクセシビリティは改善できる。