色だけに依存しないUI設計｜アクセシビリティを高める実践ガイド

UIでは、色を使うことで状態や優先順位を素早く伝えられます。成功を緑、警告を黄色、エラーを赤、情報を青で表示すれば、多くの利用者は画面を見ただけでおおよその意味を判断できます。色は、情報を短時間で理解するための有効な視覚要素です。

しかし、色だけを唯一の手掛かりにすると、色覚特性、弱視、低品質な画面、強い日光、モノクロ印刷、ハイコントラストモードなどの条件によって情報が失われる可能性があります。赤い枠線だけで入力エラーを示したり、緑と赤だけでグラフの良し悪しを区別したりすると、状態を正しく判断できない利用者が生まれます。

WCAG 2.2の達成基準1.4.1「色の使用」では、色を情報、操作、応答、識別の唯一の視覚的手段にしないことが求められています。色を廃止する必要はなく、文字、形状、アイコン、線種、パターン、位置など、色以外の手掛かりを追加することが基本です。

1. 色だけに依存しないUIとは

色だけに依存しないUIとは、色を認識できない状態でも、情報、状態、操作方法を理解できるUIです。色を使わないデザインではなく、色に加えて別の手掛かりを用意する設計を意味します。

1.1 色への依存とは

色への依存は、色が分からなければ情報を判断できない状態です。例えば、「赤色の項目は必須です」「緑の線が今年、赤の線が昨年です」という説明は、色以外の区別がない場合に色へ依存しています。

一方、「必須」という文字、アスタリスク、異なる線種、直接ラベルなどが併記されていれば、色は補助的な手掛かりになります。色を使いながら、色が失われても意味が残る状態を目指します。

1.2 色を使わない設計との違い

色だけに依存しないという原則は、白黒だけでUIを作ることではありません。色は、情報を素早く見つけたり、状態を直感的に把握したりするための有効な補助手段です。

問題になるのは、色を認識できなければ操作できないことです。成功通知を緑で表示しながらチェックアイコンと「保存しました」を付ければ、色の利点を維持したまま意味を補強できます。

1.3 冗長符号化とは

一つの情報を、色と別の表現の両方で伝える方法を冗長符号化として考えられます。エラーを赤色、感嘆符アイコン、「入力内容を確認してください」という文字で同時に表す設計が例です。

複数の手掛かりは、色覚特性のある人だけでなく、急いで操作する人や小さい画面を見る人にも役立ちます。認識方法を複数用意することで、情報を見落としにくくできます。

1.4 色以外に使える手掛かり

色以外の手掛かりには、文字、アイコン、形状、線の太さ、線種、パターン、余白、位置、番号、アニメーション、音声通知などがあります。

すべてを同時に使う必要はありません。情報の種類に応じて、最も自然な組み合わせを選びます。フォームエラーなら文字とアイコン、グラフなら線種と直接ラベルが適しています。

1.5 色を補助情報として扱う

色は、情報の主要な意味を強調する補助手段として使います。文字や構造だけでも理解でき、色があるとさらに速く認識できる状態が理想です。

設計レビューでは、色を一時的に取り除いた状態を確認してください。グレースケールでも状態、選択、リンク、エラー、グラフ系列を判別できれば、色への依存を減らせています。

2. 色だけに依存すると起こる問題

色への過度な依存は、特定の利用者だけに影響する問題ではありません。端末、環境、印刷、設定、認知負荷など、さまざまな条件で情報が失われます。

2.1 色覚特性によって区別しにくい

色の見え方には個人差があり、赤と緑、青と紫など、特定の組み合わせを区別しにくい場合があります。赤と緑だけで成功と失敗を区別すると、二つが似た明度に見える可能性があります。

色相を変更するだけでは十分とは限りません。色の違いに加え、アイコン、状態名、配置などを使って意味を伝える必要があります。

2.2 弱視やコントラスト感度へ影響する

色相を認識できても、背景との明度差が小さいと文字や境界を確認しにくくなります。薄い黄色のアイコンを白背景へ置く場合や、淡い赤文字を淡い赤背景へ置く場合が例です。

WCAG 2.2では、通常サイズの文字に4.5対1以上、大きな文字に3対1以上のコントラスト比が基準として示されています。意味を持つアイコンや入力境界などの非テキスト要素には、隣接色との3対1以上が求められます。

2.3 利用環境で色が変化する

屋外の強い光、暗い部屋、低輝度設定、古いディスプレイ、プロジェクターなどでは、設計時と異なる色に見えます。薄い背景色や近い色相の差が消えることもあります。

実際の利用環境が不明な製品では、色の差だけを前提にしないことが安全です。形や文字による区別は、表示条件が変わっても比較的維持されます。

2.4 モノクロ表示で意味が失われる

画面を印刷した資料、電子ペーパー、モノクロ表示、PDFの白黒印刷では、複数の色が同じ灰色に変換される場合があります。

赤と緑のグラフが同じ明度で印刷されると、系列を区別できません。線種、マーカー、ラベルを加えておけば、モノクロでも情報を読み取れます。

2.5 認知負荷が増える

色の意味を凡例から記憶し、画面上の要素へ対応させる作業は、利用者へ負担を与えます。状態名を直接表示すれば、凡例を何度も確認する必要がありません。

特に多くの色を使うダッシュボードでは、色の意味を覚えること自体が作業になります。重要な情報は文字で明示し、色は検索速度を高める補助として使います。

3. WCAG 2.2と色の使用

色への依存を避ける設計では、WCAG 2.2の「色の使用」「コントラスト」「非テキストコントラスト」などが重要な基準になります。

3.1 色の使用

WCAG 2.2の達成基準1.4.1はレベルAで、色を情報の伝達、操作の提示、応答の要求、視覚要素の識別に使う唯一の視覚的手段にしないことを求めています。

この基準は色を禁止していません。色と文字、アイコン、パターンなどを組み合わせれば、色を積極的に使用できます。

3.2 文字のコントラスト

色以外の手掛かりを加えても、文字そのものが読めなければ情報は伝わりません。通常サイズの文字は背景とのコントラスト比4.5対1以上、大きな文字は3対1以上がレベルAAの基準です。

「色だけに依存しないこと」と「色のコントラストを確保すること」は別の要件です。エラー文へアイコンを追加しても、赤文字が背景と十分に区別できなければ改善が必要です。

3.3 非テキストコントラスト

入力欄の枠線、チェックボックス、グラフ、状態アイコンなど、理解や操作に必要な視覚要素には、隣接色との3対1以上のコントラスト比が基準になります。

ただし、太さや形状も認識性に影響します。計測値を満たす1pxの細い線でも、利用環境によって見つけにくい場合があります。

3.4 感覚的特徴に依存しない

「右側の緑のボタンを押してください」のように、色と位置だけで操作対象を説明すると、画面構成や色を確認できない利用者へ伝わりません。

「次へ進むには、画面下部の『次へ』ボタンを押してください」のように、ラベルを含めて説明します。WCAGの感覚的特徴に関する解説でも、色や位置だけでなく、ラベルを併用する例が示されています。

3.5 色の代替だけで完了と考えない

アイコンを一つ追加しただけで、必ずアクセシブルになるわけではありません。アイコンの意味が不明、代替テキストがない、コントラストが不足している場合は、別の問題が残ります。

文字、視覚表現、HTML構造、キーボード操作、支援技術への通知を一緒に確認してください。アクセシビリティは配色だけで完結するものではありません。

4. 文字ラベルで意味を伝える

色への依存を減らす最も直接的な方法は、状態や操作を文字で明示することです。利用者が推測しなくてもよい文章を設計します。

4.1 状態名を表示する

緑の丸だけを表示するのではなく、「稼働中」「承認済み」「完了」などの状態名を併記します。

文字があれば、色を認識できない場合でも状態を判断できます。また、緑が「正常」「公開中」「接続済み」のどれを意味するのかという曖昧さも解消できます。

<span class="status status--success">  <span    class="status__icon"    aria-hidden="true"  >    ✓  </span>  稼働中 </span>

4.2 操作ラベルを具体的にする

「赤いボタン」「緑のアイコン」のような呼び方ではなく、「削除」「保存」「次へ」のように操作結果を表すラベルを使います。

アイコンボタンの場合も、アクセシブルネームを設定します。視覚上の色がなくても、支援技術や音声操作から目的を判断できる状態が必要です。

<button  type="button"  aria-label="通知を削除" >  <svg aria-hidden="true">    <!-- 削除アイコン -->  </svg> </button>

4.3 エラー理由を文章で説明する

フォームの枠線を赤くするだけでは、何が間違っているのか分かりません。「メールアドレスを入力してください」「日付は未来の日付を選べません」のように、問題と修正条件を記述します。

WCAG 2.2のエラー識別では、自動検出された入力エラーについて、問題のある項目を識別し、エラーを文字で説明することが求められます。

4.4 必須項目を明示する

必須項目を赤色のラベルだけで表すのではなく、「必須」という文字やアスタリスクを併記します。アスタリスクを使う場合は、その意味をフォーム冒頭で説明します。

W3Cの例でも、必須項目へ赤色とアスタリスクまたは説明可能なアイコンを併用し、情報をプログラムからも判別可能にする方法が示されています。

<label for="name">  氏名  <span class="required">    必須  </span> </label> <input  id="name"  name="name"  required >

4.5 短く具体的な文を使う

状態ラベルは、長すぎると一覧や表を圧迫します。短くても意味が具体的な語を選びます。

「問題あり」より「支払い失敗」、「注意」より「期限まで3日」のように、可能であれば実際の状態を直接伝えます。

5. アイコンと形状を組み合わせる

アイコンと形状は、文字を読む前に状態を認識する補助になります。ただし、形だけを新たな唯一の手掛かりにしないことが重要です。

5.1 状態ごとに異なるアイコンを使う

成功にはチェック、警告には三角形、エラーには×または感嘆符、情報には情報記号を使う方法があります。

同じ円形の中で色だけを変更するより、外形や内部記号も変えることで区別しやすくなります。

5.2 アイコンへ文字を併記する

アイコンの意味は文化や製品によって異なる場合があります。警告アイコンだけでは、何について注意すべきか分かりません。

通知やフォームでは、アイコンと状態名または具体的な説明文を併記します。アイコンは検索速度を高め、文字が意味を確定する役割を持ちます。

5.3 同じ外形を色だけで変えない

赤い丸、緑の丸、黄色い丸だけを並べる設計は、色が失われると区別できません。

成功を円形、警告を三角形、エラーを八角形など、形を変える方法があります。ただし、複雑な形状体系は学習負担になるため、文字ラベルも残します。

5.4 装飾アイコンを読み上げない

隣に「保存しました」という文字があり、チェックアイコンが同じ意味を繰り返すだけなら、アイコンをaria-hidden="true"にできます。

スクリーンリーダーが「チェックアイコン、保存しました」と重複して読み上げることを防ぎます。アイコンだけの操作には、反対にアクセシブルネームが必要です。

5.5 アイコンのコントラストを確認する

状態を判断するために必要なアイコンは、背景とのコントラストが不足しないようにします。WCAG 2.2の非テキストコントラストでは、意味を持つ視覚情報に3対1以上の基準があります。

薄い黄色の警告アイコンを白背景へ置く場合は、濃い茶色やオレンジへ変更するなど、実際の境界が見える値を選びます。

6. フォームで色以外の手掛かりを使う

フォームは、色への依存が発生しやすい代表的な領域です。必須、入力中、成功、エラー、無効状態を、色以外でも区別できるようにします。

6.1 エラーを枠線だけで示さない

入力欄の枠線を赤くするだけでは、通常状態との違いを認識できない場合があります。エラーアイコン、説明文、必要に応じてエラー一覧を追加します。

説明文は対象フィールドの近くへ配置し、aria-describedbyなどで入力欄と関連付けます。

<label for="email">  メールアドレス </label> <input  id="email"  name="email"  aria-invalid="true"  aria-describedby="email-error" > <p  id="email-error"  class="field-error" >  有効なメールアドレスを入力してください </p>

6.2 成功表示を過剰に使わない

有効な入力すべてへ緑の枠線を付けると、フォーム全体が色で騒がしくなります。通常状態を成功色で表す必要はありません。

入力条件が複雑で、検証完了を知らせる価値がある場合のみ、チェックアイコンと「確認済み」などを表示します。

6.3 フォーカスを色だけで示さない

入力欄へフォーカスしたとき、枠線の色だけを青へ変えると、通常枠との違いが小さい場合があります。

枠線を太くする、外側へアウトラインを追加する、背景や影を変えるなど、形状の変化も加えます。フォーカス表示は、キーボード利用者が現在位置を判断するために重要です。

input:focus-visible {  outline: 3px solid var(--focus-ring-color);  outline-offset: 2px;  border-width: 2px; }

6.4 無効状態を薄い色だけで示さない

無効なボタンや入力欄を薄いグレーにするだけでは、通常状態と区別しにくく、文字も読めなくなる可能性があります。

disabled属性を正しく使い、カーソル、アイコン、説明文などを必要に応じて追加します。なぜ無効なのか分からない場合は、条件を近くへ表示してください。

6.5 エラー一覧を提供する

複数のエラーがある長いフォームでは、送信ボタン付近またはフォーム上部にエラー概要を表示します。

各エラーをリンクにして対象項目へ移動できるようにすると、赤い箇所を画面内から探す必要がなくなります。

7. リンクと操作要素を色だけで区別しない

文章内のリンク、ボタン、選択可能な項目は、色が見えなくても操作対象であると分かる必要があります。

7.1 本文リンクへ下線を付ける

本文中のリンクを青色だけで表すと、色の差を認識しにくい場合に通常の文字と区別できません。下線は、一般的で理解されやすい非色彩の手掛かりです。

W3Cの失敗例でも、リンクを周囲の文字と色だけで区別し、下線などの追加表示がない場合は問題になると説明されています。

.article a {  color: var(--link-color);  text-decoration: underline;  text-decoration-thickness: 0.08em;  text-underline-offset: 0.16em; }

7.2 ホバー時だけ下線を出さない

通常時は色だけで、マウスを置いたときだけ下線を出す設計では、タッチ操作やキーボード操作でリンクを見つけにくくなります。

本文リンクは通常時から下線を表示する方法が安全です。ナビゲーションなど、形状や配置でリンクと分かる要素は別の扱いにできます。

7.3 ボタンを背景色だけで区別しない

主要ボタン、補助ボタン、危険ボタンを色だけで分けると、モノクロ環境で区別できません。

塗り、枠線、アイコン、ラベル、配置を組み合わせます。「削除」にはごみ箱アイコンを加え、危険な結果を文字で明示します。

7.4 選択状態をチェックで示す

タブ、カード、フィルターなどで、選択中の項目だけ背景色を変える設計は避けます。

チェックアイコン、太い下線、枠線、aria-selectedなどを併用してください。色が失われても選択状態を確認できます。

7.5 訪問済みリンクを補助的に扱う

訪問済みリンクの色は、履歴を把握する補助になります。ただし、訪問済みと未訪問の差が色だけでも、リンク自体が下線などで明確なら、リンクであることは判断できます。

リンクかどうかの識別と、訪問済みかどうかの補助表示を分けて考えてください。

8. グラフとデータ可視化で色以外を使う

グラフでは複数の系列を色で分けることが多く、色への依存が特に発生しやすい領域です。線種、形状、ラベル、パターンを組み合わせます。

8.1 線種を変更する

折れ線グラフでは、実線、破線、点線、一点鎖線を使って系列を区別できます。

色と線種を組み合わせれば、カラー画面では素早く認識でき、モノクロ印刷でも区別できます。

8.2 マーカー形状を変える

データ点へ円、四角、三角、ひし形などのマーカーを付けます。

線が交差するグラフでも、各点の形状から系列を判断できます。マーカーが小さすぎると区別できないため、実際の表示サイズで確認します。

8.3 直接ラベルを付ける

凡例だけに頼らず、線や棒の近くへ系列名を直接表示します。

利用者が凡例とグラフを往復する必要がなくなり、色を記憶する負担も減ります。余白が限られる場合は、終点だけにラベルを付ける方法もあります。

8.4 塗りパターンを使う

棒グラフや面グラフでは、斜線、ドット、格子などのパターンを使って領域を区別できます。

パターンを細かくしすぎるとちらつきや視覚的なノイズが生まれます。少数の分かりやすいパターンに限定してください。

8.5 数値表を併用する

複雑なグラフでは、元データを確認できる表や一覧を提供します。

グラフで傾向を把握し、表で正確な数値を確認できるようにすると、視覚的な違いを認識しにくい場合にも情報へアクセスできます。

9. ステータスと通知を色以外で伝える

成功、警告、エラー、情報などの状態は、色だけでなく、状態名、アイコン、見出し、文章で伝えます。

9.1 ステータス名を必ず含める

表や一覧の状態列では、色付きの点だけを表示せず、「公開中」「停止中」「審査中」などの文字を表示します。

状態名があれば検索、読み上げ、コピー、モノクロ印刷でも意味が残ります。

9.2 通知へ見出しを付ける

通知の先頭に「保存完了」「注意」「入力エラー」「お知らせ」などの見出しを置きます。

本文を読む前に種類を判断でき、アイコンの意味も補強できます。

9.3 通知の形状を変える

重大なエラーには太い左枠、軽い情報には細い枠など、重要度によって形状や面積を調整できます。

ただし、状態ごとに複雑な形状ルールを作るより、同じ通知構造でアイコンと見出しを変えるほうが学習しやすい場合があります。

9.4 動的な通知を支援技術へ伝える

画面上へ表示された成功や検索結果件数など、緊急性の低い動的な更新にはrole="status"を利用できます。statusは暗黙的にaria-live="polite"を持ち、適切なタイミングで読み上げられます。

即時対応が必要な重大なエラーにはrole="alert"が候補です。alertは時間的に重要なメッセージ用であり、多用すると現在の読み上げを妨げる可能性があります。

9.5 色と緊急度を分離する

赤だから必ず重大、青だから必ず軽いと決めるだけでは不十分です。見出し、配置、操作の可否、表示時間も緊急度へ合わせます。

重大エラーは画面内へ残し、修正方法を表示します。軽い成功通知は短時間のトーストでもよい場合があります。

10. 選択・進捗・状態変化を表現する

選択状態や進捗状況も、色だけで表現されやすい要素です。構造と意味を追加して、現在位置を明確にします。

10.1 タブの選択状態

選択中のタブだけ文字色を変えるのではなく、下線、太字、背景、aria-selected="true"を使います。

キーボードフォーカスと選択状態は別の状態です。フォーカスリングも独立して見えるようにします。

10.2 チェックボックスとラジオボタン

選択時に背景色だけを変えるのではなく、チェックや内部の点を表示します。

ブラウザー標準の入力要素を使うと、状態や操作方法が支援技術へ伝わりやすくなります。独自実装では、名前、役割、状態を正しく提供する必要があります。

10.3 ステップ表示

手順の現在位置を色だけで表さず、番号、チェック、現在位置を示す文字を使います。

完了済みはチェック、現在は太い枠と「現在」、未完了は番号というように、複数の違いを作ります。

10.4 進捗バー

進捗バーの色だけで完了率を表さず、数値や説明文を併記します。

「75％」「3件中2件完了」のような文字があれば、バーの長さを正確に認識できない場合にも状態が分かります。

<label for="upload-progress">  アップロード進捗：75％ </label> <progress  id="upload-progress"  max="100"  value="75" >  75％ </progress>

10.5 オンライン状態

緑の点だけでオンライン状態を示すのではなく、「オンライン」「離席中」「オフライン」という文字を表示します。

小さい画面で文字を省略する場合は、アクセシブルネームやツールチップを用意します。ただし、ホバーしなければ分からない情報だけにしないよう注意します。

11. フォーカス・ホバー・押下状態を設計する

操作状態は、色を変えるだけでは判別しにくい場合があります。形状、アウトライン、位置変化を組み合わせます。

11.1 フォーカスリングを表示する

キーボードフォーカスでは、要素の周囲へ明確なアウトラインを表示します。

背景色を少し変えるだけでは、現在位置を見つけにくくなります。外側へ線を追加し、周囲の色と区別できるようにします。

11.2 ホバーとフォーカスを区別する

ホバーはポインター位置、フォーカスはキーボードなどの操作位置を示します。両者を同じ色変化だけで表すと、状態を理解しにくくなります。

ホバーでは背景変化、フォーカスではアウトラインを追加するなど、異なる表現を用意します。

11.3 押下状態を形で示す

ボタンの押下時には、色を濃くするだけでなく、わずかな位置移動や影の変化を使えます。

ただし、大きな動きは画面のちらつきや操作ミスにつながります。色以外の変化は小さく、一貫したものにします。

11.4 ドラッグ対象を明示する

ドラッグ可能な要素を特定の色だけで示さず、ドラッグハンドル、カーソル、説明文を加えます。

キーボードからも並べ替えられる方法や、上へ移動・下へ移動ボタンを提供すると、ドラッグ操作へ依存しない設計になります。

11.5 フォーカスを消さない

outline: noneだけを指定し、代替表示を用意しない実装は避けます。

デザイン上の理由で標準アウトラインを変更する場合は、同等以上に見つけやすい独自フォーカス表示を作ります。

12. ダークモードとハイコントラストモードへ対応する

色への依存を減らす設計は、ダークモードや利用者指定の強制配色でも維持する必要があります。

12.1 ダークモードで再検証する

ライトモードで区別できる色も、暗い背景では同じ明度に近付く場合があります。

ライト用の色を単純に反転せず、文字、境界、アイコン、状態差を個別に確認します。

12.2 prefers-contrastへ対応する

prefers-contrastメディア特性を使うと、利用者がより高い、または低いコントラストを希望しているかを検出できます。

高コントラストを希望する場合に、枠線を太くする、背景差を増やす、薄い装飾を削除するなどの調整ができます。

@media (prefers-contrast: more) {  .status {    border-width: 2px;  }  .focusable:focus-visible {    outline-width: 4px;  } }

12.3 forced-colorsへ対応する

forced-colorsは、Windowsのハイコントラストモードなど、利用者が選んだ限定的な色パレットをブラウザーが強制する環境を検出します。

背景色が置き換えられても、枠線、文字、アイコン、状態名が残るようにします。背景色だけで選択やエラーを示す設計は、この環境で意味を失う可能性があります。

@media (forced-colors: active) {  .status {    border: 2px solid CanvasText;  }  .status--error::before {    content: "エラー：";    font-weight: 700;  } }

12.4 forced-color-adjustを慎重に使う

forced-color-adjust: noneを指定すると、強制配色から要素を除外できますが、利用者が選択した配色を無効にする可能性があります。

ロゴや色自体が内容であるカラーピッカーなど、限定的な用途以外では、ブラウザーの色調整を尊重するほうが安全です。

12.5 実際の環境で操作する

シミュレーションだけでなく、Windowsハイコントラスト、ブラウザー拡大、ダークモード、グレースケールなどで操作します。

表示を眺めるだけでなく、リンクを探す、フォームを修正する、タブを移動するなど、実際のタスクを実行してください。

13. デザイントークンへ組み込む

色以外の表現もデザインシステムへ登録しなければ、画面ごとに異なる実装が増えます。

13.1 色トークンだけを作らない

status-error-colorだけでは、エラーの表現方法を統一できません。

アイコン、枠線幅、背景、文字スタイル、ラベル、パターンなども含めたコンポーネント仕様を用意します。

13.2 意味トークンを使う

red-600ではなく、status-error-borderやtext-linkなど、意味を示す名前を使います。

将来色を変更しても、コンポーネントの意味を維持できます。

:root {  --status-error-text: #991b1b;  --status-error-border: #dc2626;  --status-error-background: #fef2f2;  --status-error-border-width: 2px;  --status-error-icon: "error"; }

13.3 非色彩トークンを定義する

状態アイコン、線種、パターン、枠線幅などもトークン化できます。

グラフ系列なら、色と線種をセットにしたトークンを作ります。

{  "chart": {    "seriesA": {      "color": "{color.blue.600}",      "lineStyle": "solid",      "marker": "circle"    },    "seriesB": {      "color": "{color.orange.600}",      "lineStyle": "dashed",      "marker": "square"    }  } }

13.4 状態コンポーネントを共通化する

ステータスタグ、通知、フォームエラーを共通コンポーネントとして提供します。

各画面の担当者が色だけを選ぶのではなく、「成功」「警告」「エラー」「情報」という状態を選べば、適切なアイコンと文字スタイルが自動的に適用される構造にします。

13.5 使用規則を文書化する

「色だけで区別しない」という抽象的な原則だけでなく、コンポーネントごとの具体例を記載します。

14. FigmaとCSSで実装する

デザインデータと実装の両方で、色以外の手掛かりを再利用可能にします。

14.1 Figmaで状態バリアントを作る

ステータスコンポーネントへ、成功、警告、エラー、情報のバリアントを用意します。

各バリアントでは色だけでなく、アイコンと状態名も切り替えます。デザイナーが色だけを上書きしなくてもよい構造にしてください。

14.2 グレースケールで確認する

Figma上で彩度を下げる、グレースケールのプラグインを使う、画像として書き出して白黒表示するなどの方法で確認します。

選択状態、リンク、エラー、グラフ系列が区別できなければ、非色彩の手掛かりを追加します。

14.3 CSSで状態クラスを共通化する

.status {  display: inline-flex;  align-items: center;  gap: 0.375rem;  border: 1px solid currentColor;  border-radius: 999px;  padding: 0.25rem 0.625rem;  font-weight: 600; } .status--success::before {  content: "✓"; } .status--warning::before {  content: "!"; } .status--error::before {  content: "×"; } .status--info::before {  content: "i"; }

この例では、色が適用されない場合でも記号と文字が残ります。実際の実装では、記号の意味や読み上げの重複に注意してください。

14.4 グラフへクラスを付ける

.chart-series-a {  stroke: var(--chart-series-a-color);  stroke-width: 3;  stroke-dasharray: none; } .chart-series-b {  stroke: var(--chart-series-b-color);  stroke-width: 3;  stroke-dasharray: 8 5; } .chart-series-c {  stroke: var(--chart-series-c-color);  stroke-width: 3;  stroke-dasharray: 2 4; }

SVGグラフでは、色に加えてstroke-dasharrayで線種を変更できます。各系列へテキストラベルも提供します。

14.5 自動テストだけに頼らない

コントラスト値やARIA属性の一部は自動ツールで検出できますが、「色がなくても意味が伝わるか」は人による確認が必要です。

自動検査、グレースケール確認、キーボード操作、スクリーンリーダー、実機テストを組み合わせます。

15. 色への依存を確認する監査手順

最後に、既存のUIから色への依存を発見し、改善する流れを整理します。

15.1 色を取り除いて確認する

画面をグレースケールにし、状態、リンク、選択、エラー、グラフ系列を判別できるか確認します。

意味が失われる要素を一覧化し、利用者への影響が大きいものから改善します。

15.2 主要タスクを実行する

単に画面を見るだけでなく、フォーム入力、検索、フィルター選択、保存、エラー修正、グラフ比較などを実行します。

途中で「どれが選択中か分からない」「どこがエラーか見つからない」と感じる箇所が、色への依存候補です。

15.3 コンポーネント単位で確認する

画面ごとの修正だけでは、別画面に同じ問題が残ります。ボタン、入力欄、通知、タグ、チャートなど、コンポーネント単位で確認します。

共通コンポーネントを修正すれば、多数の画面へ同じ改善を反映できます。

15.4 支援技術とユーザー設定を試す

キーボード、画面拡大、スクリーンリーダー、ダークモード、ハイコントラストモードを試します。

文字は最大200％まで拡大しても、内容や機能が失われないことがWCAG 2.2のレベルAAで求められています。拡大時に状態ラベルやエラー文が切れないことも確認してください。

15.5 改善チェックリストを運用する

設計レビューや実装レビューへ、色依存の確認項目を追加します。

実務では、次の手順で進めます。

1. 画面をグレースケールで確認する
2. 赤と緑だけで区別している要素を探す
3. エラー、成功、選択、リンクを重点的に確認する
4. 文字ラベルを追加する
5. 状態ごとに異なるアイコンを追加する
6. グラフへ線種、形状、ラベルを追加する
7. フォーカスへアウトラインを追加する
8. 文字のコントラストを計測する
9. アイコンと境界のコントラストを計測する
10. ダークモードで再確認する
11. ハイコントラストモードで操作する
12. キーボードだけで主要タスクを実行する
13. スクリーンリーダーで動的状態を確認する
14. 共通コンポーネントへ改善を反映する
15. レビュー項目として継続運用する

おわりに

色は、UIの状態や優先順位を短時間で伝えるための有効な要素です。しかし、色だけを唯一の手掛かりにすると、色覚特性、弱視、端末環境、モノクロ表示、強制配色などの条件で情報が失われる可能性があります。

色を廃止する必要はありません。色に、文字、アイコン、形状、線種、パターン、位置、太さを組み合わせます。フォームエラーには原因を説明する文章、リンクには下線、グラフには線種とラベル、選択状態にはチェックや枠線を追加してください。

設計後は、グレースケール、ダークモード、ハイコントラストモード、キーボード、画面拡大、スクリーンリーダーで確認します。色が失われても主要な情報と操作方法が残り、色が使える環境ではさらに素早く理解できるUIが、色へ依存しないアクセシブルな設計です。