WCAG 1.4.1: 色の使用

このルールの意味

WCAG 1.4.1「色の使用」は、知覚可能（Perceivable）という原則の下にあるレベルAの達成基準です。ここでは、情報を伝える、操作を示す、反応を促す、または視覚要素を区別するための視覚的手段として、色だけを唯一の手段として使用してはならないと定めています。ここでのキーワードは「only（唯一）」です。色の使用自体が禁止されているわけではなく、必ず少なくとも1つ以上の追加の視覚的手がかり（テキストラベル、パターン、形状、枠線、アイコン、タイポグラフィ上の処理など）を伴わせる必要があります。そうすることで、ユーザーが色の違いを知覚できるかどうかに関わらず、同じ情報にアクセスできるようにします。

この達成基準は、幅広いインターフェイス要素を対象とします。エラーを示すために入力欄が赤くなるフォームは、その赤色が唯一の指標である場合、この基準に不適合となります。データ系列を区別するのに色だけを使っているチャートやグラフも不適合です。本文中のリンクが、下線や太字、その他の色以外の差別化要素なしに、色だけでスタイル付けされている場合も、本文ブロック内に現れるときにはこの基準に不適合となります。ナビゲーションの状態、ステータスバッジ、進捗インジケーター、必須フィールドのマーカー、インタラクティブなアフォーダンスなどもすべて対象範囲に含まれます。

適合している実装では、色と並行して少なくとも1つの非色ベースの仕組みを提供します。例えば、赤い枠線で囲まれたエラーフィールドに、エラーアイコンと説明的なテキストラベルを併せて表示する、円グラフで明確に異なる色とパターン塗りを併用する、本文中のリンクを異なる色かつ下線付きにする、などです。不適合な実装は、色の変化のみに依存しており、同じ意味を伝える形状、枠線、パターン、ラベル、テキストの違いが存在しません。

WCAG仕様には重要な適用範囲の明確化があります。この達成基準は、情報を伝える視覚的手段としての色に特化して適用されます。すべての色を排除することを求めるものではなく、コントラスト比についても扱いません（それは1.4.3と1.4.11で扱われます）。また、色に情報的な意味がないロゴや装飾的な画像には適用されません。この達成基準が対象とするのは、2色以上を区別できないユーザーが、情報や機能へのアクセスを失ってしまう状況に限られます。

なぜ重要か

世界で約3億人が何らかの色覚異常（色覚障害）を抱えており、世界保健機関によると、世界で22億人が近見または遠見の視覚障害を持っています。色覚障害は、北ヨーロッパ系の男性では約12人に1人、女性では約200人に1人に影響します。つまり、典型的な100人のオーディエンスのうち、およそ5〜8人は、成功と失敗を示すインターフェイスで最もよく使われる色の組み合わせの1つである赤と緑を確実に区別することができません。

第二色覚異常（deuteranopia）や第一色覚異常（protanopia）（いわゆる赤緑色覚障害）のユーザーにとって、無効なフィールドを赤色だけで強調表示するフォームは、エラー指標として事実上見えないのと同じです。彼らはフォームを送信しても明らかな変化が見えず、システムが壊れているか、送信が受理されたと結論づけてしまいます。これは些細な不便ではなく、金融取引の失敗、医療予約の失念、行政サービス申請の不成功、あるいはECサイトでの決済完了の不能といった結果を招きかねません。

高コントラスト表示やカスタム配色に依存するロービジョンのユーザーは、システムレベルの色の上書きを有効にしている場合があります。そのような環境では、制作者が指定した色が完全に置き換えられることがあり、ユーザーの色知覚能力に関わらず、色だけの手がかりは意味をなさなくなります。同様に、白黒印刷された文書や、モノクロの電子ペーパーディスプレイでコンテンツにアクセスするユーザーは、すべての色の差異を失います。

障害の有無を超えて、この達成基準は幅広い人々に恩恵をもたらします。屋外で強い日光の下でモバイルを使うユーザー、色再現性の低い品質の悪い画面を使うユーザー、加齢に伴い色の知覚が自然に低下する高齢ユーザーなどです。アクセシブルな色の使い方は、間接的にSEOの向上にもつながります。この達成基準を満たすために追加される説明的なテキストラベルは、検索エンジンがインデックス可能な意味的コンテンツを増やすからです。ユーザビリティの観点からも、色と並行して明示的なテキストラベルや視覚的手がかりを提供することで、インターフェイスの意味が冗長かつ強化され、すべてのユーザーの認知負荷を軽減します。

関連する Axe-core のルール

WCAG 1.4.1は手動テストを必要とします。なぜなら、自動ツールは色が情報伝達の唯一の手段として使われているかどうかを確実に判断できないからです。これは意味論的かつ視覚的な判断です。自動ツールは、2つの要素の色が異なることは検出できますが、その色が唯一の差別化要因なのか、またはその色の違いによって伝えられる情報が別の仕組みによっても伝えられているのかを判断することはできません。その判断を行うには、ツールがデザインの意図と完全な視覚レンダリングのコンテキストを理解する必要があります。

• 手動テストが必要 — リンク色の識別: Axe-core は、本文テキスト内のリンクが、色以外の手段によって周囲の非リンクテキストと区別可能かどうかを自動的に検証することはできません。人間のテスターがページを目視で確認し、段落内にインラインで現れるリンクに、下線、太字、目に見えるアイコンなどの非色ベースの追加手がかりがあることを確認する必要があります。自動ツールはリンクの存在は検出できますが、その視覚的な提示が色相の違いだけに依存しているかどうかは判断できません。
• 手動テストが必要 — フォームのエラー状態: フォームフィールドがエラー状態になったとき、自動ツールは、赤い枠線や背景色などの視覚的変化がエラーの唯一の指標なのか、それともエラーアイコン、テキストメッセージ、その他の非色ベースの手がかりを伴っているのかを判断できません。テスターはフォームを操作し、バリデーションエラーを発生させ、そのエラーが視覚的にどのように伝えられているかを確認する必要があります。
• 手動テストが必要 — データビジュアライゼーション: カテゴリ、データ系列、領域を区別するために色を使用するチャート、グラフ、地図、図は、1.4.1への適合性について自動的に評価することができません。人間のテスターが、色分けされた要素を区別するためにパターン、ラベル、テクスチャが併用されているかどうかを評価する必要があります。
• 手動テストが必要 — ステータスインジケーター: 状態を伝えるために色に依存しているバッジ、タグ、ステータスインジケーター（オンライン／オフラインインジケーターや注文ステータスラベルなど）は、自動的にフラグを立てることができません。テスターは、各ステータスがテキストラベル、アイコン、形状の変化のいずれかによっても伝えられていることを確認する必要があります。

テスト方法

1. 自動スキャンによるベースライン: ページに対して axe DevTools、Lighthouse、または Accsible アクセシビリティチェッカーを実行します。これらのツールは1.4.1の違反を直接フラグ付けすることはありませんが、色のみの使用と相関する、代替テキストの欠如、不十分なコントラスト、フォームラベルの欠如などの関連問題を検出する場合があります。フラグ付けされた問題を記録し、それらを手動検査の出発点として利用します。axe DevTools では、ブラウザ拡張機能を開き、「Analyze」をクリックし、違反リストに加えて「Needs Review」カテゴリも確認します。一部の色関連の問題はそこに表示される場合があります。
2. グレースケールシミュレーション: ブラウザ拡張機能またはOSのアクセシビリティ機能を使用して、ページをグレースケール（彩度ゼロ）で表示します。macOSでは、「システム設定」>「アクセシビリティ」>「ディスプレイ」に移動し、「グレイスケールを使用」を有効にします。Windowsでは、「設定」>「簡単操作」>「カラー フィルター」に移動し、「グレースケール」を選択します。あるいはブラウザのDevToolsを使用します。Chromeでは、DevToolsを開き、Ctrl+Shift+P（Macでは Cmd+Shift+P）を押し、「Emulate vision deficiencies」と入力して「Achromatopsia」を選択します。グレースケールで、すべてのインタラクティブ要素、ステータスインジケーター、フォームフィールド、チャート、リンクを確認し、色がなくてもすべての情報が理解可能であることを確認します。
3. 色覚障害シミュレーション: Chrome DevTools の視覚障害エミュレーター（上記と同じ手順）を使用して、Deuteranopia、Protanopia、Tritanopia をシミュレートします。各シミュレーションについて、フォーム送信時のエラー、チャートでのデータ解釈、アクティブ／非アクティブ状態間のナビゲーションなど、すべてのユーザーフローを一通り実行し、情報が失われていないことを確認します。Coblis Color Blindness Simulator や Colour Oracle（デスクトップアプリケーション）のようなツールを使用して、画面全体の色覚障害をシミュレートすることもできます。
4. 本文中のリンク — 手動チェック: ナビゲーションメニューや単独のリンクリストではなく、本文の段落内に現れるすべてのハイパーリンクを特定します。そのような各リンクについて、少なくとも1つの非色ベースの仕組みによって周囲の非リンクテキストと視覚的に区別できることを確認します。最も一般的で許容される仕組みは下線です。リンクが色の違いだけに依存している場合は不適合です。
5. フォームバリデーション — 手動チェック: キーボード操作（Tabでフォーカス移動、EnterまたはSpaceで操作）を使ってフォームに入力し、あえて必須フィールドを空のままにするか、無効なデータを入力します。フォームを送信します。エラーがどのように伝えられているかを目視で確認します。エラーの表示が色だけで行われていないことを確認します。各エラーには、色の変化に加えて、目に見えるテキスト説明、アイコン、またはその両方が必要です。
6. スクリーンリーダー検証（NVDA + Firefox）: Firefox でページを開き、NVDA を起動した状態で使用します。仮想カーソルを使って、すべてのフォームフィールド、チャート、ステータスインジケーターを順に移動します。エラーメッセージ、ステータスラベル、データの説明がスクリーンリーダーによって読み上げられることを確認します。これはプログラム的なレイヤーを検証するものであり、視覚的な1.4.1の要件（色覚障害のある見えるユーザー向け）を満たすものではない点に注意してください。
7. チャートとグラフの確認: 各データビジュアライゼーションについて、色を意図的に無視し、形状、パターン、テキストラベルだけを使ってデータを解釈しようとします。色がなければビジュアライゼーションが解釈不能になる場合は不適合です。テキストベースの代替（データテーブル、パターン付き凡例、直接データラベル）が用意されていることを確認します。

修正方法

本文中のインラインリンク — 不適切な例

<!-- Link is distinguishable from surrounding text only by color.
     A user with color blindness cannot identify it as a link. -->
<p>
  Please review our
  <a href='/privacy' style='color: #0057b8; text-decoration: none;'>privacy policy</a>
  before continuing.
</p>

本文中のインラインリンク — 適切な例

<!-- Link is underlined in addition to being a different color.
     The underline provides a non-color visual cue that identifies it as a link. -->
<p>
  Please review our
  <a href='/privacy' style='color: #0057b8; text-decoration: underline;'>privacy policy</a>
  before continuing.
</p>

フォームのエラー状態 — 不適切な例

<!-- Error is communicated only by a red border.
     A color-blind user cannot distinguish this from a normal field. -->
<label for='email'>Email address</label>
<input
  type='email'
  id='email'
  name='email'
  class='input-error'
  aria-label='Email address'
/>
<!-- .input-error { border: 2px solid #cc0000; } -->

フォームのエラー状態 — 適切な例

<!-- Error is communicated by a red border AND a visible error icon AND a text message.
     The text message is also linked via aria-describedby for assistive technology. -->
<label for='email'>Email address</label>
<input
  type='email'
  id='email'
  name='email'
  class='input-error'
  aria-describedby='email-error'
  aria-invalid='true'
/>
<p id='email-error' class='error-message'>
  <svg aria-hidden='true' focusable='false' class='error-icon'>
    <!-- error icon SVG path data -->
  </svg>
  Please enter a valid email address.
</p>

色のみのチャート凡例 — 不適切な例

<!-- Bar chart where categories are differentiated by fill color alone.
     Users with color blindness cannot distinguish the categories. -->
<svg role='img' aria-label='Quarterly sales by region'>
  <rect x='10' y='50' width='40' height='100' fill='#e63946' />
  <rect x='60' y='20' width='40' height='130' fill='#2a9d8f' />
  <rect x='110' y='70' width='40' height='80' fill='#e9c46a' />
</svg>
<ul class='chart-legend'>
  <li><span class='swatch red'></span> North</li>
  <li><span class='swatch green'></span> South</li>
  <li><span class='swatch yellow'></span> West</li>
</ul>

色のみのチャート凡例 — 適切な例

<!-- Bars use both distinct colors AND distinct pattern fills (via SVG patterns).
     Legend items include a text label. An accessible data table is also provided. -->
<svg role='img' aria-label='Quarterly sales by region — data table below'>
  <defs>
    <pattern id='pattern-north' patternUnits='userSpaceOnUse' width='6' height='6'>
      <line x1='0' y1='6' x2='6' y2='0' stroke='#e63946' stroke-width='1.5'/>
    </pattern>
    <pattern id='pattern-south' patternUnits='userSpaceOnUse' width='6' height='6'>
      <circle cx='3' cy='3' r='2' fill='#2a9d8f'/>
    </pattern>
    <pattern id='pattern-west' patternUnits='userSpaceOnUse' width='6' height='6'>
      <rect x='0' y='0' width='3' height='3' fill='#e9c46a'/>
    </pattern>
  </defs>
  <rect x='10' y='50' width='40' height='100' fill='url(#pattern-north)' />
  <rect x='60' y='20' width='40' height='130' fill='url(#pattern-south)' />
  <rect x='110' y='70' width='40' height='80' fill='url(#pattern-west)' />
</svg>
<ul class='chart-legend'>
  <li><span class='swatch swatch-north' aria-hidden='true'></span> North (diagonal lines)</li>
  <li><span class='swatch swatch-south' aria-hidden='true'></span> South (dots)</li>
  <li><span class='swatch swatch-west' aria-hidden='true'></span> West (squares)</li>
</ul>
<table>
  <caption>Quarterly sales by region (data table)</caption>
  <thead><tr><th>Region</th><th>Sales (units)</th></tr></thead>
  <tbody>
    <tr><td>North</td><td>100</td></tr>
    <tr><td>South</td><td>130</td></tr>
    <tr><td>West</td><td>80</td></tr>
  </tbody>
</table>

ステータスバッジ — 不適切な例

<!-- Order status communicated only by background color.
     "Pending" (yellow), "Shipped" (blue), and "Delivered" (green) are
     visually identical to many color-blind users. -->
<span class='badge badge-pending'></span>
<span class='badge badge-shipped'></span>
<span class='badge badge-delivered'></span>

ステータスバッジ — 適切な例

<!-- Status is communicated by color AND a visible text label.
     The text label is the primary conveyor of meaning. -->
<span class='badge badge-pending'>Pending</span>
<span class='badge badge-shipped'>Shipped</span>
<span class='badge badge-delivered'>Delivered</span>

よくある間違い

• 本文中のインラインリンクから下線を削除し、色だけに頼ること: 本文の段落内のアンカー要素に対して text-decoration: none を設定することは、最も一般的な1.4.1の不適合の1つです。下線はリンクのデフォルトの非色ベースの手がかりです。太字やアイコンなどの別の非色ベースの差別化要素を追加せずに下線を削除すると、そのリンクが周囲の異なる色のテキスト内に現れるたびに即座に不適合となります。
• 合否状態に赤／緑の色の組み合わせを、追加のアイコンやテキストなしで使用すること: 失敗に赤、成功に緑という色分けは文化的には直感的ですが、まさに最も一般的な色覚障害である第二色覚異常や第一色覚異常のユーザーにはアクセシブルではありません。これらの色は必ず、明確に異なるアイコン（チェックマークとXなど）と明示的なテキストラベル（「Valid」と「Error」など）と組み合わせて使用してください。
• 必須フォームフィールドを色付きのアスタリスクだけで示すこと: フィールドラベルの横にある赤いアスタリスク（*）は、そのアスタリスク自体に凡例や目に見えるテキストによる説明がない場合、色によって必須であることを伝えていることになります。修正方法は、フォームの近くに「* indicates required field」のような目に見える注記を含め、アスタリスク自体が色以外の意味を持つようにすることです。
• ナビゲーションメニューで、アクティブ／選択状態を色だけで示すこと: 現在アクティブなナビゲーション項目を、フォントの太さの変更、下線の追加、枠線インジケーターの追加などを行わずに、テキストや背景色の変更だけで強調表示すると、色覚障害のあるユーザーは自分がどのページにいるのかを特定できません。
• ラベルを追加せずに、色の手がかりを繰り返すだけのチャートツールチップ: 一部のチャートライブラリは、データ系列に対応する色見本を表示するツールチップを出しますが、その系列名のテキストラベルを表示しないことがあります。ツールチップがデータの区別が行われる唯一の場所であり、そこが色見本だけに依存している場合は不適合です。
• 完了状態を示すのに色だけが変化する進捗ステップ: 複数ステップのフォームウィザードでは、完了したステップを緑の背景、これからのステップをグレーの背景でスタイル付けすることがよくあります。色の変化に「Completed」「Current」「Upcoming」といったテキストやチェックマークのアイコンが伴わない場合、ステップの状態は色だけで伝えられていることになります。
• 入力バリデーションを示すためにプレースホルダーテキストの色だけに頼ること: プレースホルダーテキストの色を変更する（例: エラー時に赤にする）ことは、色だけの手がかりであると同時に、別の理由からもアクセシブルではありません（プレースホルダーテキストはラベルやエラーメッセージの代わりにはなりません）。バリデーション状態は、永続的で目に見えるエラーメッセージ要素を通じて伝える必要があります。
• ARIAラベルだけで1.4.1を満たしているとみなすこと: 要素に aria-label や aria-describedby を追加すると、その情報はスクリーンリーダーユーザーには提供されますが、1.4.1は視覚的な達成基準です。色覚障害のある見えるユーザー向けに、非色ベースの視覚的手がかりを要求しています。プログラム的なテキスト代替だけでは不十分です。両方が必要ですが、ARIAだけでは1.4.1に適合しません。
• 表の行やセルを、交互の背景色だけで区別すること: 交互の行色（ゼブラストライプ）は一般的には装飾的なものであり、それ自体は1.4.1の問題ではありません。しかし、背景色だけを使って特定の行やセルをグループ化したり、カテゴリ分けしたり、情報的に異なるものとして強調したりする表は、その同じグループ化や区別を伝えるテキストラベル、アイコン、ヘッダーを提供しなければなりません。
• 色だけの手がかりを「単なる装飾」として免除扱いすること: 開発者が、色付きのステータスドットや色付きのカテゴリラベルは装飾的であり情報的ではないと主張することがあります。しかし、その色を取り除く（またはグレースケールで表示する）ことで、ユーザーがインターフェイスを理解したり利用したりするのに必要な情報へのアクセスを失うのであれば、それは定義上情報的なものであり、1.4.1に準拠しなければなりません。

トルコのアクセシビリティ規制との関係

トルコの大統領通達 2025/10 は、2025年6月21日付官報第32933号で公布され、WCAG 2.2 に整合した必須のウェブおよびモバイルアクセシビリティ要件を定めています。WCAG 1.4.1「色の使用」はレベルAの達成基準であり、この通達における必須のベースライン準拠レベルに含まれます。

この通達は、公共機関に対しては1年以内、民間企業に対しては2年以内の WCAG 2.2 レベルA準拠を義務付けています。対象として明示されている組織カテゴリは、公共機関および政府機関、ECプラットフォーム、銀行および金融機関、病院および医療提供者、20万以上の加入者を持つ通信事業者、認可旅行代理店、民間輸送会社、国民教育省（MoNE）に認可された私立学校です。

これらの組織にとって、WCAG 1.4.1 に準拠しないことは規制違反にあたります。実務的には、フォームエラーを示すのに色だけを使用しているウェブポータルを持つトルコの公共機関や、オンラインバンキングインターフェイスで取引状態を色だけのステータスインジケーターで示している銀行は、この通達の要件に違反していることになります。トルコで大きく急成長しているECプラットフォームでは、商品在庫状況の色分けインジケーター、プロモーションバッジ、カートのエラーメッセージなどが一般的に使用されていますが、これらはすべて、この通達の要件に基づき、色以外の代替手段を提供しなければなりません。

1.4.1への準拠は、トルコの文脈では特に影響が大きいと言えます。政府サービス、銀行、ECにモバイルデバイスからアクセスするユーザーが多く、画面品質や周囲の照明条件によって、情報伝達の唯一の手段としての色の信頼性がさらに低下するためです。この通達の対象となる組織は、自社のすべてのデジタルプロパティにおける情報伝達手段としての色の使用を監査し、色分けされた状態にテキストラベルやアイコンによる手がかりを優先的に追加し、1.4.1を自動アクセシビリティスキャンのパイプラインと体系的な手動テストプロトコルの両方に組み込むことが、コンプライアンスプログラムの一環として推奨されます。