装飾の色と、情報を伝える色を分ける
色は、文章を読む前からページの雰囲気を伝えます。一方で、送信が成功したか、どの項目が選択されているか、グラフの線が何を表すかといった、具体的な意味を担うこともあります。この二つの役割は分けて考える必要があります。青い光の装飾は、装飾のままで構いません。しかし、次の操作を決めるための色付きの点には、意味を読み取れる別の手掛かりが必要です。まず伝える内容を言葉にし、その後で視覚表現を選ぶ。この順序にすると、色に任せすぎている箇所が見えてきます。
色の名前ではなく、状態の名前を書く
WCAG 2.2の達成基準1.4.1では、情報を伝える唯一の視覚的な手段として色を使わないことが求められています。たとえば、説明のないオレンジ色の点を「確認待ち」という表示に変え、必要なら時計の形を添えます。意味は文字が伝え、色は一覧を見渡す助けになります。「緑の項目を選んでください」という案内も、項目名や用途を示す表現に置き換えられます。モノクロの画面にした途端、利用者が意味を推測しなければならなくなる設計は避けたいところです。色を増やす前に、状態の名前が利用者にとって具体的かどうかを見直します。
入力エラーは、その場で解決できる説明にする
問い合わせフォームを送信すると、メールアドレス欄が赤い枠になったとします。それだけでは、利用者は何を直すべきか分かりません。「@を含むメールアドレスを入力してください」のような説明を欄の近くに置き、実装でも入力欄と説明を関連付けます。それまでの入力内容は保持します。警告の形は補助になりますが、説明の代わりにはしません。また、目で見える伝達と支援技術への伝達は別々に確認します。画面に出ない読み上げだけでは、色に代わる視覚的な手掛かりにはなりません。反対に、画面上の文字だけで、動的な状態変化がスクリーンリーダーに伝わるとも限りません。
グラフの意味を、凡例まで探しに行かせない
小規模な進行表なら、線の近くに系列名を直接置く方法があります。離れた色の凡例とグラフを何度も見比べる負担を減らせます。線種や点の形を変える場合は、縮小しても見分けられるかを確認します。情報量が多すぎるグラフでは、模様を追加するより、比較する内容を整理するほうが先です。手掛かりを重ねた結果、かえって読みにくくなっては意味がありません。正確な値を確認する必要があるなら、見出しの付いた表も用意します。レビューでは「オレンジの線がどれか分からなくても、遅れている工程を特定できるか」と具体的に問いかけてみます。
区別できることと、見えることは別の問題
三角形と円は異なる形ですが、どちらも薄すぎれば見つけにくくなります。WCAG 1.4.11は、操作部品やグラフィックを理解するために必要な情報のコントラストを別に扱い、定められた例外を除き、隣接する色に対して原則3:1以上を求めています。意味の区別と、視認できるコントラストは、それぞれ確認が必要です。赤と緑を濃くしても、「赤いほうを選ぶ」という判断に依存したままなら十分ではありません。また、操作を識別する唯一の手掛かりがアイコンである場合、そのアイコン自体が見えにくい問題を、別の場所の説明文だけで解消することはできません。
一つの画面ではなく、操作の流れ全体を確かめる
手早い設計チェックとして、グレースケール表示で各状態を説明し、色の名前を使わずに意味が伝わるか試す方法があります。ただし、これは依存関係を見つけるための補助であり、WCAGへの適合を証明する試験でも、あらゆる人の見え方を再現する方法でもありません。その後に実際のコントラスト、キーボードのフォーカス、選択状態、エラー状態、支援技術への更新通知を確認します。スマートフォンの幅も忘れずに確認します。役立つラベルでも、狭い画面で非表示になれば役割を果たせません。目標は色をなくすことではなく、色がなくても意味の通じる設計を、色で支えることです。