色のコントラストチェック｜WCAG 2.1 (AA/AAA) 適合判定とアクセシビリティ計算
- 通常テキスト AA 基準: 4.5 : 1 以上
- 大文字・UI 枠線 AA 基準: 3.0 : 1 以上
- 通常テキスト AAA 基準: 7.0 : 1 以上
- 判定ツール: 下のコンポーネントでリアルタイム判定
1. オンライン WCAG カラーコントラストチェッカー
前景色と背景色を選択・入力し、リアルタイムにコントラスト比と WCAG 2.1 の合格判定を表示します。
👁️ この場でアクセシビリティをチェックする
WCAG 2.1における判定基準の差異
Webアクセシビリティの国際標準であるWCAG 2.1では、コンテンツの種類に応じて異なるコントラスト比の閾値を設けています。すべてのテキストに一律の基準を適用するのではなく、視認性の重要度や要素の役割（見出し、ボタン、本文など）に基づいて判定が分かれるのが特徴です。
この違いを正しく理解せずにデザインを進めると、特定の要素だけが読み取りにくい、あるいは操作しづらいといったアクセシビリティの欠陥を見落とす原因となります。ツールを活用する際は、対象となる要素が「通常のテキスト」なのか「大きなテキストやUI要素」なのかを明確に区別して判定を行う必要があります。
| 要素の種類 | WCAG 2.1 AA基準（目標） |
|---|---|
| 通常テキスト | 4.5:1 以上 |
| 大きなテキスト* | 3:1 以上 |
| UI要素（ボタン等） | 3:1 以上 |
※「大きなテキスト」とは、18pt（24px相当）以上のサイズ、または14pt（18.66px相当）以上の太字を指します。 「UI要素」とは、ボタンや入力フォームの境界線など、ユーザーの操作を導くための視覚的なインジケーターを指します。
例えば、メインコンテンツの本文であれば「4.5:1」の基準を満たす必要がありますが、大きな見出しやナビゲーションボタンであれば「3:1」を満たせば合格となります。このツールでは、入力したカラーコードに対してこれらの判定を個別に算出するため、デザインシステムにおけるコンポーネントごとの要件定義に即した正確な検証が可能です。
ツールによる判定結果の視覚化
このツールを使用する最大の利点は、抽象的な「見やすさ」を具体的な数値と合格・不合格のステータスに変換できる点にあります。前景色（Foreground）と背景色のカラーコードを入力すると、システムは即座にコントラスト比を計算し、WCAG 2.1の各基準に対する適合状況を表示します。
例えば、グレー系の配色を採用する際に「#767676」と「#FFFFFF」を組み合わせた場合、ツールは単に数値を算出するだけで、それが「通常テキスト（4.5:1）」や「大きなテキスト（3:1）」の基準を満たしているかを判定します。
前景色 (Foreground): #767676
背景色: #FFFFFF
コントラスト比: 4.54:1
WCAG AA (通常テキスト 4.5:1): Pass
WCAG AA (大きなテキスト 3:1): Pass
WCAG AAA (通常テキスト 7:1): Failこのように、数値が「4.5」をわずかに上回っているのか、あるいは「7」に届いていないのかを正確に把握できるため、デザインの微調整が必要な箇所を即座に特定できます。また、「プレビュー用テキスト」フィールドを活用することで、実際のフォントサイズや太さを適用した際の視認性をシミュレーションすることも可能です。これにより、計算上の数値だけでは判断しにくい、非常に細かな色の境界線における可読性の検証が可能になります。
実務における配色パターンの検証
Webサイトやアプリケーションにおいて、ボタンやリンクといったインタラクティブな要素は、ユーザーの操作に応じて状態が変化します。実務においては、静的なデザインの状態だけを確認するのではなく、動的な挙動を伴うすべての状態に対してコントラスト比の適合性を確認する必要があります。
例えば、ナビゲーションメニュー of ボタンを設計する場合、以下の3つの状態すべてで適切なコントラスト比を確保しなければなりません。
- 通常時（Default）: ユーザーが操作する前の基本状態
- ホバー時（:hover）: マウスカーソルが重なった際の変化
- フォーカス時（:focus）: キーボード操作などで選択された際の強調表示
例えば、ボタンの背景色を「#E0E0E0」とし、マウスホバー時に少し濃い「#D1D1D1」へ変化させるデザインの場合、両方のカラーコードをこのツールに入力して検証する必要があります。特に、アクセシビリティへの配慮が求められるUI要素（ボタンや入力フィールドの枠線など）では、状態の変化によってコントラスト比が低下し、特定の操作タイミングでテキストが読み取れなくなるリスクがあるためです。
デザインシステムを作成する際は、これらの各ステートス（State）ごとにカラーコードを定義し、このツールを用いて一つずつ「Pass」判定を得ることで、実装後の手戻りを防ぎ、誰にとっても使いやすいインターフェースを構築できます。
デザインシステムへの統合と検品
実務におけるデザイン工程では、FigmaやAdobe XDなどのツールを用いてコンポーネントを定義します。これらのツールで作成したカラーパレットやスタイルガイドが、アクセシビリティの要件を満たしているかを「実装前」に検証するワークフローを構築することで、開発後の手戻りを最小限に抑えることができます。
具体的には、デザインツール上で定義されたボタンコンポーネントやカードの背景色などのカラーコード（例：#3498db や #f1f3f5）を抽出し、このツールの「前景色」と「背景色」フィールドにコピー＆ペーストします。これにより、デザインレビューの段階で「WCAG AA（通常テキスト 4.5:1）」などの判定結果を即座に確認できます。
例えば、ブランドカラーを採用した際、意図したデザインよりもコントラストが低く、特定のユーザーにとって読み取りにくいことが判明した場合、その時点でより濃い色や明るい色の代替案へ修正することが可能です。このプロセスをデザイナーとエンジニアの共通の検品フローに組み込むことで、アクセシビリティ違反を早期に発見し、品質の高いUIを安定して提供できるようになります。
3. 実務における注意点（ハマりどころ）
opacityやrgba透明度によるコントラスト低下- CSS で
color: rgba(0, 0, 0, 0.5)のように半透明文字にすると、背後の要素が透けて計算上のコントラスト比（4.5:1）を下回り、不合格になります。
- CSS で
- ホバー・フォーカス（:hover / :focus）状態の検証漏れ
- 通常時は 4.5:1 を満たしていても、ホバー時にボタン背景が明るくなりコントラストが崩れるケースが多発します。全状態で検証してください。