ログイン

ウェブデザインにおける色のコントラスト：コントラストの問題をテストし、修正する方法

2 min read
コントラストWcagデザイン

色のコントラスト不良は、ウェブにおける最も一般的なアクセシビリティ違反であり、ほとんどのウェブサイトに影響しています。このガイドでは、WCAG が具体的に何を求めているのか、適切なツールを使ってコントラスト不良を見つける方法、そしてブランドのビジュアル・アイデンティティを損なうことなく CSS でそれらを修正する方法を、順を追って解説します。

あなたのウェブサイトに訪れた人が、弱視で、日差しの強いカフェでスマートフォンの明るさを最大にして座っているところを想像してみてください。もしあなたの薄いグレーの本文テキストが白い背景の上に載っていたら、その人はあなたのコンテンツをまったく読めません — どれだけ丁寧に言葉を選んで書いたとしてもです。この状況は仮定の話ではありません。コントラストの低いテキストは、2026年初頭の時点で、上位100万件のホームページの83.9%で検出されており、7年連続でウェブ上でもっとも一般的に特定されるアクセシビリティ上の不具合となっています。問題のある各ホームページでは、平均して34個の別々の事例が見つかっています。

色のコントラストが思っている以上に重要な理由

多くの人は、コントラストの問題は全盲のユーザーやスクリーンリーダーを使うユーザーだけに影響すると考えがちです。現実はもっと広範です。世界には何らかの色覚異常を持つ人が約3億人おり、それ以外にも、日常的に低コントラストをストレスとして感じている人が大勢います — 安価なモニターを使っている人、高齢で視力が落ちている人、あるいは明るい屋外でスマートフォンをスクロールしている誰もがそうです。弱視は全盲よりはるかに一般的であり、視力をまったく失っている人のほぼ3倍の人が弱視に該当します。

WCAGのコントラスト閾値の背後にある研究は、これを具体的に示しています。標準的なテキストに対する4.5:1の最小比率は、おおよそ20/40に相当する視力を持つ人が一般的に経験するコントラスト感度の低下を補うように調整されています — これは、80代の人に一般的に報告される視力です。 WCAGのより厳しい7:1のLevel AAA閾値も同様に調整されています。これは20/80に相当する視力を持つユーザーを対象としており、支援技術を使わない弱視の人々のコントラスト感度の低下を補うことを目的としています。

また、法的・ビジネス上の影響も非常に現実的です。アメリカでは、2024年にADAに基づくデジタルアクセシビリティ訴訟が4,605件に達し、さらに欧州アクセシビリティ法が2025年6月に施行され、多くの商用ウェブサイトやアプリに義務的な遵守義務が拡大されました。色のコントラストの不備は検出可能で、文書化され、訴訟で日常的に指摘されています。コンプライアンス担当者にとって、それを修正することは「できればやりたいこと」ではなく、優先事項になります。

最後に、アクセシブルなコントラストは単に良いデザインでもあります。コントラストの高いテキストは誰にとっても読み飛ばしやすく、認知負荷を減らし、全体的な読書速度を向上させます — つまり、コンプライアンス義務であると同時に、ビジネスパフォーマンスの改善でもあるのです。

本当に知っておくべきWCAGのコントラストルール

WCAG 2は、コントラストを2つの色の知覚される輝度の差の尺度として定義しています。この式は、前景色と背景色の相対的な明るさを比較し、その結果を1:1（差がない — 白地に白）から21:1（最大の差 — 白地に黒）までの比率で表します。これを自分で計算する必要はありません。重要なのは、どの比率がいつ必要になるのかを理解することです。

WCAG 2.x Level AA — 多くの法律やアクセシビリティ標準で参照されているレベル — のもとでは、要件は次のように分解されます。

  • 通常のテキスト（本文、ラベル、18pt未満または14pt未満の太字のUIテキスト）: 背景に対して最小コントラスト比4.5:1。
  • 大きなテキスト（少なくとも18pt / 24px、または14pt / 約18.66pxの太字）: 最小コントラスト比3:1。文字が大きいほど識別しやすいという前提から、閾値が緩和されています。
  • 非テキストのUIコンポーネントおよび情報グラフィック（WCAG 2.1で導入された達成基準1.4.11）: 隣接する色に対して最小コントラスト比3:1。これは、フォーム入力のボーダー、フォーカスインジケーター、アイコンのみのボタン、データ理解に必要なチャートの一部などを対象とします。

Level AAAでは、基準はさらに高くなります。通常のテキストで7:1、大きなテキストで4.5:1です。Level AAAが全面的に義務付けられることはほとんどありませんが、テキスト量の多いページや、読み取り精度が重要なユーザーインターフェイスでは、デザインの目標として扱う価値があります。

重要なニュアンス: WCAGが定義する「大きなテキスト」は、CSSの値ではなく、ブラウザでレンダリングされたサイズに基づきます。フォントを1.2remに設定しても、ユーザーのブラウザのベースフォントサイズによっては大きなテキストに該当しない場合があります。迷ったときは4.5:1の閾値を適用し、ツールを使って実際のレンダリングサイズを確認してください。

いくつかの要素は、コントラスト要件から明示的に除外されています。純粋に装飾的な画像、無効化されたフォームコントロール、ロゴ、実際の写真は、達成基準1.4.3の対象ではありません。この例外は理にかなっています — 透かしの背景や商品写真が、ナビゲーションラベルと同じ閾値を満たすことを強制されるべきではありません — しかし、チームがこれを誤用し、安易なデザイン選択を正当化することがよくあります。ページの内容を理解するために画像やグラフィックが必要である場合は、3:1の非テキストコントラスト要件を満たす必要があります。

もう1つ注意すべき重要なルールが、WCAG 1.4.1（色の使用）です。リンクを周囲の本文テキストと区別するのに色だけを使っている場合 — 下線も太さの違いも、他の視覚的な手がかりもない場合 — そのリンクは、標準の4.5:1のテキストと背景の比率を満たすだけでなく、隣接する本文テキストに対して3:1のコントラスト比を達成しなければなりません。この3つの要件を同時に満たすのは本当に難しく、もっとも簡単な解決策はリンクの下線を残すことです。

コントラストの不備をテストする方法

コントラストのテストは、アクセシビリティ作業の中でもっともツールに適した部分の1つです。基礎となる計算は数学的かつ決定論的であり、多くの他のアクセシビリティ問題とは異なり、自動ツールで確実に検出できます。ただし、自動化が苦手とする境界的なケースもあり、テストの全体像を理解しておくことで、監査をはるかに徹底したものにできます。

ステップ1: 自動ページスキャンを実行する

WAVE（WebAIMのウェブアクセシビリティ評価ツール）とaxe DevToolsは、もっとも広く使われているブラウザベースのスキャナーです。どちらもChromeとFirefoxの拡張機能として利用できます。これらはレンダリングされたDOMをスキャンします — つまり、CSSやJavaScriptが適用された後、ブラウザが実際に描画した色を評価し、WCAG AAのコントラスト閾値に満たないテキスト要素にフラグを立てます。axe DevToolsはさらに進んで、各問題の重大度を報告し、関連するWCAGの達成基準に紐づけ、修正方法のガイダンスを提供します。エンタープライズチーム向けには、axe-coreをCI/CDパイプラインに直接統合し、デプロイ前にコントラストのリグレッションを検出できるようにすることもできます。

Google Lighthouseも、Chrome DevToolsに組み込まれており、アクセシビリティ監査の一部としてコントラストチェックを行います。これは便利な一次チェックであり — 特に、多くの開発者のワークフローにすでに組み込まれているため有用ですが — axe-coreルールのサブセットのみを実行するため、完全なaxe DevTools拡張機能ほど包括的ではありません。

重要な制限事項の1つとして、自動スキャナーは、グラデーション背景、背景画像、半透明レイヤー、複雑なCSSスタッキングを持つ要素上のテキストのコントラストを確実に評価することができません。これらのケースは手動での確認が必要です。

ステップ2: Chrome DevToolsのカラーピッカーでピンポイントに検査する

Chrome DevToolsで任意の要素のStylesペインを開き、色の値の横にあるカラースウォッチをクリックすると、要素の計算済み背景に対する現在のコントラスト比を表示する組み込みのカラーピッカーが起動します。色が基準を満たしていない場合、DevToolsは自動修正機能を提供し、AAおよびAAAを満たす最も近い色を提示して、クリック1つで準拠した値を採用できるようにします。これは開発中の迅速な反復に非常に有用です。DevToolsにはRenderingパネルに視覚障害エミュレーターも含まれており、ぼやけた視界、1型色覚異常（プロタノピア）、2型色覚異常（デューテラノピア）、全色盲（アクロマトプシア）などの状態をシミュレートして、色覚に障害のあるユーザーがあなたのパレットをどのように体験するかを定性的に把握できます。

ステップ3: 専用チェッカーで特定の色の組み合わせをテストする

まだ何も実装されていない段階で、たとえばFigmaでのデザインレビュー中に、個々の色の組み合わせを単体で検証する場合には、WebAIM Contrast Checker（webaim.org/resources/contrastchecker）が業界標準です。前景と背景のhex値を入力すると、コントラスト比と、通常サイズと大きなテキストの両方についてAAおよびAAAの合否判定を即座に返してくれます。WindowsとmacOS向けのデスクトップアプリケーションであるColour Contrast Analyser（CCA）も同様に有用で、半透明の前景や、ブラウザに限らず任意のアプリケーションから画面上の色をスポイトで取得するような複雑なケースにも対応します。

ステップ4: 文脈の中でテストする — ダークモード、ホバー状態、フォーカスインジケーター

多くのチームが見落とすのがここです。デフォルトのライトテーマでは合格している色の組み合わせが、ダークモードではまったく不合格になることがあります。白い背景では鮮やかに見えるブランドのアクセントカラーが、暗い背景では濁って見えたり、まぶしく感じられたりすることもよくあります。ホバー、フォーカス、アクティブ、訪問済みといったすべてのインタラクティブな状態は、新たなコントラスト不備の潜在的な原因です。同様に、キーボードユーザーがタブでコントロールに移動したときに表示されるフォーカスインジケーター（可視のアウトライン）は、WCAG 2.1の達成基準1.4.11のもとで、隣接する色に対して3:1のコントラストを達成しなければなりません。リリース前には必ず両方のテーマをテストしてください。見た目が洗練されているからといって、ダークモードが自動的にアクセシブルになるわけではありません。

もっともよくあるコントラストの不備 — その直し方

監査で頻出する不備のパターンを理解しておくと、修正作業の優先順位を付けやすくなります。コントラストの問題の多くは、予測可能なカテゴリのセットに分類されます。

白地にグレーの本文テキスト

#767676や#999999のような中間的なグレーを白い背景に載せるデザインは、モダンなフラットデザインで蔓延しています。キャリブレーションされたモニターを使うデザイナーには、軽やかで洗練されて見えますが、4.5:1の閾値を満たさないことが多く、弱視のユーザーには見えません。修正はたいてい、単純な色値の変更で済みます — かろうじて4.54:1で合格する#767676を#595959に変えると、7.0:1の比率が得られ、ほとんどの晴眼者には見た目の違いが最小限でありながら、可読性は大幅に向上します。

コントラスト調整により直感的な色モデルであるHSLで作業する場合、コントラスト比を変えるために必要なのはLightnessコンポーネントだけです。選んだ色相と彩度はそのままにできます。白い背景では、Lightnessの値を下げるとテキストが暗くなり、コントラストが向上します。暗い背景では、Lightnessを上げるとテキストが明るくなります。Lightnessを2〜5ポイント程度変えるだけで、不合格から明確なAA合格に移行できることが多く、デザインが知覚できるほど変わることはほとんどありません。

/* Before: WCAG AAに不合格（白地で比率約3.9:1） */
.body-text {
  color: #888888;
}

/* After: WCAG AAとAAAの両方に合格（白地で比率約7.0:1） */
.body-text {
  color: #595959;
}

フォームフィールドのプレースホルダーテキスト

ブラウザのデフォルトスタイルでレンダリングされるプレースホルダーテキスト — 通常は#AAAAAAや#BBBBBBといった薄いグレー — は、白い入力背景に対してほぼ例外なくWCAG AAに不合格です。多くのデザイナーは、ユーザーが入力した内容と視覚的に区別するために、意図的にプレースホルダーのコントラストを低く保ちますが、これは認められた例外ではありません。プレースホルダーテキストはユーザーインターフェイスのテキストであり、4.5:1の基準を満たさなければなりません。より濃い色を使い、明度ではなく、イタリック体、配置、アニメーションなどで視覚的な区別をつけてください。

::placeholder {
  /* 不合格: #AAAAAAは白地で約2.3:1 */
  color: #AAAAAA;
}

::placeholder {
  /* 合格: #767676は白地で約4.54:1 */
  color: #767676;
  font-style: italic; /* 代替の視覚的手がかり */
}

中間トーンのブランドカラー上の白または明るいテキスト

中程度の彩度のブランドカラー — HSLの明度5〜6の範囲にある一般的な青、緑、紫など — は、その上に載せた白いテキストに十分なコントラストを提供できないことがよくあります。ロゴでは映える鮮やかなブランドブルーでも、白に対して2.8:1程度の比率しか出ず、本文テキストに必要な4.5:1を大きく下回ることがあります。解決策は、背景色を暗くする（デザインシステムの800や900のトークンにブランドカラーをシフトする）、その背景の上では暗いテキストに切り替える、あるいはコントラストルールが適用されない純粋に装飾的な要素にのみ中間トーンの色を使う、のいずれかです。

背景画像やグラデーション上のテキスト

写真やグラデーションの上に直接テキストを載せるケースは、背景の輝度が一様ではないため、もっとも厄介なケースの1つです。画像の場所によってコントラスト比が変わるからです。もっとも確実な修正方法は、CSSで半透明の暗い（または明るい）オーバーレイを擬似要素として適用し、その下に画像が見えるようにすることです。黒のオーバーレイを50〜60%程度の不透明度でかけると、ギリギリのコントラストしかなかった白いテキストが、たいていAAAレベルのしっかりしたコントラストになります。

.hero {
  position: relative;
}

.hero::after {
  content: '';
  position: absolute;
  inset: 0;
  background: rgba(0, 0, 0, 0.55);
}

.hero__text {
  position: relative;
  z-index: 1;
  color: #ffffff;
}

無効状態やセカンダリのUI要素

WCAGは、無効化されたUIコンポーネントをコントラスト要件から明示的に除外しています — 非アクティブなボタンは4.5:1を満たす必要はありません。しかし、多くのチームがこの例外を、実際には無効ではないセカンダリテキスト、キャプション、補足テキスト、ラベルにまで過剰に適用しています。ユーザーが理解したり行動したりするために必要な情報を伝える要素であれば、その視覚的な階層に関係なく、該当するコントラスト基準を満たさなければなりません。デザインシステムのニュートラルスケールにあるすべての色を、それが使われる背景に対してチェックしてください。

コントラストをデザインシステムに組み込む

個々のコントラスト不備を後追いで修正するのは、時間がかかり、ミスも起こりやすい方法です。より持続的なアプローチは、コントラストの遵守をデザインシステムに組み込み、アクセシブルな色の組み合わせがデフォルトのアウトプットになるようにすることです — 後から考えるのではなく。

基盤となるのは、適切に段階付けされたトークンスケールです。パレット内の各色について、標準的な背景色に対するコントラスト比を事前に計算し、文書化しておくべきです。合理的な慣習として、トークンをコントラスト性能でラベリングする方法があります。たとえば--color-text-primaryトークンは、常に--color-surface-defaultに対してAAに合格しなければならず、その保証は文書化され、テストされ、強制されるべきです。デザイナーがテキストに色を付けるためにトークンを選ぶとき、そのトークンが最小基準を満たしていると信頼できるようにし、毎回手動でチェックする必要がない状態にします。

CSSカスタムプロパティを使うと、これが特に扱いやすくなります。パレット全体を変数として定義し、メディアクエリを使ってダークモード用にそれらを差し替えることで、特定の色の組み合わせをハードコードせずに済みます — コントラスト遵守の管理を1か所に集約できるのです。

:root {
  --color-surface-default: #ffffff;
  --color-text-primary: #1a1a1a;   /* 白地で約16:1 */
  --color-text-secondary: #595959; /* 白地で約7.0:1 */
  --color-text-subtle: #767676;    /* 白地で約4.54:1 */
  --color-accent: #0052cc;         /* 白地で約8.0:1 */
}

@media (prefers-color-scheme: dark) {
  :root {
    --color-surface-default: #121212;
    --color-text-primary: #ededed;   /* #121212に対して約14.5:1 */
    --color-text-secondary: #c0c0c0; /* #121212に対して約9.4:1 */
    --color-text-subtle: #909090;    /* #121212に対して約5.1:1 */
    --color-accent: #6fa8ff;         /* #121212に対して約6.5:1 */
  }
}

上記のダークモード用トークン値に注目してください。白い背景でAAに合格する色が、暗い背景では不合格になることも多く、その逆もまた然りです。ダークモードをデザインするときは、ライトモードの値を単純に反転させるのは避けてください。純粋な黒（#000000）に純白のテキストを載せるような完全な飽和状態は、ハレーションと呼ばれる視覚的なにじみを引き起こし、一部のユーザーにとっては読みづらくなります。#121212のサーフェスと#edededのテキストの組み合わせは、依然として優れたコントラストを保ちながら、より快適なペアリングです。

自動コントラストテストをコンポーネントパイプラインに統合することもできます。axe-coreのようなライブラリは、JestやPlaywrightのテスト内で呼び出すことができ、標準のテストスイートの一部としてコントラストの不備にフラグを立てます。これにより、外部監査の段階ではなく、不備が導入された瞬間にリグレッションを検出できます。

自動ツールでは検出できないもの — その対処法

自動スキャンは強力な出発点ですが、限界もあります。アクセシビリティ基準全体を考慮すると、自動テストが検出できる潜在的なWCAG違反は、通常20〜30パーセント程度にとどまります — ただし、色のコントラストは比較的検出しやすいカテゴリの1つです。それでもなお、自動ツールをすり抜けるコントラスト不備のシナリオがいくつかあります。

グラデーションや背景画像上のテキストは、もっとも一般的な盲点です。axeやWAVEは、前景と背景の両方に単一の決定論的な色値がある場合に、色の組み合わせを特定できます。背景がCSSグラデーションやJPEG写真の場合、ツールは意味のある比率を計算できないことが多く、その項目を明確な不合格ではなく「要レビュー」としてマークします。これらのケースは人間による確認が必要であり、理想的にはColour Contrast Analyserのようなピクセルレベルのスポイトツールを使って、重なり合う領域の複数箇所で実際の前景色と背景色をサンプリングします。

半透明や合成された色も同様の課題を生みます。青いボタンの上の白いラベルが、緑のページ背景の上にレンダリングされている場合、計算されるコントラストは3つの色レイヤーすべてに依存します — DOMベースのツールでは、この計算を正確に行えないことがあります。アルファ値を手動でフラット化するか、画面キャプチャベースのツールを使ってレンダリングされたピクセルの色をサンプリングしてください。

動的に生成される状態 — JavaScriptで制御されるツールチップ、モーダルダイアログ、ドロップダウンメニュー、エラーメッセージなど — は、その場でレンダリングされるため、自動スキャンの実行時に表示されていないことがあります。スクリプト可能なツール（Playwrightテスト内のaxe-coreなど）は、これらの状態に遷移して評価できますが、そのカバレッジを構成するには意図的な取り組みが必要です。QAワークフローに組み込み、新しい色の組み合わせを導入するすべての新規コンポーネントについて、コントラストを「完了の定義」に含めてください。

最後に、WCAGの数学的なコントラスト式は確立されたものではありますが、知覚される読みやすさを完全に代替するものではありません。この式は、フォントの太さ、文字間隔、アンチエイリアスを考慮していません。4.5:1の比率でも、細いウェイトの書体は、同じ比率の太いウェイトより読みづらく感じられます。WCAGの閾値は「床」 — 達成しなければならない最低ライン — として扱い、最適化の目標として扱わないでください。可能な限り7:1を目指し、実際に弱視の人たちとユーザーテストを行って、現実の世界であなたの色選択が機能しているかを検証してください。

重要なポイントのまとめ

  • 色のコントラストは、ウェブにおけるアクセシビリティ不備の第1位です。 コントラストの低いテキストは、2026年時点で上位100万件のホームページの83.9%に見られました。組織のアクセシビリティプログラムがどれだけ成熟していても、コントラストは今まさに不備が残っている可能性がもっとも高い領域であり、かつもっとも修正しやすい領域の1つです。
  • 自分たちのコンテンツに適用される閾値を把握する。 WCAG AAでは、通常のテキストに4.5:1、大きなテキスト（18pt以上または14pt以上の太字）に3:1、入力ボーダーやアイコンのみのコントロールなどの非テキストUIコンポーネントに3:1が求められます。これらは、インターフェイスがライトモードかダークモードかに関係なく適用されます。
  • レイヤーごとにテストする: 自動スキャン、DevToolsでの検査、スタンドアロンチェッカー、手動レビュー。 axe DevToolsやWAVEで高速な全ページスキャンを行い、Chrome DevToolsの組み込みカラーピッカーで迅速に反復し、WebAIM Contrast CheckerやCCAで特定の組み合わせを検証し、自動ツールでは確実に評価できないグラデーション、画像、動的状態を手動で確認してください。
  • コントラストはコンポーネントレベルではなくデザインシステムレベルで修正する。 事前にコントラスト比を検証したトークンスケールを構築し、どのテキストトークンがどのサーフェストークン上で合格するかを文書化し、CIの自動テストで遵守を強制してください。これにより、本番環境に到達する前に、特定の種類の不備を丸ごと排除できます。
  • WCAGを目標ではなく最低ラインとして扱う。 4.54:1を達成しても、かろうじて合格したに過ぎず、多くのユーザーが依然として苦労します。タイポグラフィ、可読性、ブランドが許す範囲で7:1を目指し、フォントの太さ、サイズ、字間なども活用して、単に技術的に準拠しているだけでなく、本当に読みやすいテキストを実現してください。