アクセシビリティと情報デザイン——架空の予約画面を評価する
色以外の手掛かり、キーボード操作、画像の代替テキストを手掛かりに、情報を得て目的の操作を完了できる画面を考える。架空UIの観察結果と数値を使い、改善案と再評価の方法を組み立てる。
- 色の区別、文字の読みやすさ、操作のしやすさを別の観点として評価できる。
- キーボードでの到達・実行・離脱とフォーカスの確認方法を説明できる。
- 画像の目的と周囲の文脈に応じて代替テキストを選べる。
- 架空の評価データから改善点を述べ、限定的な検査と適合判定を区別できる。
📑 目次
1．「見た目が整っている」だけでは足りない
アクセシビリティは、障害のある人を含む多様な利用者が情報を知覚し、理解し、操作できるようにする考え方です。例えばマウスを使わない人や画面読み上げソフトを使う人にも、予約の空き状況と確定結果が伝わる必要があります。屋外で画面が見えにくい場合などにも役立ちますが、そうした一時的状況だけで障害のある人の経験を代弁することはできません。
情報デザインでは、誰が何を完了したいかを先に決めます。本記事の目標は「希望時刻を選び、予約を確定し、結果を確認する」です。見栄えの好みではなく、この一連の行動を妨げる箇所を根拠付きで探しましょう。以下の画面・観察記録・数値はすべて学習用の架空設定で、実サービスや実利用者の統計ではありません。
2．色以外の手掛かりとコントラストは別問題
「緑は空き、赤は満席」という説明だけでは、その色の区別が難しい人に状態が伝わりません。「空き」「満席」という文字を各時刻に直接添え、必要なら形や模様も併用します。色を禁止するのではなく、色が伝わらなくても同じ判断ができるようにします。図の色を説明する代替テキストだけでは、画面を見ているが色を区別しにくい人への可視の手掛かりにはなりません。
| 情報 | 色だけに依存する表現 | 追加する手掛かり |
|---|---|---|
| 予約状態 | 緑・赤の丸だけ | 各時刻に「空き」「満席」の文字 |
| 入力エラー | 入力枠を赤くするだけ | 「日付を選んでください」という文と該当欄の関連付け |
| 折れ線の系列 | 青線と橙線だけ | 実線と破線、異なる点の形、系列名の直接表示 |
| 選択中の項目 | 背景色だけが変わる | チェック印と選択状態を支援技術へ伝える仕組み |
文字を追加しても、背景との明暗差が小さければ読みにくさが残ります。WCAG 2.2の達成基準1.4.3（レベルAA）は、通常の文字と背景について原則4.5対1以上のコントラスト比を求めます。大きな文字は3対1以上です。ここで大きな文字は18ポイント以上、または太字で14ポイント以上を指します。ロゴ、付随的な文字、非アクティブなUIなどには例外があり、この一つの値だけで全体の適合を判断できません。
LはWCAGの定義で求めた相対輝度で、単位はありません。RGBの数値や明度の百分率をそのまま代入してはいけません。以下では計算済みの相対輝度を条件として与え、半透明・写真背景・位置ごとの色変化はないものとします。実画面では測定ツール等で対象の前景色と背景色を確認します。
白背景の相対輝度を1、通常サイズの文字の相対輝度を0.20とする。予約欄には色付き丸だけで状態を表示している。文字のコントラスト比を求め、相対輝度0.15の文字に変更すれば問題がすべて解決するか答えよ。値は計算モデル上の正確な値とする。
解答・解説
変更前は(1 + 0.05)/(0.20 + 0.05) = **4.2対1**で、通常の文字の4.5対1に届きません。変更後は1.05/0.20 = **5.25対1**で、この文字コントラストの条件は満たします。しかし状態が色付き丸だけという問題は残ります。「空き」「満席」も表示する必要があります。読みやすさと意味の識別は別に点検します。
3．キーボードで到達・実行・離脱できるか
フォーカスは、キーボード入力を現在受け取る場所です。一般的なWeb画面ではTabとShift＋Tabで移動し、リンクはEnter、通常のボタンはEnterやSpaceで実行できます。選択肢のグループなどでは矢印キーを使う場合もあり、すべての項目がTabで一つずつ移動するとは限りません。標準的なHTMLのボタンや入力欄を使うと、名前・役割・標準操作を提供しやすくなります。見た目だけボタンの画像にする方法とは異なります。
- 到達：必要な操作にキーボードで移動できるか。順序は入力・確認・確定という意味の流れと一致するか。
- 認識：フォーカスがどこにあるか見えるか。固定ヘッダーなどで完全に隠されていないか。
- 実行：項目を選び、確定し、エラーを修正できるか。移動しただけで意図せず確定されないか。
- 離脱：メニューやダイアログから適切に戻れるか。閉じた後に元の操作位置を見失わないか。
4．代替テキストは画像の役割から決める
代替テキストは画像の見た目を何でも詳述するものではありません。画像を使えないときにも、その文脈で必要な情報や操作の目的が伝わることを目指します。画面読み上げだけでなく画像が読み込めない場合にも役立ちます。文字を画像に埋め込むより、通常のテキストとして提供する方が拡大や読み上げに対応しやすくなります。
| 画像の役割 | 対応の考え方 | 架空の例 |
|---|---|---|
| 情報を伝える写真 | 本文の目的に必要な内容を短く伝える | 「図書室入口の右側に返却ポスト」 |
| 画像だけの操作ボタン | 模様でなく操作目的を伝える | 虫眼鏡の絵なら「検索」 |
| 複雑なグラフ | 短い要約に加え、本文やデータ表でも詳細を提供 | 予約数の傾向を要約し、各月の件数を表にする |
| 意味のない装飾 | 読み上げを増やさない | HTMLの装飾用imgではaltを空文字列にする |
虫眼鏡の画像を、Aでは画像だけの検索ボタン、Bでは「検索」という文字も入った同じボタン内の飾りとして使う。他に名前を付ける仕組みはない。各画像のaltをどうするか。
解答・解説
Aは **「検索」** とし、操作の目的を伝えます。「丸と棒の絵」では実行結果が分かりません。Bはボタン内の文字で名前が伝わるので、飾りの画像は **空のalt** とする案が適切です。両方に「検索」を付けると重複して読まれる可能性があります。画像ファイル自体ではなく、使われ方で判断します。
5．架空UIを観察記録から評価する
| 観察対象 | 改善前Aの記録 | 改善後Bの記録 |
|---|---|---|
| 状態表示 | 緑丸と赤丸のみ | 色に加えて空き・満席の文字 |
| 通常の文字 | 例題1の4.2対1 | 例題1の5.25対1 |
| キーボード | 6個の必要な操作対象のうち4個だけ到達・実行可能 | 同じ6個すべて到達・実行可能 |
| 確認ダイアログ | 閉じる操作にマウスが必要 | キーボードで閉じ、元の確定ボタンへ戻れる |
| 会場地図 | 「map.png」という代替テキスト | 地図の要約と、本文に入口から受付への道順 |
表のキーボードの記録から、必要な操作対象の到達・実行可能な割合をAとBで求めよ。割合の改善幅と、Bについてまだ断言できないことを述べよ。6個はこの課題で必要な操作対象を重複なく数えたものとする。
解答・解説
Aは4/6 × 100 ≈ **66.7％**、Bは6/6 × 100 = **100％**。改善幅は約**33.3パーセントポイント**です（表示値は小数第1位に丸めた）。ただし操作順序、フォーカスの見え方、読み上げ時の名前、エラーからの復帰などはこの割合に含まれません。Aで使えない2個の中に確定操作があれば予約自体が完了できません。Bの100％も全利用者への使いやすさやWCAG全体への適合の証明ではありません。
評価報告には「観察した事実→妨げられる行動→改善案→再確認する条件」を書きます。例えば「閉じる操作がマウス専用→キーボード利用者が確認画面から戻れない→名前のある標準ボタンで閉じられるようにする→開く・閉じる・再入力するまでをキーボードで再確認する」と整理できます。単に改善項目の数を競わず、完了を妨げる問題を優先します。
- 色を使わない表示でも状態が分かるか確認する。ただしグレースケール表示だけで色覚の多様性を再現できるわけではない。
- マウスなしで一連の課題を試し、到達だけでなく実行・離脱・結果確認を記録する。
- 画像の目的、フォームのラベル、見出しの構造を確認し、読み上げでも意味が通るか検証する。
- 自動検査はコントラストや属性の一部を調べられるが、代替テキストの意味や全操作の自然さを保証しない。手動確認や多様な利用者からの評価を組み合わせる。
入力欄の枠を赤くするだけでエラーを知らせている。色以外に何を追加し、何が伝わるようにするか。
解答・解説
例えば「メールアドレスに@を含めて入力してください」という具体的な文を該当欄に関連付けます。色が区別できなくても、どの欄に何の問題があり、どう直せばよいかが分かるようにします。単に「エラー」と付けるより修正につながります。
白背景の相対輝度が1、通常の文字が0.25のとき、コントラスト比を求めよ。本文の通常文字の基準に達するか。
解答・解説
(1 + 0.05)/(0.25 + 0.05) = **3.5対1**。4.5対1未満なので通常文字の基準に達しません。大きな文字の基準を通常文字に流用してはいけません。
「会場への行き方」という本文に、入口から受付への道順を示す地図がある。「地図」という代替テキストだけでは何が不足するか。
解答・解説
地図が存在することしか伝わらず、行き方が分かりません。地図の役割が分かる短い要約に加え、必要な道順・目印を本文にも提供します。長い経路をすべて短いaltへ詰め込む必要はありません。
予約ボタンにTabで到達できたことだけを根拠に「キーボード対応済み」と報告してよいか。
解答・解説
不十分です。フォーカスの視認、実行、確認ダイアログからの離脱、結果の把握、エラーの修正まで点検します。到達できてもEnter等で実行できなければ目的を達成できません。
問1. 色の区別に依存せず予約状態を伝える改善はどれか。
問2. 画像だけでできた印刷ボタンに、他の名前付けはない。適切な代替テキストはどれか。
問3. モーダルダイアログのキーボード操作について、適切な設計はどれか。
問4. 必要な6個の操作対象をすべてキーボードで実行できた。この結果から直接いえることはどれか。
根拠とこの教材の範囲
基準の出典はW3C「Web Content Accessibility Guidelines (WCAG) 2.2」、2023年10月5日勧告版（https://www.w3.org/TR/2023/REC-WCAG22-20231005/）。主に1.1.1 非テキストコンテンツ、1.4.1 色の使用、1.4.3 コントラスト、2.1.1 キーボード、2.1.2 キーボードトラップなし、2.4.3 フォーカス順序、2.4.7 フォーカスの可視化、2.4.11 フォーカスが隠されない（最低限）、3.3.1 エラーの特定、4.1.2 名前・役割・値を参照しています。相対輝度とコントラスト比は同文書の定義に基づきます。