Webアクセシビリティを高めるには、特定の見え方や操作方法だけを前提にせず、利用者が自分の環境や必要に合わせて情報へアクセスできる設計が求められます。
文字と配色の調整、字幕、キーボード操作、スクリーンリーダー対応は、どれも利用方法の選択肢を広げる施策ですが、目的と確認方法は同じではありません。
「要求に応じた変更」を広く捉えすぎない
この記事では、利用者が文字の見え方や操作方法を選べることを、表示と操作のカスタマイズとして扱います。
一方、WCAG 2.2の達成基準3.2.5「リクエスト時の変更」は、ページ遷移、新しいウィンドウ、主な内容の更新など、利用者を混乱させる可能性があるコンテキストの変更を制御するための基準です。
文字サイズ、字幕、キーボード操作、読み上げ対応を一つの基準としてまとめず、次のように目的を分けると実装と試験の漏れを見つけやすくなります。
| 利用場面 | 必要な配慮 | 主な確認 |
|---|---|---|
| 文字が小さい、配色が見分けにくい | 文字の拡大と読みやすい配色を妨げない | 拡大しても文字や操作部品が欠けないか |
| 音声を聞き取れない、音を出せない | 字幕や文字起こしを用意する | 音声の内容と文字情報が対応しているか |
| マウスを使いにくい | キーボードで主要な機能を操作できるようにする | 移動順序、フォーカス表示、実行方法が明確か |
| 画面を目で追いにくい | 見出し、ラベル、読み上げ用の名前を整える | スクリーンリーダーで内容と操作目的が伝わるか |
文字サイズと配色を調整できる設計
文字サイズの変更ボタンや配色テーマを用意する場合も、ブラウザーのズームや利用者側の表示設定を妨げないことが前提です。
文字サイズには相対的な指定を使い、拡大したときに文章が重なったり、ボタンが画面外へ隠れたりしないレイアウトにします。
- 文字を拡大しても、本文と操作部品を読める状態を保つ
- 背景色と文字色の組み合わせを変えても、内容を判別できる状態を保つ
- 設定ボタンには「文字を大きくする」など、実行後の変化が分かる名前を付ける
- 設定機能そのものもキーボードやスクリーンリーダーで操作できるようにする
動画と音声には文字で受け取る手段を用意する
動画には字幕、音声コンテンツには文字起こしを用意すると、音声を聞き取りにくい場合や音を出せない環境でも内容を確認できます。
アクセシブルな動画掲載では、字幕だけでなく、再生と停止などの操作方法も確認します。
<track>要素を使う基本形は次のとおりです。
<video controls>
<source src="movie.mp4" type="video/mp4">
<track src="subtitles.vtt" kind="subtitles" srclang="ja" label="日本語字幕">
</video>字幕ファイルを設定した後は、表示の切り替え、音声との対応、読みやすさを実際のプレーヤーで確認します。
キーボードで操作の流れを確認する
マウスを使わずに主要なリンク、ボタン、入力欄へ移動でき、現在位置を見失わずに操作できることを確認します。
HTMLの<button>要素には標準の操作方法が備わっているため、単純なボタンを別の要素で作り直すより、目的に合うHTML要素を選ぶほうが操作を伝えやすくなります。
<button type="button">送信</button>移動順序やフォーカスの見え方は、キーボード操作とフォーカス表示の確認ポイントも参考にしてください。
スクリーンリーダーに操作目的を伝える
スクリーンリーダーは、見出しやリンク、ボタンの名前などを手掛かりにページの構造と操作方法を伝えます。
まず内容に合うHTML要素と画面上の分かりやすいラベルを使い、アイコンだけでは目的が伝わらない場合にaria-labelなどで名前を補います。
<button type="button" aria-label="検索">🔍</button>ARIA属性を追加しただけで確認を終えず、ボタンの名前、役割、操作後の結果が読み上げ環境で伝わるかを試します。
予期しない画面変更を避ける
選択肢を変えただけで別ページへ移動したり、操作の説明なしに新しいウィンドウが開いたりすると、利用者は現在位置を見失うことがあります。
- 選択内容を反映する処理は「適用」などのボタンで明示的に実行できるようにする
- 自動更新が必要な場合は、利用者が更新を要求する方法や停止する方法を用意する
- 新しいウィンドウやタブを開く必要がある場合は、リンクの文言などで事前に伝える
表示を変える機能を提供することと、予期しないコンテキスト変更を防ぐことは別の作業として試験します。
実装後の確認リスト
- ブラウザーで文字を拡大しても、内容と操作部品が欠けないか
- キーボードだけで主要な機能へ移動し、実行できるか
- フォーカスの位置を画面上で確認できるか
- 字幕と文字起こしが音声の内容を伝えているか
- スクリーンリーダーで見出し構造と操作部品の名前が伝わるか
- 入力や選択だけで予期しないページ移動やウィンドウ表示が起きないか
多様な利用方法を妨げない設計へ
アクセシビリティ対応は、設定ボタンやARIA属性を一つ追加すれば完了する作業ではありません。
表示、音声情報、入力方法、読み上げ、画面変更を分けて設計し、それぞれを実際の操作で確認すると、利用者が自分に合う方法で情報へアクセスしやすくなります。
当社では、ウェブアクセシビリティを簡単に導入できるUUU ウェブアクセシビリティウィジェットツールをリリースしております。
アクセシビリティ向上にご興味がある方は、ぜひ詳細をご覧ください。