色覚多様性に配慮したWeb配色｜コントラストと色だけに頼らない実践ガイド

見やすい配色は、色の選び方だけでは決まりません。
文字と背景のコントラストを確保し、色を区別できない場面でも意味が伝わるように、ラベル、形、線などを組み合わせる必要があります。

この記事では、色覚の個人差を前提に、Webサイトの配色を設計、実装、確認する順序を整理します。
最初に押さえたい原則は次の三つです。

• 文字やアイコンと背景の組み合わせごとにコントラストを確認する
• エラー、状態、リンクなどの意味を色だけで伝えない
• 自動検査だけで終えず、実際の画面と操作でも確かめる

色覚多様性への配慮が必要な理由

色覚多様性とは、色の見え方や区別のしやすさに個人差があることを表す考え方です。
同じ画面でも、特定の色の組み合わせが似て見えたり、明るさの差が小さい要素を見分けにくかったりする場合があります。

問題になるのは、配色の好みではなく、色が情報の唯一の手掛かりになっている設計です。
たとえば、入力欄を赤い枠に変えるだけでは、どこに何の問題があるのかを色の違いから判断しなければなりません。

枠の色に加えて「メールアドレスを確認してください」という文を表示すれば、色を区別しにくい利用者にも内容が伝わります。
この考え方は、警告、グラフ、ステータス、リンク、ボタンの状態にも共通します。

コントラスト比の読み方

コントラスト比は、文字などの前景色と、その背後にある背景色の明るさの差を数値で表したものです。
数字が大きいほど明るさの差も大きくなります。

WCAGで示される文字の基準は、次のように整理できます。

コントラスト比は、色名やHEX値を一つだけ見ても判断できません。
「#333333の文字と#FFFFFFの背景」のように、隣り合う前景色と背景色を一組として測ります。

表の数値を満たすことは、読みやすさを確認する一部の条件です。
色だけで意味を伝えていないか、キーボードフォーカスが見えるか、画像内の情報に代替手段があるかなど、別の確認も必要です。
WCAG 2.2の全体像と実務上の考え方も併せて確認すると、配色以外の要件との関係をつかみやすくなります。

色だけに頼らない伝え方

色は情報を見つけやすくする補助として使えますが、意味を色だけに背負わせると、区別できない利用者に情報が届きません。
次のように、文字や形を同時に使います。

グラフや表を詳しく設計するときは、データ表とグラフのアクセシビリティ設計も参考になります。

配色を組み立てる手順

1. 色が意味を持つ場所を洗い出す

本文、リンク、ボタン、フォーム、警告、ステータス、グラフを画面ごとに確認します。
通常時だけでなく、ホバー、フォーカス、選択中、無効、エラーといった状態も対象です。

2. 色相、明度、彩度を分けて考える

• 色相：赤、青、黄など、色の種類です。
• 明度：色の明るさです。
• 彩度：色の鮮やかさです。

色相を離すだけでは、見分けやすさを保証できません。
明度差を確保し、さらにラベル、輪郭、形などを加えることで、色を区別しにくい場面でも情報を追いやすくなります。

3. 前景色と背景色を組み合わせて測る

パレット表に色を一つずつ並べるのではなく、本文と背景、リンクと背景、ボタン文字とボタン背景のように、実際に隣り合う組み合わせを記録します。
文字サイズや太さも併記すると、どの基準で確認したかを後から追えます。

4. モノクロ表示と色覚シミュレーターで確認する

モノクロ表示は、明度差や情報の階層が保たれているかを見つける簡易確認に向いています。
色覚シミュレーターは、似て見える組み合わせを探す補助として使います。

ただし、どちらか一方を通過しても、利用者全員の見え方を確認できたことにはなりません。
コントラスト測定と実画面の操作確認を組み合わせます。

HTMLとCSSの実装例

次の例では、エラーを色だけに任せず、記号と具体的な文で示しています。
送信ボタンには、キーボード操作時に見えるフォーカス表示を用意しています。

<p class="status status-error">
  <span aria-hidden="true">!</span>
  メールアドレスを確認してください
</p>

<button type="submit" class="btn-primary">送信</button>

.status-error {
  color: #333333;
  border-left: 4px solid #D9534F;
  padding: 0.75rem 1rem;
}

.btn-primary {
  background-color: #005A9E;
  color: #FFFFFF;
  padding: 0.8em 1.2em;
  border: 2px solid transparent;
  border-radius: 4px;
}

.btn-primary:focus-visible {
  outline: 3px solid #111111;
  outline-offset: 3px;
}

この色指定は実装方法を示す例です。
実際には、ページの背景、文字サイズ、ボタンの周囲色を含む完成画面でコントラストを測ります。
リンクとボタンの状態設計は、リンクとボタンのアクセシビリティガイドで詳しく確認できます。

自動検査と手動確認の進め方

1. 自動検査：axe、Lighthouse、コントラストチェッカーなどで、機械的に判定できる問題を探します。
2. 実画面の確認：通常時と各操作状態について、文字、アイコン、境界線、フォーカス表示を確認します。
3. モノクロ表示とシミュレーション：色を外したときに、意味や情報の順序が失われないかを確かめます。
4. キーボード操作：Tabキーで移動し、現在位置とボタンの状態が見えるかを確認します。
5. 利用者による確認：可能であれば、異なる見え方を持つ利用者に実際の課題を確かめてもらいます。

自動検査は、数値やコードから判断できる問題を早く見つけるために役立ちます。
一方、色以外の手掛かりが理解しやすいか、操作の途中で迷わないかまでは自動検査だけで判断できないため、手動確認を残します。

公開前後に確認するチェックリスト

• 本文、リンク、ボタンの文字と背景を組み合わせて測定したか
• エラーや状態を、色だけでなく文字や形でも伝えているか
• 通常時、ホバー、フォーカス、選択中の違いが見えるか
• グラフの系列をラベルや線種でも区別できるか
• モノクロ表示や色覚シミュレーターで崩れを確認したか
• 自動検査の後に、キーボード操作と実画面を確認したか
• 画面やコンテンツの変更後に再検査する担当と時期を決めたか

見やすさを配色から運用へつなげる

色覚多様性に配慮した設計は、特定の色を避けることではありません。
コントラストを組み合わせごとに測り、色以外の手掛かりを加え、実際の画面で確認することが中心です。

デザイン、実装、確認の各工程で同じ基準を共有すれば、更新による見えにくさも見つけやすくなります。
配色表だけで終わらせず、公開後の変更時にもチェックリストを使って見直してください。