color theoryApril 13, 202610 min read

アクセシブルな色のコントラスト:グレーのぼやけた表現をなくしたWCAG

ブランドイメージを単調なグレーにすることなく、WCAG 2.2のコントラスト基準を満たすデザインを実現する方法。比率、APCA、実際のデザインシステム事例、そしてトークン化されたテストワークフローをご紹介します。

By Boone
XLinkedIn
accessible color contrast

アクセシビリティとデザインの個性は相反するものではありません。これは、多くのブランドチームがコントラストに関する議論を避ける際に自らに言い聞かせている誤解であり、多くの「アクセシブル」なリブランディングが空港の案内標識のような見た目になってしまう理由でもあります。

アクセシブルな色のコントラストは、測定の問題です。現代のデザインシステムは、トークンレイヤーですでにこの問題を解決しています。つまり、WCAGを達成することとブランドの面白さを維持することのどちらかを選択する必要はありません。必要なのは、ルールを知り、ルールの誤りを見つけ、実際に作業が行われる場所を把握することだけです。


コントラストが絶対に無視できないルールである理由

約3億人が、あなたの基本パレットが想定する色とは異なる色を認識しており、さらに多くの人が、暗い場所、劣悪な画面、あるいは誰も報告していない部分的な視力障害を抱えながらインターフェースを利用しています。

低コントラストは、ウェブ上で最も一般的なアクセシビリティの失敗であり、同時に最も簡単に修正できる問題でもあります。死角、色覚異常、グレア、加齢による視力低下、安価なモニター、スマートフォンの画面に当たる直射日光。これらすべては、同じ解決策に行き着きます。それは、テキストと背景の間に十分なコントラストを確保し、デザイナーのRetinaディスプレイだけでなく、あらゆる厳しい環境下でもメッセージが確実に伝わるようにすることです。

左側に4.5:1の比率注釈が付いた適合カラーペア4組と、右側に不適合カラーペア4組を比較したボクセルパネル。アクセス可能なコントラストとアクセス不可能なコントラストの違いを示している。
左側に4.5:1の比率注釈が付いた適合カラーペア4組と、右側に不適合カラーペア4組を比較したボクセルパネル。アクセス可能なコントラストとアクセス不可能なコントラストの違いを示している。

この点を誤ると、単にユーザーを排除するだけでなく、コンプライアンス違反のリスクも伴います。EUの欧州アクセシビリティ法、米国のセクション508、オンタリオ州のAODA、そして増え続ける各国の法律はすべて、WCAGを法的参照基準としています。コントラストは、監査で最初にチェックされる項目の1つです。なぜなら、納品時に最も問題となる要素の1つだからです。


WCAG 2.2 コントラストルール(平易な言葉で解説)

WCAGでは、4.5:1、3:1、3:1という3つの数値が示されており、それぞれ特定のUI要素に適用されます。

| 要素 | AA最小値 | AAA最小値 | 注記 |

|---------|-----------|-------------|-------|

| 本文 | 4.5:1 | 7:1 | 18pt標準または14pt太字より小さいテキスト |

| 大きなテキスト | 3:1 | 4.5:1 | 18pt標準または14pt太字以上 |

| UIコンポーネントとグラフィック | 3:1 | 指定なし | ボタン、アイコン、フォームの境界線、フォーカスリング |

| ロゴまたは装飾画像内のテキスト | 対象外 | 対象外 | ブランド要素および付随的なテキストは対象外 |

AAは、ほとんどの商用製品が目指すレベルであり、ほとんどのアクセシビリティ法で要求されるレベルです。AAAはより厳格な目標であり、主に政府機関、医療機関、教育機関で使用されます。AAAを規定するコンプライアンス文書が提示されない限り、AAが最低限の基準となります。

多くのデザイナーが陥りがちな落とし穴は、非テキストのコントラスト比3:1を忘れてしまうことです。ページ背景に対して2:1のコントラスト比のフォームフィールドの境界線は、たとえ内部のラベルが基準を満たしていても、基準を満たしません。

コントラストが不十分なフォーカスリングも基準を満たしません。意味が色に依存するアイコンのコントラスト比が2.5:1の場合も基準を満たしません。非テキストのコントラストは必須です。


WCAGの計算式がしばしば間違っている理由

WCAG コントラスト比は30年前の計算式であり、人間の視覚的知覚を無視しているため、見た目がひどい色を基準に合格させ、見た目が問題ない色を基準に不合格にしてしまうことがあります。

WCAG 2の計算式は輝度のみに基づいています。テキストと背景の関係を、2つの色の相対的な明るさの線形関係として扱っています。しかし、人間の視覚系は実際にはそのような方法でコントラストを認識していません。

実際の知覚コントラストは、フォントの太さ、フォントサイズ、色温度、そして直前に目が何を見ていたかによって左右されます。WCAG 2はこれらの要素を一切考慮していません。その結果、白地に薄いグレーの文字と、薄いグレー地に黒の文字を同じように扱う比率が算出されます。実際には、前者は読みやすく、後者は目に負担がかかるにもかかわらずです。


APCAが知覚問題を解決する方法

アクセシブル知覚コントラストアルゴリズム(APCA)は、人間の視覚が実際にどのように機能するかに基づいてコントラストを測定します。そのため、WCAG 3の草案では、APCAが代替案として提案されています。

APCAのスコアは0(コントラストなし)から約108(極端なコントラスト)までの範囲です。WCAG 2とは異なり、APCAは文字の太さ、サイズ、そして極性(明るい文字と暗い文字の組み合わせでは、目に異なる印象を与える)を考慮します。

一般的なテキストにおけるAPCAの目安となる基準値:

  • 本文(16px標準):75以上(必須)、90以上(理想)
  • 小テキスト(14px標準):90以上(必須)
  • 大テキスト(24px以上):60以上(必須)
  • テキスト以外のUI要素:45以上(最低)

APCAは現時点では法的に義務付けられていません。しかし、製品版では既に内部標準として採用されています。これは、APCAが読みやすさの指標として優れているためです。賢明な選択は、WCAG 2 AAに準拠し、APCAで実際の品質を確保することです。カラートークンが適切に設計されていれば、両方の目標を同時に達成することは難しくありません。


トークン化コントラストを採用した4つのデザインシステム

これらのシステムは既にアクセシビリティをトークンレイヤーに組み込んでいるため、デザイナーは比率を計算する代わりに役割を選択するだけで済みます。

Radix Colors

Radix Colorsのエイリアシングに関するドキュメントでは、12段階のスケールがテキスト、背景、UI要素のアクセシビリティを維持するロールトークンにどのようにマッピングされるかを示しています。
Radix Colorsのエイリアシングに関するドキュメントでは、12段階のスケールがテキスト、背景、UI要素のアクセシビリティを維持するロールトークンにどのようにマッピングされるかを示しています。

radix-ui.comで実際にご覧ください。

Radix Colorsは、各ステップに役割があらかじめ割り当てられた12段階のコントラストスケールを提供します。ステップ11と12は高コントラストのテキストステップで、下位ステップと比較してWCAG AA基準を満たすことが保証されています。役割トークン(texttextContrastsolidsolidHover)により、デザイナーは比率を計算する必要がなく、役割を選択するだけで済みます。

注目すべき点:役割ごとに番号が振られたコントラストモデル。ステップ11を選択するデザイナーは、同じスケールの下位ステップと比較してWCAG AA基準を満たすことが分かります。比率はステップ番号自体にエンコードされています。

マテリアルデザイン3

Material Design 3のアクセシビリティの基本に関するドキュメント。コントラスト要件と、Materialのカラーシステムがどのようにアクセシブルな色の組み合わせをエンコードしているかを説明しています。
Material Design 3のアクセシビリティの基本に関するドキュメント。コントラスト要件と、Materialのカラーシステムがどのようにアクセシブルな色の組み合わせをエンコードしているかを説明しています。

m3.material.ioでライブ映像をご覧ください。

マテリアル3では、すべてのカラーロールに、親要素との比率が4.5:1となるように、対応するon-on-primaryon-surfaceon-error)がペアとして用意されています。このペアとなるトークンがアクセシビリティレイヤーであり、システムに直接組み込まれています。

参考にすべき点:on-パターン。デザイナーがテキストにon-primaryを使用すると、アクセシビリティが自動的に確保されます。判断を誤る余地はありません。


さらに2つの例:比率と知覚システム

RadixとMaterialは、ロールペアリングによってコントラスト問題を解決しています。次の2つのデザインは、文書化された比率と知覚的に均一なスケールによって解決しています。どちらのアプローチも有効であり、どちらも参考にする価値があります。

GitHub Primer

GitHub プライマーカラーシステムの概要。レイヤー化されたデザイントークンと、パレット構造に組み込まれたアクセシビリティガイダンスを示しています。
GitHub プライマーカラーシステムの概要。レイヤー化されたデザイントークンと、パレット構造に組み込まれたアクセシビリティガイダンスを示しています。

primer.styleで実際に見てみましょう

Primerは、前景、背景、境界線トークンを、コントラスト比が明記された明確な階層に分けます。fg.defaultbg.defaultには正確な比率が記載されており、役割に基づくセマンティックトークンも同様に扱われます。

参考にすべき点:トークンの横に比率を明記すること。関連するすべての背景に対するすべてのトークンのコントラストが明記されていれば、デザイナーと開発者はチェックツールを一切使用しなくても済みます。

Adobe Spectrum

Adobe スペクトルカラーの基本ページでは、知覚カラーシステムと、テーマ全体にわたってアクセスしやすいコントラストをデザインするためのアプローチを示しています。
Adobe スペクトルカラーの基本ページでは、知覚カラーシステムと、テーマ全体にわたってアクセスしやすいコントラストをデザインするためのアプローチを示しています。

spectrum.adobe.comでライブ映像をご覧ください。

Spectrumは、知覚的に均一なカラースケールを使用しているため、同じステップ番号を持つ2つのトークンは、色相に関係なく同じ視覚的重みを持ちます。つまり、同じテーマ内で色相を入れ替えても、コントラストの関係は維持されます。 「青では合格、オレンジでは不合格」なんてことはもうありません。

取り入れるべきは、知覚の均一性です。知覚モデルに基づいたスケール(HSLuv、OKLCH、Spectrumの独自アプローチなど)を用いることで、アクセシビリティをブランドテーマ全体にわたって適用できるようになります。


ブランドイメージを損なうことなくWCAGに準拠したカラーシステムが必要ですか?Brainyは、すべてのカラーパレットにトークンレイヤーのアクセシビリティを組み込みます。


個性を失わずにアクセシビリティを維持する方法

アクセシビリティとは、白地に黒文字、地味なブランドイメージを意味するものではありません。最も包括的な製品を世に送り出しているチームは、そのことを理解しています。

重要なのは、アクセシビリティをスタックのどの層に配置するかです。トークン層にアクセシビリティを配置すれば、ブランドは鮮やかでありながら、デザイナーはアクセシブルな成果物を生み出すことができます。最終レビューの段階にアクセシビリティを配置すると、あらゆるブランドカラーが監査に不合格となるリスク要因となってしまいます。

個性とアクセシビリティを両立させるための3つのテクニック:

  1. アクセントカラーをブランドカラーとアクセシビリティ対応カラーに分割する。 Linearは、ブランドを示す場面には特定の紫色を、インタラクティブな要素には少し異なる紫色を使用します。どちらもブランドカラーとして認識できますが、すべてのサーフェスで確実に表示されるのはどちらか一方のみです。

  2. 知覚的に均一なスケールを使用する。 OKLCHとHSLuvは、色の値を知覚される明るさにマッピングするため、コントラストを損なうことなく色相を切り替えられます。Radix、Spectrum、Material 3も、同様の機能を備えています。

  3. ダークモードは後付けではなく、並行トークンセットとして提供する。 ダークモードで正しく表示されないトークンは、ダークモードに対応していません。システムがtext-defaultを明るい画面ではある色に、暗い画面で別の色に解決する場合、両方の値が対応するサーフェスで正しく表示される必要があります。

最悪の結果は、誰も望んでいない妥協案、つまり、アクセシビリティが確保されないまま、くすんだブランドイメージになってしまうことです。これは、チームがコントラストに関するフィードバックに対して、色の組み合わせを修正するのではなく、すべての色の彩度を下げることで対応した場合に起こります。彩度を下げることとアクセシビリティは同じではありません。重要なのは、色の関係性です。


アクセシビリティテストのワークフロー

コントラストテストは安価で自動化できますが、デザインレビューまで放置すると全く意味がありません。

効果的なワークフローでは、コントラストチェックを1箇所ではなく4箇所で実行します。

ボクセルワークフロー図には、DESIGN、TOKEN LAYER、CI CHECKというラベルが付いた3つの接続されたステーションが示されており、矢印と小さなボクセルアイコンはパレット、トークン、チェックマークを表しています。
ボクセルワークフロー図には、DESIGN、TOKEN LAYER、CI CHECKというラベルが付いた3つの接続されたステーションが示されており、矢印と小さなボクセルアイコンはパレット、トークン、チェックマークを表しています。
  1. トークン定義時 トークンが作成されると、使用可能な面も定義されます。text-default は、bg-defaultbg-subtlebg-raised でのみ使用可能です。トークンのコントラストは各コンポーネントに対して一度チェックされ、ロックされます。

  2. コンポーネントのコミット時 Storybookとaxe-coreまたはpa11yの統合により、CIの一環としてすべてのコンポーネントバリアントに対してアクセシビリティチェックが実行されます。チェックに失敗した新しいバリアントは、マージ前にブロックされます。

  3. デザインファイルの引き渡し時 Figma Starkなどのプラグインや組み込みのWCAGチェッカーは、デザインツール内で問題点を検出します。レビュー時ではなく、デザイン時に問題を検出しましょう。

  4. ページレベル Lighthouse、axe DevTools、またはpa11yは、ステージング環境または本番環境のライブページで実行されます。これにより、コンポーネントテストでは見逃される実際の障害(サードパーティの埋め込み、ユーザー生成コンテンツ、動的テーマなど)を検出できます。

WebAIMのコントラストチェッカーインターフェースには、前景色と背景色の入力欄が表示され、WCAG AAおよびAAAレベルの合格/不合格インジケーターが表示されます。
WebAIMのコントラストチェッカーインターフェースには、前景色と背景色の入力欄が表示され、WCAG AAおよびAAAレベルの合格/不合格インジケーターが表示されます。

重要なのは、より多くのツールを実行することではありません。重要なのは、チェックをより早い段階で行うことです。CIパイプラインで検出されたコントラストの不備は、5分で修正できます。ローンチ前の監査で同じ不具合が発覚し、チームは1週間を無駄にしました。

この階層型アプローチが機能する構造的な理由については、デザインシステムガイドでトークンレイヤー思考が優れている理由を解説しています。また、60-30-10ルールが破られたでは、アクセシビリティの基盤となる役割ベースのカラーが、比率ベースの思考に取って代わった理由を説明しています。


よくある質問

WCAG AAで十分ですか?それともAAAが必要ですか?

AAは、ほとんどの商用製品とほとんどのアクセシビリティ関連法における標準です。AAAは特定の状況(政府機関、医療機関、教育機関など)でのみ法的に義務付けられており、カラーパレットをフラット化せずにAAAを達成するにはコストがかかります。AAを最低限の基準とし、APCAの理想を最高水準としてください。

すべての非テキスト要素はコントラスト比を満たす必要がありますか?

意味を伝える非テキストUIコンポーネントは、WCAG 2.2で最低3:1のコントラスト比が必要です。これには、ボタン、フォームの境界線、フォーカスリング、意味を持つアイコン、グラフィック要素が含まれます。純粋な装飾(背景パターン、アンビエントグラデーション)は対象外です。付随的なテキスト(ロゴタイプ、写真キャプションオーバーレイなど)も対象外です。

WCAGとAPCAの違いは何ですか?

WCAG 2は、30年前の輝度計算式に基づいた現在の法的基準です。APCAは、人間の知覚の仕組みに基づいて、WCAG 3ドラフトで提案されている代替基準です。APCAスコアは実際の読みやすさとより高い相関性を示しますが、現時点では法的に義務付けられていません。製品では両方が使用されています。WCAG 2は準拠のために、APCAは品質のために使用されています。


トークンにアクセシビリティを組み込む

アクセシブルな色のコントラストはスタイルの選択ではありません。システム特性です。

最も包括的でブランドを重視した製品を出荷しているチームは、アクセシビリティを後回しにするのではなく、カラーパレット自体の特性として扱うようになったチームです。

トークンは比率をエンコードします。スケールはペアリングをエンコードします。テストはワークフローの4つの段階で行われます。リリース前にコントラストチェッカーを画面に当てて確認する人はいません。

もし現在のプロセスが、デザイナーがパレットを「読みやすい」かどうか目視で判断するだけなら、監査に合格できません。チェックツールと手動レビューを組み合わせたプロセスなら、大規模展開で失敗するでしょう。しかし、定義レイヤーでアクセシビリティをエンコードするロールベースのトークンを使用するプロセスなら、リリースは成功します。

トークンを作成し、比率を公開し、チェックを自動化しましょう。ブランドイメージは鮮明さを保ち、インターフェースは読みやすさを維持し、監査は再構築ではなく形式的なものになります。

ブランドイメージを損なうことなくWCAGに準拠したカラーシステムが必要ですか?Brainyは、すべてのカラーパレットにトークンレイヤーのアクセシビリティを組み込みます。

Need a color system that hits WCAG without flattening the brand? Brainy builds token-layer accessibility into every palette.

Get Started