基準はまず WCAG を見る

まず基準として見ておきたいのは WCAG です。

本文テキストのコントラストは、WCAG 2.2 の 1.4.3 Contrast (Minimum) で扱われています。
通常サイズのテキストは背景とのコントラスト比が 4.5:1 以上、大きなテキストは 3:1 以上が Level AA の目安です。

また、ボタンの境界、フォーム部品、アイコン、グラフのように意味を持つ非テキスト要素については、1.4.11 Non-text Contrast が関係します。
こちらは、重要な視覚情報が隣接する色に対して 3:1 以上のコントラストを持つことが求められます。

• Understanding SC 1.4.3: Contrast (Minimum) - W3C
• Understanding SC 1.4.11: Non-text Contrast - W3C

ここで大事なのは、文字だけを見ればよいわけではないということです。
リンク、ボタン、入力欄、フォーカスリング、エラー表示、タグ、チャート、地図上の線など、ユーザーが判断材料にする色はすべて確認対象になります。

デザイン段階で潰しておく

カラーコントラストは、Figma などのデザインツール上で早めに確認した方が楽です。

実装後に「この文字色と背景色だと足りない」と気づくと、コンポーネントの見た目、ブランドカラー、状態表現まで巻き戻ってしまいます。
逆に、デザイン時点で背景色、本文色、補助テキスト色、リンク色、ボタン色、枠線色の関係を見ておけば、実装ではそのルールを再現するだけで済みます。

最近は Figma 側でも Variables や Modes を使って、ライトモード、ダークモード、高コントラスト寄りのテーマなどを同じ設計の中で扱いやすくなっています。
色をただのカラーパレットとして並べるのではなく、text.primary、text.muted、surface.default、surface.subtle、border.default、action.primary のように、役割ベースで管理しておくと実装にもつなげやすいです。

• Overview of variables, collections, and modes - Figma
• Modes for variables - Figma

特に確認したいのは、派手なブランドカラーではなく、むしろグレーまわりです。
補足テキスト、日付、ラベル、プレースホルダー、非アクティブに近い表現は、デザイン上は控えめで美しく見えても、実際には読みにくくなりがちです。

CSS変数で役割ごとに管理する

実装では、色を直接 #777 のように各所へ書くより、CSS 変数やデザイントークンとして管理した方が安全です。

たとえば、以下のように役割ごとに分けておきます。

:root {
  --color-bg: #ffffff;
  --color-bg-subtle: #f5f5f2;
  --color-text: #1f1f1f;
  --color-text-muted: #666666;
  --color-border: #d8d4cc;
  --color-link: #1f4b99;
}

:root[data-theme='dark'] {
  --color-bg: #141414;
  --color-bg-subtle: #202020;
  --color-text: #f1f1ed;
  --color-text-muted: #b8b8b0;
  --color-border: #3a3a35;
  --color-link: #9db9ff;
}

こうしておくと、ライトモードとダークモードで同じコンポーネントを使いながら、色だけを切り替えられます。
また、text-muted が薄すぎる、border が見えない、link が本文色と区別しづらい、といった問題も、変数側を見直せばまとめて調整できます。

注意したいのは、色名を見た目だけで付けないことです。
--blue や --gray-500 だけでは、その色が本文なのか、背景なのか、枠線なのか、状態表示なのかが分かりません。実装が大きくなるほど、役割ベースの名前の方が崩れにくくなります。

ブラウザで実際の状態を確認する

デザイン上で問題がなくても、ブラウザで見ると印象が変わることがあります。
フォントレンダリング、背景画像、半透明レイヤー、ホバー状態、フォーカス状態、ダークモード、OS側の表示設定などが入るためです。

確認方法はいくつかあります。

• Chrome DevTools や Firefox DevTools のアクセシビリティ関連機能で確認する
• axe DevTools などのブラウザ拡張でページ全体をチェックする
• Colour Contrast Analyser のようなアプリで画面上の色を拾って確認する
• Storybook やコンポーネントカタログ上で状態別に確認する
• Playwright などで主要ページをスクリーンショット化し、目視確認しやすくする

自動チェックは便利ですが、すべてを拾えるわけではありません。
特に、画像上のテキスト、グラデーション、半透明のカード、地図やグラフ、ホバーしないと出ない UI、無効状態と有効状態の違いなどは、人間の確認も必要です。

色だけに頼らない

コントラストを満たしていても、色だけで意味を伝えるのは避けたいところです。

たとえば、エラーを赤だけで示すのではなく、テキスト、アイコン、枠線、余白、文言も組み合わせる。
グラフでは、色だけで系列を分けるのではなく、ラベル、線種、マーカー、凡例の近接配置も使う。
リンクは色だけでなく、文脈や下線、ホバー、フォーカス表示も含めて認識できるようにする。

Webサイトは、見る環境がかなりばらつきます。
屋外のスマートフォン、暗い部屋、低輝度設定、古いディスプレイ、色覚特性、ブラウザの拡大表示。そうした条件でも情報が失われにくいようにしておく方が安心です。

サイトとして管理する

最終的には、カラーコントラストは個別ページの問題ではなく、サイト全体の設計問題です。

運用しやすくするには、次のようなルールを持っておくとよさそうです。

• 本文、補助テキスト、リンク、ボタン、枠線、背景の基本色を決める
• ライトモードとダークモードの両方で確認する
• 記事カード、フォーム、ナビゲーション、タグ、地図、グラフなどの代表コンポーネントを確認する
• 新しい色を足すときは、既存の変数に置き換えられないか先に見る
• Figma の Variables と CSS 変数の役割をできるだけ揃える
• 公開前にブラウザ拡張や DevTools で主要ページを確認する

ツールは、あくまで確認のための手段です。
Color.review のようなコントラストチェッカー、Figma 上の確認機能、ブラウザの DevTools、アクセシビリティ拡張、どれも役に立ちます。

ただ、それ以上に大事なのは、色をその場の感覚で増やさないことです。
Webサイトとして扱う色を役割ごとに整理し、デザインと実装の両方で同じ考え方にしておく。そうすれば、記事やコンポーネントが増えても、読みやすさを保ちやすくなります。