コントラストチェッカー

WCAG の AA と AAA 適合に向けた色のコントラスト比をチェック。Web サイトのテキストを読みやすくアクセシブルに。無料のオンラインツール。

主な機能

リアルタイムのコントラスト比計算
WCAG 2.1 の AA と AAA 適合チェック
通常文字と大きな文字の基準に対応
色の入れ替えとライブプレビュー

Guide

色のコントラストのアクセシビリティは、視覚障害のある人を含むすべての人がウェブサイトのテキストを読めるかどうかを決定します。Web Content Accessibility Guidelines（WCAG）は、テキストがアクセシブルと見なされるために満たさなければならない特定のコントラスト比を定義しています。これらの基準を満たさないことは、一部の訪問者がコンテンツを読めないことを意味し、多くの管轄区域では、サイトが法的なアクセシビリティ要件を満たさないことを意味します。本ガイドでは、コントラスト比の仕組み、WCAG の要件、デザインを損なうことなくコントラストの問題を修正する方法を説明します。コントラスト比は、1:1（コントラストなし、両方の色が同一）から21:1（最大コントラスト、純白の上の純黒）のスケールで2つの色の相対輝度を比較します。相対輝度は、色が人の目にどれくらい明るく見えるかの尺度で、人の視覚が異なる波長をどう知覚するかを考慮した計算式を使って色の RGB 値から計算されます。赤、緑、青は知覚される明るさに異なる寄与をし、緑が最も多く寄与し青が最も少なくなります。計算式は：L = 0.2126 * R + 0.7152 * G + 0.0722 * B で、R、G、B は sRGB 値から線形化されます。線形化のステップは、伝達関数を適用してガンマエンコードされた sRGB 値を線形光の値に変換します。コントラスト比自体は（L1 + 0.05）÷（L2 + 0.05）として計算され、L1 はより明るい色の相対輝度、L2 はより暗い色の相対輝度です。0.05 という値は環境光を考慮します。この計算式はおなじみの比の形式を生みます。例えば、純白は輝度1.0、純黒は輝度0.0を持ち、コントラスト比は（1.0 + 0.05）÷（0.0 + 0.05）= 21:1 になります。 WCAG はコントラストについて2つの適合レベルを定義します。レベル AA はほとんどのウェブサイトのベースライン要件です。レベル AAA はより良い可読性を提供するより厳しい基準です。通常サイズのテキスト（18pt未満または14ptボールド未満）について、レベル AA は少なくとも4.5:1のコントラスト比を要求し、レベル AAA は7:1を要求します。大きなテキスト（18pt以上、または14ptボールド以上）について、レベル AA は3:1を要求し、レベル AAA は4.5:1を要求します。これらの閾値は、中程度の低視力（おおむね20/40の視力で、高齢者の典型的な視力低下の閾値）の人の可読性の研究に基づいています。大きなテキストの例外が存在するのは、大きな文字が本質的に読みやすいからです。より大きなサイズでは、太いストロークと広いカウンターが、より低いコントラストでも文字をより区別しやすくします。これが、見出し、ヒーローテキスト、その他の大きなディスプレイテキストが AA 適合の下で3:1の比を使え、本文が4.5:1を必要とする理由です。CSS の用語では、18pt はブラウザの既定設定で24pxに等しく、14pt ボールドはおおむね18.66px ボールドに等しいです。テキストが大きなテキストに該当するか不確かな場合は、安全のためににより厳しい4.5:1の比を適用しましょう。非テキスト要素にも WCAG 2.1 達成基準 1.4.11（非テキストのコントラスト）の下でコントラスト要件があります。コンテンツの理解に必要なユーザーインターフェースコンポーネント（ボタン、フォーム入力、フォーカスインジケーター）とグラフィックオブジェクト（アイコン、チャート要素）は、隣接する色に対して少なくとも3:1のコントラスト比を持たなければなりません。白色の背景上で3:1を下回る薄い灰色のボタン境界は、特に低視力のユーザーにとって、ボタンがクリック可能な要素として識別しにくくします。フォーカスインジケーターは特に重要です：キーボードユーザーはナビゲーションのために視覚的なフォーカススタイルに依存し、それらのフォーカススタイルは周囲のコンテンツに対して3:1の比を満たさなければなりません。色覚特性は北ヨーロッパ系の男性の約8% と女性の0.5% に影響し、他の集団では異なる有病率です。最も一般的な形態は赤緑色覚特性（deut-眼と protanopia）で、赤と緑が似て見えます。青黄色覚特性（tritanopia）はよりまれです。完全な色覚特性（achromatopsia）は稀です。輝度に基づくコントラスト比の計算は、色の知覚とは独立して機能します。明るさの差を測り、色相の差は測らないからです。ただし、色だけで情報を伝える（エラーは赤、成功は緑）と、コントラスト比に関わらず色覚特性のユーザーに問題を作ります。色分けとともに、アイコン、テキストラベル、パターンのような追加の視覚的手がかりを常に提供しましょう。ダークモードはさらなるコントラストの考慮事項を導入します。多くのデザイナーは単に色を反転してダークテーマを作りますが、これはしばしば貧弱な結果を生みます。純黒（#000000）の背景上の純白（#FFFFFF）のテキストは最大コントラスト（21:1）を作りますが、このレベルのコントラストは一部のユーザーに視覚疲労とハレーション（暗い背景上の明るいテキストの周りの発光効果）を引き起こす可能性があります。#121212 の上の #E0E0E0 のようなやや減らしたコントラストは、WCAG AAA 要件を依然として超えながらより快適です。Google の Material Design ダークテーマのガイドラインは、表面色として #121212 を使い、純白ではなくテキストの不透明度を下げることを推奨しています。プライマリテキストは87% の不透明度を使い、セカンダリテキストは60%、無効化されたテキストは38% を使います。半透明の色はコントラストチェックを複雑にします。アルファ値が1未満の rgba() または hsla() 色を使うとき、実際にレンダリングされる色はその背後にあるものに依存します。70% の不透明度の白いテキストは、暗い背景と明るい背景とで異なる実効コントラストを持ちます。半透明のテキストのコントラストをチェックするとき、合成された色（透明が背景に対して適用された後にユーザーが実際に見る色）を計算する必要があります。計算式は、アルファ値に基づいて前景と背景をブレンドします：合成 = 前景 * アルファ + 背景 *（1 - アルファ）、各チャンネルに適用。分離した透明色ではなく、常に合成された結果をチェックしましょう。グラデーション背景はテキスト領域全体にわたり可変のコントラストを作ります。テキストが濃い青から薄い青に移行するグラデーションの上にある場合、コントラスト比はテキストの左右の端で異なります。WCAG はテキストが現れるすべての点でコントラスト比が満たされることを要求します。最も弱い点でコントラストをチェックしましょう。それは背景がテキストの色に最も近い輝度の点です。グラデーションが #003366 から #6699CC に及びテキストが白なら、#6699CC に対してコントラストをチェックします。それが最も低くなるからです。放射状グラデーションについては、テキスト領域全体で複数の点をチェックしましょう。画像背景は最も難しいコントラストの課題を提示します。写真やパターンのある背景上のテキストは、すべてのピクセルで異なるコントラストを持ちます。解決策は：画像とテキストの間に固定または半透明のオーバーレイを置く、可読性を保証するためにテキストシャドウやアウトラインを使う、またはテキストを一貫した色の画像の領域に制限することです。一般的なパターンは、テキストが現れるヒーロー画像の下部に暗いグラデーションオーバーレイです。グラデーションは画像を十分に暗くし、白いテキストとの十分なコントラストを作ります。オーバーレイについては、rgba(0, 0, 0, 0.5) が典型的に白いテキストでほとんどの画像を WCAG AA 適合にしますが、具体的な画像で検証しましょう。色空間とコントラストの計算は、ほとんどのツールが認めるより複雑です。標準の WCAG コントラスト計算式は、sRGB 色空間の相対輝度を使います。この計算式には既知の限界があります。非常に暗い色のペアのコントラストを過大評価し、明るい色のペアのコントラストを過小評価することがあります。研究は、黒い背景上の暗い青のテキスト（#00007E）が技術的には WCAG AA に合格するが、実際には極めて読みにくいことを示しています。APCA（Advanced Perceptual Contrast Algorithm）は、ポーラリティ効果（明るい背景上の暗いテキストは暗い背景上の明るいテキストとは異なる知覚される）を含め、人の視覚知覚をより正確に考慮した WCAG 3.0 向けに開発されたより新しいアプローチです。WCAG 2.x とその sRGB ベースの計算式が現在の法的基準のままである一方、APCA はより知覚的に正確な評価を提供します。 APCA モデルは、フォントサイズとウェイトに基づいて異なるコントラスト要件を割り当て、WCAG 2.x の二値閾値アプローチではなく最小コントラスト値のマトリックスを作ります。例えば、14px の通常ウェイトのテキストは24px のボールドテキストより高い APCA コントラスト値を必要とします。APCA はポーラリティの問題も処理します：暗い背景上の明るいテキストは、明るい背景上の暗いテキストと異なるコントラスト値を必要とします。APCA はまだ公式基準ではありませんが、特に WCAG 2.x が疑わしい結果を生むエッジケースで、より良いコントラストの決定をする助けになります。コントラストの失敗の修正は典型的に3つのアプローチのいずれかを含みます：テキストを暗くする、背景を明るくする、またはその両方です。色を調整するとき、色相や彩度を変えるのではなく HSL 色空間で明度の値を変更することでブランドパレット内に留まりましょう。ブランドの青が hsl(210, 80%, 55%) で白に対してコントラストに失敗するなら、明度を hsl(210, 80%, 40%) に下げると、依然としてブランドの青と認識可能なままで AA に4.6:1で合格するかもしれません。小さな明度の調整が、完全な再設計なしでコントラストの問題を解決することがよくあります。OKLCH 色空間では、これらの調整はさらに知覚的に均一な結果を生みます。 CSS カスタムプロパティはコントラスト対応のテーミングを現実的にします。HSL 値として色をカスタムプロパティに定義し、コントラスト要件を満たす明るいテーマと暗いテーマのバリアントを作ります。例えば：ライトテーマには --brand-primary: hsl(210, 80%, 40%)、ダークテーマには --brand-primary: hsl(210, 80%, 70%) です。両方とも同じ色相と彩度を使いますが、それぞれの背景のために最適化された異なる明度の値です。このアプローチは数十のカラートークンを持つデザインシステム全体に拡張します。すべてのテーマでアクセシビリティ要件を満たしながらブランドの一貫性を維持します。デザインシステムの統合は、コントラストチェックが最も価値を持つところです。個々のページ要素をチェックするのではなく、カラートークンを定義し、トークンシステム内のすべての背景上のテキストの組合せが WCAG 要件に合格することを検証します。承認された組合せを、どのテキスト色がどの背景色で安全かを示すコントラストマトリックスに文書化します。そして開発者がコンポーネントを構築するとき、事前承認された色のペアから選択し、コントラストの遵守がインスタンスごとにチェックされるのではなくシステムによって保証されます。これが Google、Microsoft、Adobe のような大規模組織がスケールでコントラストを処理する方法です。コントラストマトリックスの構築は、すべての背景色を上部に、すべてのテキスト色を側面にリストし、各交差点のコントラスト比を計算することを含みます。各セルを AA 合格、AAA 合格、または不合格としてマークします。このマトリックスはチーム全体の参照文書になります。デザイナーが色の組合せを指定するとき、マトリックスを即座にチェックできます。開発者がコンポーネントを実装するとき、マトリックスはどのカラートークンが一緒に安全かを伝えます。自動テストはコントラストの問題を早期に発見します。axe-core、Lighthouse、Pa11y のようなツールはレンダリングされたページを走査し、WCAG コントラスト要件に失敗する要素にフラグを立てます。これらを CI/CD パイプラインに統合し、コントラストの回帰をデプロイ前に発見しましょう。自動ツールの限界は、画像、グラデーション、動的に変化する背景上のテキストを評価できないことです。これらのケースではコントラストチェッカーツールによる手動チェックが依然として必要です。包括的なアプローチは大多数のケースに自動テストを使い、自動化が扱えないエッジケースに手動チェックを使います。法的遵守がコントラストのアクセシビリティを巡る緊急性の多くを推進します。米国の Americans with Disabilities Act（ADA）、EU の欧州アクセシビリティ法、カナダの Accessibility for Ontarians with Disabilities Act、その他の管轄区域の類似の法律は、直接的に WCAG 適合を要求するか、裁判所によって WCAG 適合を要求するものと解釈されています。ウェブアクセシビリティに関する訴訟は年々有意に増加し、コントラストの失敗が最もよく引用される問題の一つです。WCAG AA の達成が広く受け入れられた法的基準です。規制産業（政府、医療、教育、金融）の組織はより厳しい要件とより活発な執行に直面します。法的遵守を超えて、良いコントラストは良いデザインです。読みやすいテキストはコンバージョンを高め、訪問者を長く留め、直帰率を下げます。明るい日差しの下でスマートフォンを読むユーザー、自然に視力が低下する高齢のユーザー、色再現の劣る低品質モニターのユーザー、単に疲れているユーザーのすべてが強いコントラストの恩恵を受けます。人の能力の限界（低視力、困難な環境）のために設計することは、中心にいるすべての人にもよりよく機能するデザインを生みます。研究は、より高いコントラストのテキストが視覚障害のある人だけでなく、すべてのユーザーにわたり読書時間を減らし理解を向上させることを示しています。実際の条件でコントラストの選択をテストするとは、複数のデバイスで、様々な照明条件で、プレースホルダーテキストではなく実際のコンテンツでチェックすることを意味します。数学的なコントラストチェックに合格する色のペアでも、フォントが細く、テキストが小さく、レタースペーシングがタイトなら読みにくいかもしれません。コントラスト比は必要な最小値であり、可読性の保証ではありません。最良の結果のために、十分なコントラストを適切なフォントサイズ（本文は最小16px）、ウェイト（ライトやシンではなくレギュラーやミディアム）、スペーシング（1.5以上の行の高さ）と組み合わせましょう。一般的なコントラストの落とし穴には、フォーム入力のプレースホルダーテキスト（しばしば白の上の薄い灰色で、コントラスト要件に失敗）、無効化されたボタンのテキスト（完全なコントラスト要件を満たさなくても区別可能である必要）、周囲のテキストとの区別を色のみに依存するリンクテキスト（WCAG はリンクと周囲のテキストのコントラストが少なくとも3:1でない限り、下線のような追加の視覚的インジケーターを要求）、コントラストが位置によって変わる装飾的な背景上のテキストがあります。ブランドカラーのアクセシビリティは頻繁な課題です。マーケティングチームは WCAG 適合のためではなく、感情的インパクトと視覚的魅力のためにブランドカラーを選びます。明るいオレンジのブランドカラー（hsl(30, 100%, 50%)）は白に対してわずか2.14:1のコントラスト比を持ち、通常テキストの AA 4.5:1の要件をはるかに下回ります。解決策はブランドカラーのアクセシブルなバリアントを作ることです。色相を保ち、明度を調整します。hsl(30, 100%, 35%) は依然としてオレンジと認識可能ですが、4.6:1で白に対して AA に合格します。大きなテキストと装飾要素用のプライマリカラー（低いコントラストが許容される）と、本文、リンク、UI コンポーネント用の調整されたバリアント（AA に合格しなければならない）を持つブランドカラーパレットを作りましょう。データの可視化とチャートは独特のコントラストの課題を提示します。チャート内の各データシリーズは、隣接するシリーズと背景から区別可能である必要があります。5つ以上のデータシリーズでは、すべてが互いにそして背景と十分にコントラストする色を見つけるのは困難です。色覚特性セーフパレット（ColorBrewer や Okabe-Ito パレットからのものなど）はこの目的のために特別に設計されています。色を超えて、データシリーズを区別するためにパターン、テクスチャ、または直接ラベルを使いましょう。折れ線グラフは異なるダッシュパターンを使えます。棒グラフは斜線ハッチングを使えます。散布図は異なる形状を使えます。異なる照明環境でのコントラストは劇的に異なります。薄暗いオフィスで快適に読める色のペアが、直射日光下ではほとんど見えなくなります。モバイルユーザーは明るい屋外の条件に頻繁に遭遇します。高いコントラスト比は環境要因に対する緩衝材を提供します。ちょうど4.5:1（AA の最小値）のペアは管理された条件では読めますが、明るい日光下では失敗するかもしれません。5:1や6:1を目標にすれば、現実の視聴条件を考慮した余裕が得られます。重要な UI 要素（ナビゲーション、コールトゥアクション、エラーメッセージ）については、より高いコントラストの側に振りましょう。カラーマネージメントとデバイスの違いはユーザーがコントラストをどう知覚するかに影響します。広色域ディスプレイ（P3 や Adobe RGB）上の sRGB 色は、意図したものとわずかに異なって見えることがあります。安価な TN パネルモニターは IPS や OLED 画面とは異なる色を表示します。画面の明るさの設定が知覚されるコントラストを変えます。ブルーライトフィルターと夜間モードはディスプレイを暖色に着色し、寒色の知覚されるコントラストを下げます。これらの要因は計算された WCAG 比を変えませんが、実際の視覚体験に影響します。複数のデバイスと複数の条件でテストすれば、数学的な計算が見逃す問題を発見できます。画像に埋め込まれたテキストのコントラスト要件は、生きたテキストと同じです。ヒーロー画像に（HTML テキストではなく）画像ファイルに焼き付けられたテキストが含まれる場合、そのテキストは依然として WCAG コントラスト要件を満たす必要があります。違いは、画像テキストを CSS で調整できないため、エクスポート前に画像編集ツールでコントラストを検証しなければならないことです。ソーシャルメディアのプレビュー画像（og:image）には読めるべきテキストがしばしば含まれますが、これらは第三者のプラットフォームに現れるため WCAG では正式にはカバーされません。タイポグラフィのコントラストは、前景色と背景色だけにとどまりません。テキストの知覚されるコントラストはフォントウェイト、フォントサイズ、レタースペーシング、行の高さに依存します。細いフォント（300ウェイト以下）はストロークが細く背景から区別しにくいため、同じテキストをレギュラーやボールドウェイトにするより高いコントラスト比を必要とします。WCAG の仕様は閾値にウェイトを考慮せず（サイズのみ）、技術的に合格する比でもフォントが細すぎると読めないテキストを生むことがあります。本文には、少なくともレギュラー（400）やミディアム（500）ウェイトを使いましょう。ライトとシンのウェイトは、サイズがストロークの視認性の低下を補う大きな見出しのためにとっておきましょう。大規模なウェブサイト全体の体系的なコントラスト監査は、自動ツールと手動レビューの組み合わせを必要とします。自動スキャン（axe-core、Lighthouse）を実行して、比に失敗するハードコードされた色のような容易に取れる成果を発見します。次に、動的コンテンツ、ユーザー生成コンテンツ領域、インタラクティブな状態（ホバー、フォーカス、アクティブ、無効）、エラーと成功のメッセージ、ツールチップのテキスト、色が実行時に決定されるあらゆる領域を手動でレビューします。定期的な監査スケジュールを作りましょう：大規模サイトは四半期ごと、アクティブな開発中は月次です。時間の経過に伴うコントラストの問題の数を追跡し、進捗を測りましょう。コントラストチェッカーツールを使えば、任意の2色を入力し、コントラスト比、通常テキストと大きなテキストの両方の WCAG AA と AAA の合格/不合格ステータス、組合せの視覚的プレビューを即座に見られます。デザインフェーズに色の選択を検証するために、コードレビュー中に実装された色がデザインと一致することを確認するために、アクセシビリティ監査中に既存の問題を特定して修正するために使いましょう。ツールは16進数、RGB、HSL の色の値を受け入れ、各色の計算された輝度を比とともに表示します。

よくある質問

WCAG AA に必要なコントラスト比は？

WCAG AA は通常文字で最低 4.5:1、大きな文字（18px 以上、または14px 以上の太字）で 3:1 を要求します。

AA と AAA の違いは？

AAA の方が厳しく、通常文字で 7:1、大きな文字で 4.5:1 です。AA は推奨される最低基準です。