何もインストールせずにカラーコントラストを監査する方法

カラーコントラストの監査は、専門的なアクセシビリティ作業として扱われがちです。デザインファイルを開き、プラグインをインストールし、スクリーンショットを書き出し、レポートを実行し、ブランドカラーについて議論する。そうした作業が役立つこともありますが、多くのチームが最初に取り組むべき場所ではありません。

本番環境のウェブサイトであれば、最も速く信頼できる監査は、たいてい今すでに開いているブラウザで行えます。現在のブラウザ DevTools では、算出済みの色を調べ、コントラスト比を表示し、状態ごとのスタイルを明らかにし、自動レポートが見落としやすい厄介なケースを検証できます。

このガイドでは、何もインストールしないことを前提にします。ブラウザ拡張機能は使いません。デザインプラグインも使いません。有料の監査スイートも使いません。必要なのは、ページ、ブラウザ、そしてシンプルな方法だけです。

実際に必要なコントラストのルール

ほとんどのウェブ制作では、WCAG のコントラストは次のいくつかのしきい値に集約されます。

• 通常のテキスト: 背景に対して少なくとも 4.5:1 のコントラスト。
• 大きなテキスト: 少なくとも 3:1。WCAG では、おおよそ 24 CSS ピクセル、または太字の場合は約 18.66 CSS ピクセルと定義されています。
• UI コンポーネントとグラフィカルオブジェクト: 意味のある境界線、アイコン、状態、インターフェースを理解するために必要なチャート要素について、少なくとも 3:1。
• 強化されたコントラスト: ベースラインを超える水準を目指す場合、通常のテキストは 7:1、大きなテキストは 4.5:1。

例外もあります。非アクティブなコントロール、装飾要素、ロゴなどです。ただし、これらの例外は控えめに使うべきです。「ブランドの一部だから」は例外ではありません。それはデザイン上の制約です。

また、コントラストはアクセシブルな色使いの一部にすぎないことも忘れないでください。赤いエラー状態に十分なコントラストがあっても、テキスト、アイコンラベル、プログラムによる示し方がなければ、赤と近い色を区別できないユーザーにとっては依然として失敗になり得ます。

デザインファイルではなく、レンダリングされたページから始める

デザインファイルは有用ですが、現実世界のすべての変数を含んでいるわけではありません。CSS の上書き、不透明度、ホバー状態、ブラウザのフォントレンダリング、ユーザーのズーム、ダークモード、継承されたスタイル、CMS コンテンツ、マーケティング用の埋め込みなどです。

ユーザーが受け取るページそのものを監査してください。

現在のデスクトップブラウザでページを開きます。Chrome、Edge、Firefox、Safari にはいずれも有用な検査ツールがあります。正確なラベルは異なりますが、ワークフローは同じです。

1. テキストまたは UI 要素を右クリックします。
2. Inspect を選びます。
3. 算出済みの color と background-color を見つけます。
4. ブラウザのカラースウォッチまたはアクセシビリティパネルでコントラスト比を読み取ります。
5. 合格、不合格、不確実な点を記録します。

Chromium ベースのブラウザでは、カラーピッカーにコントラスト比と、テキストに関する WCAG の合否ガイダンスが表示されることがよくあります。Firefox DevTools でもアクセシビリティ情報とカラーツールを確認できます。Safari の Web Inspector では、ワークフローは少し異なりますが、算出済みスタイルとアクセシビリティ情報を表示できます。

重要なのは、特定のブラウザではありません。重要なのは、そのコンポーネントが使っているはずだと誰かが考えている値ではなく、算出された結果を読むことです。

まず小さな監査リストを作る

疲れるまでランダムにテキストを調べるのは避けましょう。パターンの短い棚卸しを作ります。

• メインページ背景上の本文テキスト。
• 控えめなテキスト、キャプション、メタデータ、プレースホルダー。
• 通常、ホバー、訪問済み、フォーカス状態のリンク。
• プライマリ、セカンダリ、破壊的操作のボタン。
• フォームラベル、ヘルプテキスト、エラー、成功メッセージ。
• ナビゲーション項目、パンくず、タブ。
• カード、バッジ、ピル、タグ。
• 意味を伝えるアイコン。
• チャート、地図、プログレスバー、ステータスカラー。
• 画像、動画、グラデーション、半透明オーバーレイの上にあるテキスト。

これで、一般的なサイトにある失敗の大半を見つけられます。また、監査を一回限りのピクセルではなく、コンポーネントに結び付けて進められます。

監査にボタンが含まれる場合は、コントラスト確認とあわせて アクセシブルなウェブボタンのチェックリスト の基本も確認してください。ボタンのコントラスト問題は、フォーカス状態の欠落、不明瞭なラベル、壊れたキーボード操作の隣にあることがよくあります。

DevTools でテキストのコントラストを調べる

単色背景上の通常のテキストであれば、ブラウザがたいていコントラストを計算してくれます。

要素を検査し、color プロパティを探します。スウォッチからカラーピッカーを開きます。ブラウザが背景を判定できる場合、コントラスト比が表示されます。ツールによっては、3:1、4.5:1、7:1 を満たす位置を示す線がカラーピッカー内に表示されます。

ブラウザが不合格を報告した場合は、反証できるまでそれを信じてください。合格を報告した場合でも、判断は必要です。小さく細い文字、品質の低いディスプレイ、強いアンチエイリアス、情報量の多い背景では、技術的には合格しているテキストでも弱く感じられることがあります。

実務上のルールとして、本文テキストが 4.55:1 でぎりぎり合格しているだけなら、喜ぶべきではありません。もっと余裕を持たせましょう。コントラスト要件は最小値であり、理想の目標ではありません。

タイポグラフィも重要です。より大きく明瞭なタイプシステムは、色を調整する前から負担を減らします。コントラストに合格しているにもかかわらずページが読みにくく感じられる場合は、読みやすいタイポグラフィの実践ガイド のようなより広い読みやすさの観点から、行長、サイズ、ウェイト、間隔を見直してください。

不透明度を含め、実際の背景を確認する

多くのコントラストの誤りは、見えている背景が宣言された背景ではないために起こります。

よくある落とし穴は次のとおりです。

• 半透明カード内のテキスト。
• 親要素に opacity が適用されているテキスト。
• rgba() や color-mix() を使ったオーバーレイ。
• 見出しの背後にあるグラデーション。
• テキスト領域内で変化する背景画像。
• ダークモードで変化するテーマ変数。

DevTools がコントラストを確信を持って計算できない場合は、レンダリングされた前景色と背景色を手動で特定します。算出済みスタイルパネルを使う、レイヤーを一時的に無効にする、またはブラウザが対応していれば組み込みのカラーピッカーで見えている色をサンプリングします。

画像上のテキストについては、画像の最も都合のよい部分をサンプリングしてはいけません。テキストの背後にあり得る最も悪い領域をサンプリングしてください。CMS アップロード、カルーセル、レスポンシブなクロップによって画像が変わる場合、それは安定したコントラストシステムではありません。画像に関係なくテキストを保護できる、信頼できるオーバーレイ、テキストシャドウ、塗りのコンテナ、グラデーション処理を追加します。

良い画像オーバーレイシステムは地味です。同じオーバーレイ強度、予測できるクロップ領域、明るい写真でも十分なコントラスト。地味で構いません。ユーザーは読もうとしているのです。

状態を忘れない

静的なスクリーンショットは、多くのコントラストの失敗を見落とします。インタラクション状態をブラウザで直接監査してください。

DevTools で、次のような疑似クラスを強制します。

• :hover
• :focus
• :focus-visible
• :active
• :visited
• :disabled
• :checked
• :invalid

そのうえで、算出済みの色をもう一度調べます。

フォーカスインジケーターには特に注意が必要です。WCAG 2.2 ではフォーカスの見た目に関する期待が強化されましたが、薄いグレーのカード上に淡い青のアウトラインが出る失敗は今でもよくあります。フォーカスインジケーターには、隣接する色に対して十分なコントラストと、気づけるだけの十分な面積が必要です。

無効化されたコントロールについては、WCAG のコントラストルールに非アクティブなコンポーネントの例外があります。だからといって、無効状態がデフォルトで読みにくくてよいわけではありません。無効状態が有用な情報を伝えるなら、読めるようにしてください。そうでないなら、そもそも表示するべきかを検討します。

Lighthouse は使う。ただし判断を委ねない

Lighthouse のようなブラウザ監査は、一部のコントラスト失敗を素早く見つけられます。ブラウザに組み込み監査があるなら実行し、その結果を出発点として扱ってください。

自動チェックは、算出済みコントラストに明らかな失敗があるテキストノードを見つけるのは得意です。一方で、次のようなものには弱いです。

• 画像に埋め込まれたテキスト。
• Canvas で描画されたラベル。
• SVG のエッジケース。
• ホバー時だけの失敗。
• フォーカスインジケーターの品質。
• 色の関係性が意味を担うチャート。
• 認証、メニュー、フォームステップの背後に隠れたコンポーネント。

レポートが緑でも、代表的なコンポーネントを調べる必要はあります。レポートが赤でも、慌てずにユーザー影響で不具合を優先順位付けしてください。同じ原則は、パフォーマンスやアクセシビリティのレポート全般にも当てはまります。ツールの出力は判決ではなく、証拠として読みます。私たちは Lighthouse レポートを慌てず読むためのガイド でもこの考え方を使っており、ここにもそのまま適用できます。

非テキストのコントラストも監査する

テキストが最も注目されますが、WCAG はインターフェースを理解または操作するために必要な非テキストコンテンツも対象にしています。

少なくとも次のケースを確認してください。

• ページ背景に対する入力欄の境界線。
• チェックボックスとラジオボタンのアウトライン。
• トグルの状態。
• アイコンのみのボタン。
• エラーアイコンと警告シンボル。
• チャートの線、棒、ラベル。
• 進捗インジケーター。
• 選択中のタブまたはアクティブなナビゲーションのインジケーター。

目標は通常、隣接する色に対して 3:1 です。たとえば、白背景上の薄いグレーの入力欄境界線は、ほとんど見えないかもしれません。5 本のパステルカラーの線を使ったチャートは、見た目は上品でも使えない場合があります。

チャートでは、コントラストだけでは不十分です。情報が色だけに依存しないよう、ラベル、パターン、線のスタイル、直接の注釈、間隔を使ってください。これは色覚特性のあるユーザー、ロービジョンのユーザー、まぶしい環境で見ている人、ドキュメント内のスクリーンショットを読む人の助けになります。

開発者が使える形式で結果を記録する

有用なコントラスト監査は、「いくつかのグレーが不合格」とは言いません。コンポーネント、状態、現在の値、期待されるしきい値、推奨修正を特定します。

コンパクトな形式がうまく機能します。

| Component | State | Foreground | Background | Ratio | Target | Result | Suggested fix | |---|---:|---:|---:|---:|---:|---|---| | カードのメタデータ | デフォルト | #8A8F98 | #FFFFFF | 3.2:1 | 4.5:1 | 不合格 | --color-text-muted-strong を使用 | | プライマリボタン | ホバー | #FFFFFF | #2F6FEA | 4.8:1 | 4.5:1 | 合格 | 維持 | | 入力欄の境界線 | デフォルト | #D7DCE2 | #FFFFFF | 1.4:1 | 3:1 | 不合格 | 境界線トークンを濃くする |

サイトにデザイントークンがある場合は、修正をそれに結び付けます。本当の問題が 1 つの弱いトークンにあるなら、20 個の個別コンポーネントにパッチを当てるべきではありません。

最小値より少し強めに修正する

コントラストの失敗は、悪いやり方なら簡単に直せてしまいます。チームがチェッカーに 4.51:1 と表示されるまで色を少し動かし、そのまま先へ進む。これでは、フォントレンダリング、透明度、ブラウザ差、テーマ設定、画像のばらつき、将来のブランド変更に対する余裕がありません。

余裕のある目標を好みましょう。

• 本文テキスト: 実用上可能なら 7:1 に近づける。
• 控えめなテキスト: 実際のコンテンツであれば、なお 4.5:1 を超える。
• UI の境界線とアイコン: 3:1 を十分に上回る。
• 画像上のテキスト: 画像ごとの推測ではなく、制御されたオーバーレイを使う。

ウェブは、安価なノート PC、暗いスマートフォン、明るい歩道、色付きのモニター、劣化したディスプレイで閲覧されます。最低限の準拠は、快適な読書と同じではありません。

<!-- tool-cta:start -->

💡 試してみましょう: DevTools から取得したコントラストのペアを確認するとき、Color Converter は hex、RGB、HSL の間で変換し、値が監査メモと一致するようにするのに役立ちます。

<!-- tool-cta:end -->

インストール不要のコントラスト監査チェックリスト

素早く、しかし信頼できる監査が必要なときは、この順序を使ってください。

1. 本番ページをモダンブラウザで開く。
2. 主要なテキスト、UI、状態のパターンを列挙する。
3. DevTools で算出済みの前景色と背景色を調べる。
4. 組み込みのカラーピッカーまたはアクセシビリティパネルでコントラストを読む。
5. ホバー、フォーカス、アクティブ、訪問済み、無効な状態を強制する。
6. 画像やグラデーション上のテキストを、あり得る最悪の背景に対して確認する。
7. 非テキストの UI 部分を 3:1 要件に照らして確認する。
8. 組み込みの自動監査を、監査全体ではなく安全網として実行する。
9. コンポーネントとトークンごとに失敗を記録する。
10. しきい値をぎりぎり超えるのではなく、余裕を持って修正する。

これで、スタックに別のツールを追加しなくても、コントラスト問題の大半を見つけるには十分です。より高度な監査にも、もちろん役割があります。特に大規模なデザインシステム、規制対象のプロダクト、複雑なデータ可視化では重要です。しかし多くのウェブサイトでは、ブラウザがすでに必要な証拠を提供しています。難しいのは、それを使えるだけ十分に体系的であることです。