WCAG 向けのカラーコントラストをチェックする方法

WCAG 向けにカラーコントラストをチェックするには、前景となるテキストとその背景の相対輝度を比較し、算出された比率がその要素タイプのしきい値を満たしているかを確認します。レベル AA では、通常テキストが 4.5:1、大きなテキストが 3:1、テキスト以外の UI が 3:1 です。

多くの人はこれを痛い目を見ながら学びます。自分の画面では問題なく見えた薄いグレーのラベルを出荷し、2 スプリント後の監査で不合格になる、といった具合です。これを手計算する必要はありません。チェッカーなら 2 つの hex 値から数秒で判定してくれます。本ガイドでは、正確なしきい値、比率を測る最速の方法、多くのチームがつまずく失敗例、そして本文テキストを超えて UI コンポーネント、フォーカスインジケーター、色による意味づけにまで及ぶルールを解説します。

WCAG が要求するコントラスト比とは?

コントラスト比は、2 色間の輝度差を測るものです。下限は 1:1(前景と背景が同じ色の場合)、上限は 21:1(白に対する黒)です。WCAG では (L1 + 0.05) / (L2 + 0.05) として算出します。ここで L1 と L2 は、明るい色と暗い色それぞれの相対輝度です。以下は、あらゆるチェッカーが適用するしきい値です。

レベル AA では通常テキストが 4.5:1、大きなテキストが 3:1 となり、レベル AAA では同じ組み合わせが 7:1 と 4.5:1 に引き上げられます。何を「大きい」とみなすかはサイズとウェイトの問題です。18pt(約 24px)以上、または太字であれば 14pt(約 18.66px)以上が該当します。WebAIM Contrast Checker は、まさにこれらのしきい値に対して結果を報告します。判断の目安はほとんどのケースでこれ 1 つで足ります。テキストは大きいか? → 3:1、そうでなければ → 4.5:1。

打ち消しておくべき誤解があります。2023 年 10 月に公開された WCAG 2.2 はフォーカスの見え方に関するガイダンスを追加しましたが、コントラストの最低要件には手を加えていません。以降のバージョンは既存の達成基準を書き換えるのではなく、達成基準を追加するのみで(4.1.1 Parsing が唯一の例外)、4.5:1 / 3:1 / 7:1 は 2.0、2.1、2.2 を通じて一貫しています。低コントラストは依然としてウェブで最も多いアクセシビリティ上の欠陥です。2026 年の WebAIM Million レポートでは、上位 100 万件のホームページのうち 83.9% で低コントラストのテキストが見つかりました。

カラーコントラストはどうやってチェックするのか?

最速のワークフローは、レンダリングされた 2 つの hex 値を取得し、チェッカーに貼り付け、合否を読む、というものです。デザインファイル内の値ではなく、レンダリングされた色を取得してください。オーバーレイ、グラデーション、透明度によって、ユーザーが実際に目にするものは変わります。

• WebAIM Contrast Checker:前景と背景の hex を貼り付けます。比率に加えて 5 つの判定が得られます。通常テキストと大きなテキストがそれぞれ AA と AAA で判定され、テキスト以外の要素には独自の AA 行が用意されているためです。基準に届かない場合は、WebAIM によるツールの解説にあるとおり、Lightness スライダーでどちらかの色を微調整して合格させられます。
• TPGi Colour Contrast Analyser:Windows と macOS 向けのデスクトップアプリです。スポイトで画面から直接どちらの色も取得でき、hex、RGB、HSV、HSL で値を入力し、前景にアルファ値を設定し、不合格の組み合わせが合格するまでスライダーをドラッグできます。8 種類の色覚特性設定を通したプレビューも可能です。
• Chrome DevTools:要素を検証し、color 宣言の横にあるスウォッチから Color Picker を開き、Contrast ratio セクションを展開します。その組み合わせが AA と AAA をクリアしているかを報告し、合格する値を適用する Use suggested color ボタンを提供し、シェードプレビュー内に AA と AAA の境界線を描画するので、手動でピッカーをその下までドラッグできます。
• Firefox:DevTools を開き → アクセシビリティパネル → ノードを選択 → コントラストと合否を確認します。

ページ全体の監査には、WAVE、axe DevTools、または Lighthouse を実行してください。WAVE はスタイル内のテキスト色と背景色を読み取り、AA の 4.5:1 ラインを下回る本文テキストの大半を検出し、大きなテキストには低い方の 3:1 のしきい値を適用します。判定できないのは、画像上のテキスト、アルファ合成、ホバーやフォーカスの状態です。したがって重要なコンポーネントは手動で検証してください。

よくあるコントラストの失敗とその修正方法

失敗のほとんどは、繰り返し現れる少数の常習犯であり、素早く検証可能な修正が可能です。

白背景上の薄いグレーのテキスト。 白背景の #767676 は、4.5:1 で AA をクリアできる最も明るいグレーですが、#999 は 2.85:1 にしか届かず不合格です。本文テキストを #595959 まで暗くしましょう。これはちょうど 7:1 に相当し、AA と AAA の両方をクリアします。

/* FAIL: ~2.85:1 */  color: #999999; background: #fff;
/* PASS: 7:1 */      color: #595959; background: #fff;

プレースホルダーテキスト。 プレースホルダーを 40〜50% の不透明度に設定することが 1.4.3 の不合格の典型的な原因です。背景が透けてしまい、比率が 4.5:1 を下回るためです。代わりに #767676 以上に暗い実際の hex 値を指定してください。また、ユーザーが必ず読む必要がある内容には、常時表示される <label> を使いましょう。プレースホルダーは入力すると消えてしまうためです。

色だけで示すリンク。 text-decoration: underline を追加し、リンクが色相だけで区別されないようにします。下線を取り除くと、追加の要件を背負うことになります。その場合、リンクテキストは背景に対して両色が満たすべき 4.5:1 に加えて、周囲の本文テキストに対して 3:1 が必要になります。

画像上のテキスト。 写真では輝度が場所によって変わるため、同じテキストがある領域では合格し、別の領域では不合格になります。半透明のスクリムを追加しましょう。

.hero {
  background:
    linear-gradient(rgba(0,0,0,.6), rgba(0,0,0,.6)),
    url("hero.jpg");
}
.hero-text { color: #fff; } /* now has guaranteed contrast */

テキストの先へ:UI コンポーネント、フォーカス、色の使用

コントラストのルールは段落テキストにとどまりません。達成基準 1.4.11 は、コントロール、および読者がコンテンツを理解するために必要なグラフィックの部分について、隣接するどの色に対しても 3:1 を下限として定めています。入力欄のボーダー、ボタンのアウトライン、意味を持つアイコン、チャートの系列がいずれも該当します。状態も対象ですが、注意点があります。デフォルト状態は 3:1 が必要で、いずれの状態もコンポーネントをそれ未満に落としてはいけません。ただし、その上に追加するホバー効果自体は、コントロールが既に持っているコントラストを打ち消さない限り、3:1 の対象にはなりません。

フォーカスインジケーターは仕様の番号が混同されやすい領域なので、正確に対応づけましょう。フォーカスの可視性は 2.4.7 Focus Visible です。インジケーターの 3:1 のコントラストは 1.4.11 Non-text Contrast に由来するものであり、2.4.11 ではありません。2.4.11 は Focus Not Obscured (Minimum) であり、オーバーレイがフォーカスされた要素を隠すことに関する基準です。AAA レベルの 2.4.13 Focus Appearance は、これに加えて最小サイズと状態変化時のコントラストを要求します。

最後に、WCAG 1.4.1 Use of Color(レベル A) は、色だけで意味を伝えてはならないことを意味します。赤/緑のステータスにはテキストラベルやアイコンを併用し、リンクには下線を付けましょう。覚えておくべき除外規定が 1 つあります。非アクティブ(無効化された)コンポーネントは、テキスト以外およびコントラストの最低要件から除外されます。とはいえ、見えなくなるほどグレーアウトするより、読める状態を保つ方が UX としては優れています。

コントラストをワークフローに組み込む

出荷前にコントラストを捕まえましょう。デザイン段階では Figma 内の Stark のようなプラグインでチェックし、その結果を各色の比率を注記したトークン層に落とし込みます。

:root {
  --text-primary:   #171717; /* 18.8:1 — headings, body */
  --text-secondary: #595959; /* 7:1  — secondary text */
  --border-input:   #767676; /* 4.5:1 — meets 1.4.11 */
  --border-subtle:  #d4d4d4; /* 1.6:1 — decorative only */
}

本文テキストは最低要件を十分に上回るべきで(10:1 以上が快適です)、二次テキストや大きなテキストは 4.5:1、ボーダーは 3:1 で維持できます。Chrome DevTools → Rendering → Emulate vision deficiencies で色覚特性をテストし、色がなくても意味が伝わることを確認しましょう。そして自動化します。CI で axe や Lighthouse を実行し、コントラストのリグレッションがユーザーに届く前にビルドを失敗させるのです。さらに、ダークモードには専用のチェックを行ってください。輝度を反転させると、ライトモードで合格していた比率が崩れるため、テーマごとにすべてのトークンを再計算する必要があります。

コントラストは、修正コストが最も安く、予防も最も容易なアクセシビリティ問題の 1 つです。チェッカーを選び、しきい値をトークンとして設定し、自動スキャンを CI に組み込めば、上記のような不具合は出荷されなくなります。まずは今日、現在の本文テキストとフォーカススタイルを 4.5:1 と 3:1 のラインに照らして監査することから始めましょう。

FAQ

WCAG のコントラストは色相や彩度を測るのですか、それとも明度だけですか?

コントラスト比が測るのは相対輝度、つまり各色の知覚上の明るさのみであり、色相や彩度ではありません。だからこそ、緑の背景に赤いテキストのように見た目が異なる 2 色でも、輝度が近ければ不合格になり得るのです。比率は明るい方と暗い方の輝度値から (L1 + 0.05) / (L2 + 0.05) として算出されます。したがって、色相だけで伝えられる意味については、WCAG 1.4.1 Use of Color が別途規定しています。

WCAG 1.4.11 Non-text Contrast と 2.4.11 Focus Not Obscured の違いは何ですか?

WCAG 1.4.11 Non-text Contrast(レベル AA)は、UI コンポーネントおよび意味を持つグラフィック(フォーカスインジケーターを含む)に対して、隣接する色との間で 3:1 のコントラスト比を求めるものです。WCAG 2.2 で新設された WCAG 2.4.11 Focus Not Obscured(Minimum、レベル AA)はコントラストとは無関係で、フォーカスされた要素がスティッキーヘッダーやオーバーレイなど制作者が作成したコンテンツによって完全に隠されないことを求めます。コントラストは 1.4.11、遮蔽からの可視性は 2.4.11 です。

同じテキストがデザインファイルではコントラストに合格するのに、ブラウザでは不合格になるのはなぜですか?

デザインファイルのプラグインは指定したフラットな色値をチェックしますが、ブラウザはレンダリング結果を合成します。不透明度、半透明のオーバーレイ、グラデーション、背景画像、ブレンドモードはいずれも、ユーザーが実際に目にする輝度を変化させます。不透明度 50 パーセントに設定されたプレースホルダーや写真上のテキストは、モックアップでは合格してもレンダリング後には不合格になり得ます。ソースの色を信用せず、常に DevTools や画面上のスポイトツールでレンダリングされた hex を取得してください。

無効化されたボタンや非アクティブなコントロールも WCAG のコントラスト最低要件を満たす必要がありますか?

いいえ。WCAG 1.4.3 Contrast(Minimum)は非アクティブなユーザーインターフェースコンポーネントを明示的に除外しており、無効化された要素は 1.4.11 のテキスト以外のコントラスト要件からも除外されます。つまり、グレーアウトした無効化ボタンが自動コントラスト監査で不合格になることはありません。完全に見えないコントロールはユーザーを混乱させるため、無効化されたコントロールを判読可能に保つことは依然としてユーザビリティ上望ましいものの、その状態に関して WCAG の適合要件ではありません。