Keyboard shortcuts

Press ← or → to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

第8章　人間は、色を単独では見ていない

同じグレーの四角を、白い面と黒い面の上へ置きます。CSS の色の値を調べれば、二つの四角は同じです。それでも、違う明るさに見えることがあります。

画面で経験する色は、カラーピッカーに表示された一つの値だけでは決まりません。周囲の色、境界、面積、隣接関係、目の順応、ディスプレイ、周囲光、過去に見た状態が関わります。さらに Web では、色が役割、状態、操作を教え、テーマや利用者設定によって置き換わります。

色を説明する体系も一つではありません。顔料を混ぜる教育用の色相環、印刷の CMYK、ディスプレイの RGB、測色の XYZ／Lab、CSS の HSL／Oklch は、目的と媒体が違います。同じ「明度」等の語でも体系を記します。

したがって本章は、「美しいパレットの作り方」や「この色はこの感情を表す」という対応表を教える章ではありません。どの値が、どの条件で、何として見え、何を伝えているかを観察します。

この章の必修は三つです。

  1. 色の値と、周囲を含む見え方を分けて観察する
  2. 数値差、知覚差、意味差、コントラスト達成を区別する
  3. 色を変えたテーマや利用者のパレットでも、役割と状態が残るか確かめる

この章で見るもの

  • 同じ色の値と、同じに見える色の違い
  • 色相、明度、彩度と色空間
  • 小さな色見本、広い面、細線、テキスト
  • 色トークンが役割と状態を繰り返して教える仕組み
  • WCAG のコントラスト比が測るもの、測らないもの
  • エラー、グラフ、リンクを色だけで伝える問題
  • ライト、ダーク、強制色の異なる条件
  • 色の意味と文化・文脈

8.1 同じ色は、隣の色によって違って見える

二つのグレーの色片を比べます。一方は暗い周囲、もう一方は明るい周囲に置かれています。中央のピクセル値は同じでも、暗い周囲に置いた方が明るく見える場合があります。

同じ色、異なる周囲を示す図。
図 8-1　同じ色、異なる周囲

この種の現象は、同時明度対比や同時色対比等として研究されています。ただし、「隣の反対色へ必ず寄る」という一行の法則にはしません。刺激の面積、境界、配置、空間周波数、順応等によって結果が変わり、周囲へ同化するような結果もあり得ます。

値と見え方を別々に記録する

観察は次の順番にします。

  1. どの色片が明るい、赤い、鮮やかに見えたかを記録する
  2. 値を取る前に二つの値が同じか予想する
  3. CSS の指定値、計算値、最終ピクセルを調べる
  4. 周囲を隠し、色片だけを並べ直す
  5. 色片は固定して周囲だけを変える

教材図は知覚実験の結果図ではありません。人を対象に比較する場合は、色片と周囲の視角、視距離、提示時間、順応時間、観察順、ディスプレイの白色点・輝度・カラープロファイル、周囲照度を固定します。自由観察の Web 画面と統制刺激を同じ証拠にしません。

「同じ色なのに違って見える」は、見え方の報告です。「脳が補正したから」は解釈です。どの対比／同化の仕組みで説明できるかは、刺激条件と研究を照合してから考えます。

Web では Surround も状態で変わる

ボタンの色は、ページ背景、カード、画像、ホバー、フォーカスリング、隣のボタンによって見え方が変わります。色トークンだけを一覧にしても、実際の組合せは分かりません。コンポーネントを使われる文脈へ戻して見ます。

8.2 色相、明度、彩度を分けて比べる

カラーピッカーには Hue、Saturation、Lightness と書かれたスライダーがあります。便利ですが、これを人間の色経験を直接表す普遍的な三軸とは考えません。

色相・明度・彩度を色空間で読むことを示す図。
図 8-2　色相・明度・彩度を色空間で読む

色空間が違えば座標の意味が違う

同じ sRGB の色を HSL、Lab、LCH、Oklab、Oklch へ変換すると、異なる座標で表されます。HSL の Lightness、Lab／Oklab の L、WCAG 計算の相対輝度は同じ量ではありません。

  • Hue: 色相に対応する角度として表す色空間がある
  • Saturation: HSL 等、その色空間内の定義に依存する
  • Chroma: LCH／Oklch 等の色みの量に対応する座標
  • Lightness: 色空間内で定義された明るさ方向の座標
  • 相対輝度: WCAG のコントラスト計算で使う、線形化した sRGB 等から得る量

日常語として「明るい青」と言うことはできます。ただし CSS 値を設計・比較する段階では、どの色空間の何を固定したかを書きます。

発展――知覚的に均等に近い色空間も完全ではない

Oklab／Oklch 等は、sRGB の数値差より知覚差を扱いやすくする目的で利用できます。しかし、同じΔ値なら、すべての色、面積、観察者、ディスプレイで完全に同じ差へ見えるとは限りません。「Perceptual だから人間に正しい」としません。

発展――Gamut の外に出る

Display P3 で表せる色の一部は sRGB では表せません。CSS として有効でも、出力デバイスの色域外にある色があります。ブラウザは表示のために色域変換をします。デザインツールの P3 色を sRGB スクリーンショットへ変えたとき、同じ数値・同じ見え方とは限りません。

図 F02 では、色域外を隠さずマーカーで示し、元の値、変換後、実際のスクリーンショットのピクセルを分けます。

変換では元の色空間、白色点、色順応、色域変換、レンダリング意図、丸め精度と実装版を記録します。ブラウザ間の差を隠しません。

8.3 小さな色見本と、大きな色面

デザインシステムの配色ページには、小さな色見本が並びます。色見本でよく見えた色を、ページ全体の背景へ使うと、強すぎる、暗すぎると感じることがあります。

小さな色見本と大きな色面を示す図。
図 8-3　小さな色見本と大きな色面

同じ色の値でも、役割は異なります。

  • 8px の状態ドット
  • 1px の境界線
  • 16px の文字
  • ボタンの背景
  • ページ全体の面
  • 写真上の半透明な重なり

色面の構成として、面積比、反復、近接、境界の硬さ、グラデーション、透明な重なり、図と地、アクセントの位置も観察します。色名の組合せだけでなく、どの色がどれだけの面積を占め、どこで接し、どの順序で重なるかを書きます。

小さな色見本だけでは、面積、隣接色、文字とのコントラスト、長時間見る背景、状態変化を判断できません。実際の面積と役割へ置きます。

面積効果を観察するための単純な図と、文字、境界線、背景という実務上の役割へ適用する画面を分けます。役割を変えた比較を「面積だけの実験」とは呼びません。

面積だけの法則にしない

「大きい面は必ず鮮やかに見える」とは断定しません。見る距離、ディスプレイの明るさ、周囲光、境界、順応、色座標も関わります。面積の影響を比べたいなら、色の値、周囲の色、形、表示時間、距離を固定します。

スクリーンショットも中立ではない

スクリーンショットのカラープロファイル、ブラウザ、ディスプレイ、画像ビューアによって表示が変わります。P3 のスクリーンショットを sRGB 前提のツールで開けば、変換または誤解釈が起こり得ます。色を厳密に比べる図版では、元の値、プロファイル、出力形式を残します。

8.4 色は、役割と状態を繰り返して教える

同じ青がリンク、主要ボタン、選択中タブに使われていると、利用者は青を「操作できる」「選ばれている」などのルールとして学ぶかもしれません。しかし、異なる役割を同じ色だけで表すと、ルールが曖昧になる場合があります。

色が役割と状態を教えるを示す図。
図 8-4　色が役割と状態を教える

生の値ではなく役割として名前を付ける

blue-600 は配色上の位置を示します。color-action-primary、color-text-link、color-status-error などは設計上の役割を示します。このような名前を使えば自動的に正しくなるわけではありませんが、テーマごとに役割を追跡しやすくなります。

色の名前は primitive → semantic role → component → state → theme override のように参照関係を持たせ、最終的に使われた色まで追跡します。一方、意味を持つ名前は表現を均質化する命令ではありません。祝祭感や静けさなどの表現意図を別列に置き、役割の分かりやすさとブランド表現を両方評価します。

:root {
  --color-surface: oklch(98% 0.01 250);
  --color-text: oklch(24% 0.02 250);
  --color-action-primary: oklch(55% 0.18 255);
  --color-focus-ring: oklch(70% 0.17 80);
}

値を決める前に、役割と組合せを表にします。

部品状態前景背景境界線／リング色以外の手がかり
ボタン通常文字主要色なしラベル、形
ボタンフォーカス文字主要色フォーカスリングアウトライン
入力欄エラー文字面エラー境界線アイコン、エラー文、関連付け

状態を色の値一覧にしない

ホバー、フォーカス、押下中、選択中、無効、エラー、成功は異なる意味を持ちます。少し暗くするだけで、すべての状態が識別できるとは限りません。入力方法、プログラム上の状態、文言、形、位置、操作結果も確認します。

無効状態を低コントラストにすればよいという単純則にも注意します。操作不能の理由、読める必要、利用者が次にできることを状態設計として考えます。

8.5 コントラストは一つの数値だけでは語れない

「この色はコントラストが高い」と言うとき、何と何の、どのコントラストでしょう。文字と背景の相対輝度比、色相差、輪郭の局所差、知覚上の目立ち、役割の違いは別です。

コントラスト比が測るものを示す図。
図 8-5　コントラスト比が測るもの

WCAG のコントラスト比

WCAG 2.2 の文字コントラスト達成基準は、文字や文字画像と背景の相対輝度から比率を計算します。通常の文字と大きな文字で閾値が異なり、AA と AAA、例外があります。

計算用の記録では、前景、背景、透明度を合成した後の sRGB 値、相対輝度、文字サイズと太さ、達成基準番号、レベル、合否を一件の記録にします。アンチエイリアスされた文字の縁のピクセルは、CSS の文字色そのものではありません。スクリーンショットの縁から取った値と、仕様上の入力値を別表にします。

比率は重要な確認値ですが、次のすべてを測るものではありません。

  • 色相を区別できるか
  • 色の見え方の個人差全体
  • フォントの線が細く描画された結果
  • まぶしさ、ディスプレイ品質、周囲光
  • 文字の意味が理解できるか
  • ボタンが押せると分かるか
  • 視覚的階層が適切か

基準を満たした後も実際の文字を読み、拡大、フォント、環境を確認します。反対に、主観的に読めた一人の報告で達成基準を省略しません。

透明度、グラデーション、画像背景

半透明の文字や重なりでは、最終的な合成色が背景で変わります。グラデーションや写真上の文字は、値を取る位置によって比率が変わります。Hex 同士を計算するだけでなく、合成順、最も不利な背景、動的な内容を記録します。

文字以外のコントラスト

UI 部品や図形では、識別に必要な視覚情報と隣接色を特定します。「すべての境界線は 3:1」とは限りません。境界線が部品を識別する唯一の手がかりか、フォーカスリング、チェックマーク、グラフの線などの何を測るかを先に決めます。

8.6 色だけで違いを伝えない

フォームの入力欄が赤くなった、グラフの線が赤と緑、リンクが青いだけ。このような画面は、色相差を識別できないと意味が失われる可能性があります。

色だけで状態を伝えないを示す図。
図 8-6　色だけで状態を伝えない

WCAG の「色の使用」は、色を禁止していません。色に加えて情報を伝える方法を用意します。

  • エラー境界線＋エラーアイコン＋エラー文
  • グラフの色＋線種＋マーカー＋直接ラベル
  • リンク色＋下線
  • 選択色＋チェックマーク＋aria-selected
  • 必須色＋文字ラベル＋プログラム上の関連付け

明度差があれば十分か

色相だけでなく十分な相対輝度差がある場合、視覚上の追加区別として扱える条件があります。しかし、赤ならエラー、緑なら成功という色そのものの意味を答えさせるなら、比率が高くてもラベルなどが必要です。

シミュレーションの限界

色の見え方のシミュレーションは、配色内の区別が失われそうな箇所を探す補助になります。しかし、特定の人がどう見えるかを完全に再現するものではなく、当事者によるタスク確認の代替ではありません。シミュレーションの計算方法と条件を記録します。

シミュレーション前の元プロファイル、変換方法、想定する色の見え方の違い、出力プロファイルを保存します。画像だけから参加者の診断名を推定しません。

また、スクリーンリーダーに状態が伝われば、色だけに依存する問題が解決するわけでもありません。色を区別しにくい視覚利用者が支援技術を使っているとは限りません。視覚上の補助と、プログラム上の状態の両方を確認します。

8.7 ダークモードは色を反転すれば作れるか

明るいテーマの白を黒へ、黒を白へ反転すると、ダークモードらしい画面はできます。しかし、すべての役割が保たれるとは限りません。

ダークモードと強制色を示す図。
図 8-7　ダークモードと強制色

面を役割ごとに見る

ページ、カード、ポップオーバー、入力欄などの面が、明るいテーマでは影とグレー差で分かれていても、ダークテーマでは同じ黒へ潰れる場合があります。浮き上がりを明るさだけで表すか、境界線や間隔を併用するかを文脈で決めます。

画像、ロゴ、イラスト、コードの強調表示、チャート、フォーカスリング、選択表示、フォーム部品、スクロールバーも確認します。写真が明るすぎるなら画像や重なりの調整が必要かもしれません。

prefers-color-scheme はテーマの同意ではない

メディアクエリは、利用者が明るい配色か暗い配色かを望んだ設定を検出する入口です。製品内のテーマ選択、システム設定、保存値の優先順位を決めます。no-preference を特定テーマへの同意としません。

強制色はダークモードではない

強制色では、ブラウザなどのユーザーエージェントが制作者の色を利用者のシステム配色へ置き換えます。黒背景になるとは限らず、利用者は白背景、黒背景、独自色などを選べます。

制作者の色が置換されると、影、背景画像、色だけで示した状態が消える場合があります。システム色、境界線、アウトライン、文字、ネイティブ部品を使い、Windows 実環境で確認します。forced-color-adjust: none で全ての部品を固定するのは、利用者の選択を奪う可能性があります。

明るいテーマ、暗いテーマ、強制色は「明るさを三段階で変える」比較ではありません。それぞれの条件で、役割と状態が残るかを見ます。

8.8 色の意味は文化と文脈で変わる

赤はエラー、危険、停止として使われることがあります。同じ赤は祭りのアクセント、セール、祝意、チームカラーにもなります。色自体に一つの意味が埋め込まれているわけではありません。

色の意味は文脈で変わるを示す図。
図 8-8　色の意味は文脈で変わる

「日本では白は〇〇、国 A では赤は〇〇」という一覧も、理解の入口に留めます。一つの国や文化に、単一の意味があるわけではありません。領域、時代、宗教、地域、ブランド、世代、UI の慣習、周囲の文字が関わります。

図 F08 では同じ赤を、エラー、祭の見出し、売り切れ、値下げへ置きます。色の値を固定し、ラベルと領域だけを変えます。読者が理解した意味と、その根拠を記録します。架空の「国別正答率」は載せません。

Web の状態では、製品内の反復によって意味を学ぶこともあります。最初から普遍的に理解されると仮定せず、ラベル、アイコン、位置、操作結果でルールを教えます。

8.9 問い――この色の差は、何を伝え、誰に見えるか

文化祭のチケットフォームを見ます。座席状況グラフ、入力エラー、リンク、主要操作、写真上の案内、明るいテーマと暗いテーマがあります。

章末統合課題を示す図。
図 8-9　章末統合課題

基準条件

sRGB ディスプレイ、明るいテーマ、100% ズーム、通常の制作者色から始めます。次に一軸ずつ、暗いテーマ、強制色、色だけの補助なし、写真差し替え、P3 対応環境へ変えます。色の厳密な知覚実験ではなく、Web 画面の観察とタスク比較です。

操作と記録の順序

  1. 注釈なしで、最初に見た色面と要素を記録する
  2. チケットを選び、入力エラーを見つけて修正する
  3. 座席グラフの二系列を説明する
  4. CSS 値、計算後の色、実際に使われた色、コントラスト記録を開く
  5. 明るいテーマ、暗いテーマ、強制色を一つずつ切り替える
  6. 色だけの補助を外し、同じタスクを行う

記録表は「条件／値・色空間／観察／役割・状態／代替仮説／確認方法」の 6 列にします。実機の強制色がない読者には、Windows 実機スクリーンショット、システム色対応表、キーボード操作動画、DOM とアクセシビリティツリーの記録を配布します。エミュレーションだけを実機結果とは呼びません。

問い

  1. 同じ色の値なのに違って見える箇所はあるか
  2. 各色は、値ではなく何の役割や状態として使われているか
  3. 色相を消してもエラー、リンク、座席状態を区別できるか
  4. コントラスト比は、どの前景と背景の何を測ったか
  5. 明るいテーマ、暗いテーマ、強制色で、何の意味や境界が失われたか
  6. その仮説を、値、スクリーンショット、人のタスクのどれで確かめるか

答えの例

六つの問いへの回答では、次の観点を最低限含めます。

  1. 文脈: 同じ値の要素と異なる周囲色を指し、値を取る前後を分ける
  2. 役割: red-600 でなく、エラー、操作、面などの役割と状態を書く
  3. 色以外: 文字、形、模様、プログラム上の状態を確認する
  4. 比率: 対象の前景と背景、達成基準、レベル、文字か文字以外かを特定する
  5. テーマ: 消えた境界、フォーカス、状態、画像をテーマごとに記録する
  6. 証拠: CSS 値、スクリーンショット、タスク観察が支える範囲を限定する

具体例にすると、次のようになります。

  1. 同じ oklch(60% 0.12 250) の座席ドットが、白い表の上より濃紺のヘッダー上で明るく見えた。ドットの値を固定し、周囲色だけを入れ替える。
  2. red-600 はエラー境界線と売り切れバッジに使われるが、前者は入力状態、後者は在庫状態である。色名ではなく二つの役割を分ける。
  3. エラーの赤をグレーへ置換すると境界線の差だけが残り、理由が分からない。エラー文、アイコン、入力欄との関連を追加して修正タスクを行う。
  4. 主要ボタンの文字と背景について SC 1.4.3 AA を測った。グラフ線やフォーカスリングの合否をこの記録からは結論しない。
  5. 強制色で座席グラフの塗りが同じシステム色へ置換された。直接ラベルとマーカー形状で二系列を追えるか確認する。
  6. CSS 記録は値と達成基準、スクリーンショットは特定環境のピクセル、人のタスクはその条件での行動を支える。どれか一つを全体の証拠にしない。

入力エラーは境界線だけが赤へ変わり、文字ラベル、アイコン、エラー文がない。赤を区別できない場合、どの入力欄に何の問題があるか視覚的に分からない可能性がある。エラー文とアイコンを追加し、入力欄へプログラム上も関連付けた条件で、エラー発見と修正タスクを確認する。

座席グラフの赤線と緑線は、白背景との文字コントラスト比を測っても意味がない。図形として線と隣接色を特定し、線種、マーカー、直接ラベルを追加する。比率達成と系列識別タスクを別に確認する。

ダークテーマでカードの影が見えなくなり、ページ面とカード面が同じ計算後の色になった。問題があるなら「ダークモードのコントラスト不足」ではなく、カード境界を示していた唯一の手がかりが影で、それがダークテーマで知覚できないという仮説になる。間隔、境界線、面の差を一軸ずつ比べる。

別の答え方

主要操作が見つからない原因は色ではなく、同じ大きさのボタンが三つあること、ラベルが曖昧なこと、位置がタスクの流れから離れていることかもしれません。色の鮮やかさを上げても改善しなければ、階層、文言、配置を調べます。

写真上の文字が読みにくい理由は、平均比率でなく、文字の背後にある局所的な明暗変化かもしれません。写真を固定して重なりだけを変え、最も不利な位置の値と実際の読字を確認します。

よくある考え方

コントラスト比を満たしたので、この配色はアクセシブルである。赤は危険、緑は安全だから分かる。

注意点

一つの達成基準を、アクセシビリティ全体の合格証にしています。色そのものへ依存する意味、状態のプログラム上の関連付け、テーマ変更、フォント、タスク、環境は別に確認します。色の意味も文脈を越えて固定できません。

必須セルフチェック

  • 色の値、周囲色、見え方を別々に記録できる
  • 数値差、知覚差、意味差、コントラスト達成を区別できる
  • 明るいテーマ、暗いテーマ、強制色で役割と状態を確認できる

発展セルフチェック

  • 色空間、色域、プロファイル、透明度の合成を記録できる
  • 文字、文字以外、色の使用の対象を分けられる
  • シミュレーションを当事者の見え方やタスク検証の代替にしていない

参考

  • W3C, CSS Color Module Level 4. CSS の色空間、変換、補間、色域変換を確認する仕様です。https://www.w3.org/TR/css-color-4/
  • W3C WAI, Understanding SC 1.4.1: Use of Color. 色だけに意味を依存させない達成基準の公式解説です。https://www.w3.org/WAI/WCAG22/Understanding/use-of-color
  • W3C WAI, Understanding SC 1.4.3: Contrast (Minimum). 文字コントラストの対象、式、例外を確認できます。https://www.w3.org/WAI/WCAG22/Understanding/contrast-minimum.html
  • W3C WAI, Understanding SC 1.4.11: Non-text Contrast. UI 部品などで何を測るかを確認できます。https://www.w3.org/WAI/WCAG22/Understanding/non-text-contrast.html
  • W3C, CSS Color Adjustment Module Level 1. color-scheme、強制色、システム色を確認する仕様です。https://www.w3.org/TR/css-color-adjust-1/
  • W3C, Media Queries Level 5. prefers-color-scheme と forced-colors の定義を確認できます。https://www.w3.org/TR/mediaqueries-5/
  • Bosten, J. M. and Mollon, J. D. (2012), “New Laws of Simultaneous Contrast?” 同時 Contrast の単純則と条件を検討する専門的な研究です。
  • CIE, Colorimetry — Part 6: CIEDE2000 Colour-Difference Formula. 色差式の標準です。Web 画面の意味理解や可読性の尺度ではありません。https://cie.co.at/publications/colorimetry-part-6-ciede2000-colour-difference-formula-1
  • International Color Consortium, ICC.1 Profile Specification. デバイス間のカラーマネジメントを調べる専門仕様です。https://www.color.org/specification/ICC.1-2022-05.pdf

本章の E03「面積」と E09「文化的意味」は、無条件の普遍則を採用していません。図版は本書内比較、意味は対象文脈での理解確認として扱います。

検索キーワード: simultaneous color contrast assimilation、CSS Color 4 Oklch gamut、WCAG use of color、forced colors system colors、dark mode color accessibility、color meaning cross cultural context