- はじめに
- WCAG 2.xのコントラスト比は、何を測っているのか
- なぜ「実感とズレる」ケースが増えてきたのか
- APCAという新しいアプローチ
- WCAG 2.x と APCA は対立するものではない
- APCA基準で実際にチェックするには？
- では今、どう考えればいい？
- 終わり
- 参考
はじめに
enechainプロダクトデザインデスクのマネージャーの近藤（@add_kk）です。
日々のデザインで色の組み合わせを考える時に、
「4.5:1（3:1）を満たしているのに、なんだか読みにくい」
そんな違和感を抱いたことはないでしょうか。例えば、
- ダークモードで使う、少し薄めのグレー文字
- UIの端にある小さな補足テキスト
「コントラストチェッカーを通すと数値上はパスしている。でも、実際はなんだか「読みにくい」と感じてしまう」
この記事では、そんな引っかかりから出発し、WCAG 2.x のコントラスト比の仕組みや限界を解説します。その上で、その限界を補うための新しいアプローチである APCA（Advanced Perceptual Contrast Algorithm） について整理し、理解を深めていきたいと思います。
WCAG 2.xのコントラスト比は、何を測っているのか
WCAG 2.x におけるコントラスト比
Webアクセシビリティの文脈で「コントラスト比」といえば、多くの方が WCAG 2.x の基準を思い浮かべると思います。
- 通常テキスト (AAA)： 7:1 以上
- 通常テキスト(AA)：4.5:1 以上
- 大きなテキスト(AAA）：4.5:1 以上
- 大きなテキスト(AA）：3:1 以上
デザインツールやチェッカーにも広く組み込まれていて、アクセシビリティ対応の「共通言語」として機能しています。実務で色を決めるときに、まずこの数値を確認するという方も多いのではないでしょうか。
コントラスト比の計算のしくみ
コントラスト比の計算式は以下です。
(L1 + 0.05) / (L2 + 0.05)
L1, L2はそれぞれ、明るい色の相対輝度、暗い色の相対輝度を表します。
計算の流れはシンプルです。
- 前景色と背景色、それぞれの RGB 値から相対輝度（Relative Luminance）を算出する
- 明るい方と暗い方の輝度の比率を求める
ただし、相対輝度自体を求めるのはなかなか複雑なので、ここでは省略しますが、興味のある方はWCAGのページ及び以下の記事が参考になります。
大事なのは「2つの色の明るさの比率を見ている」という点です。色相や彩度ではなく、あくまで輝度の差を見ている、ということになります。
WCAG 2.xの前提条件
この計算式自体はシンプルですが、いくつか割り切っている部分もあります。
- 文字サイズを細かくは考慮しない（「通常」と「大きな」の2段階のみ）
- フォントウェイトは評価に含まれない
- 明るい背景と暗い背景を区別しない
- 文字の種類（言語や書記体系の違い）も考慮しない
つまり、白背景に黒文字でも、黒背景に白文字でも、同じ色の組み合わせなら同じコントラスト比になります。14pxのLight体でも、24pxのBold体でも、色が同じなら同じ数値です。 シンプルだからこそ広く普及した。でもそのシンプルさが、現代のUIでは「実感とのズレ」を生むことがあります。
ほぼ同じ4.5:1のコントラストでもダークモードのテキストの視認性がライトモードに比べて明らかに下がります。
なぜ「実感とズレる」ケースが増えてきたのか
WCAG 2.xが想定していたUIの世界
WCAG 2.x のコントラスト比は、もともと以下のようなUIを前提に設計されていました。
- 明るい背景に暗い文字
- 比較的大きな本文テキスト
- ラテン文字（アルファベット）中心
- 文字サイズやウェイトのバリエーションが少ない
この条件が揃っている場面では、WCAG 2.x のコントラスト比は今でも十分に機能します。「基準が古くなった」という話ではなく、前提としていた条件が変わってきた、という話です。
WCAG 2.0が勧告された2008年当時と現在では主流なディスプレイ環境も異なります。
当時の主流はLCDで、輝度もコントラスト比も今ほど高くなく、「黒」にもバックライトの光が漏れていました。現在はOLED（有機EL）が普及し、ピクセル単位で完全な黒を出せるディスプレイが一般化しています。
この変化はコントラスト体験を根本的に変えました。暗い背景と明るい文字のコントラストが極端に強くなりやすく、ハレーションや眩しさといった、輝度比だけでは測れない知覚上の問題が顕在化しています。WCAG 2.x のコントラスト比は、こうした変化を織り込んでいるわけではありません。
現代UIで崩れ始めた前提
ダークモードの普及
暗い背景では、同じ比率でも光の滲み（ハレーション）で見え方が変わります。
UIの高密度化
特にBtoBプロダクトなどでは、情報の密度を上げるために小さなラベルや細いフォントが多用されます。
低彩度カラーの活用
洗練された印象を作るために、絶妙なニュアンスカラーが好まれるようになりました。
こうした変化が重なった結果、「数値はOK、体感はNG」という状況が生じやすくなっています。
日本語UI
さらに、日本語環境に特有の事情もあります。
英語UIと日本語UIでは、一般的なベースフォントサイズが異なります。英語圏では 16px が標準的ですが、日本語UIでは 14px や 13px をベースにしているプロダクトも少なくありません。
加えて、日本語、特に「漢字」には構造的な特徴があります。
- ストローク数が多い
- 字面の内部が詰まりやすい
- 小さくすると潰れて読みにくくなりやすい
たとえば「議」「鋼」「薬」のような画数の多い漢字を 12px + Regular で表示すると、背景とのコントラスト比が 4.5:1 を満たしていても、かなり読みづらく感じることがあります。ラテン文字の "a" や "e" とは、文字の複雑さがまったく違うわけです。
同じ色、同じコントラスト比でも、日本語の方が読みにくく感じやすい。これは WCAG 2.x の計算式では捉えられない差です。
12pxでの日本語テキストと欧文テキストの比較。同じフォントサイズでも日本語テキストの方が大き目なのにも関わらず、画数の多い感じではやはり視認性は下がります。
数値だけでは説明できない「読みにくさ」
ここまでの話を簡単にまとめると、WCAG 2.x のコントラスト比は、以下の要素を区別していません。
- 文字サイズの細かな違い
- フォントウェイトの違い
- 文字構造の違い（英語 / 日本語）
- 背景の明暗方向
そのため、英語UIでは問題にならない配色が、日本語UIでは辛くなるというケースが発生します。
繰り返しますが、WCAG 2.x が間違っているわけではありません。策定時の前提条件と、現在のUIの現実とのあいだにギャップが生じている、というのがより正確な見方です。
APCAという新しいアプローチ
APCAとは何か
APCA（Advanced Perceptual Contrast Algorithm）は、次世代のWebアクセシビリティガイドラインである WCAG 3.0 での採用が検討されているコントラスト評価の考え方です。 最大の特徴は、「色の比率」ではなく「人間の知覚」を基準にしている点にあります。同じ色の組み合わせでも、文字のサイズやウェイト、背景の明暗方向によって「見え方」は変わる。APCAは、その「見え方」の違いを評価に組み込もうとしています。
WCAG 2.xとの決定的な違い
明背景と暗背景を区別する。
白地に黒文字と、黒地に白文字では、人間が感じるコントラストは同じではありません。APCAはこの非対称性を計算に組み込んでいます。
文字サイズとウェイトを考慮する。
同じ色の組み合わせでも、大きな見出しと小さなキャプションでは求められるコントラストが違います。APCAでは、サイズとウェイトに応じて「必要なコントラスト値」が変わります。
Lc（Lightness contrast）という新しい尺度を使う。
WCAG 2.x の「◯:1」という比率ではなく、Lc という独自のスケールでコントラストを表現します。
先程の比較をそれぞれLcで測ってみるとこうなります。Lc基準ではダークモード表示でのコントラスト評価が大きく下がっています。
Lc（Lightness Contrast）という尺度
Lc のスケールはおおよそ -108 〜 +108 の範囲です。符号は背景の明暗方向を表していて、正の値は明るい背景に暗い文字、負の値は暗い背景に明るい文字を意味します。コントラストの強さを評価する場合は符号を外した絶対値が使われます。
そして、APCAの大きなポイントは「文字の用途によって必要な Lc 値が変わる」という考え方です。
たとえば、大きな見出しであれば低めのコントラストでも十分読めますが、本文テキストではより強いコントラスト基準が求められます。また、テキストの重要度などによって複数推奨ラインがあります。アイコンやプレースホルダーなどにも基準が設けられ、利用者側からも使いやすくなっています。「一律 4.5:1」ではなく、用途に応じて「読めるライン」を設計できる。これがAPCAの考え方です。
Lc75に合わせて調整したものです。ダークモードの視認性が明確に上がっているのが確認できると思います。体感でも両方の見え方が大分近くなってきたのが感じられるのではないでしょうか。
APCAが解決しようとしていること
APCAは、まさに前章で挙げたような「WCAG 2.x では捉えきれなかった違和感」に対応しようとしています。
- ダークモードでの読みにくさ
- 小さな文字の可読性
- ウェイト差による見え方の変化
デザイナーが「なんとなく読みにくい気がする」と感じていたものに、数値的な根拠を与えてくれる可能性がある。それがAPCAの意義だと思います。
補足: ダークモードとコントラストの考え方
もう一つ、ダークモードに関しても触れておきたい点があります。
ダークモードを好む人の中には、ライトモードと同じ強いコントラストを必ずしも快適だと感じないケースもあります。暗い背景に対して強い白文字は、視認性は高い一方で、にじみや疲労を感じやすくなることもあります。
そのため、「ダークモードでもライトモードと同じコントラストが必要なのか」という問いも、再考され始めています。
WCAG 2.x と APCA は対立するものではない
よくある誤解
ここまで読むと「じゃあ WCAG 2.x はもう古いのか」「APCAに乗り換えるべきなのか」と思われるかもしれません。しかし、そういう話ではありません。
現時点では、法的要件やプロダクトのアクセシビリティ準拠として求められるのは WCAG 2.x です。APCA はまだ WCAG 3.0 の策定プロセスの中にあり、正式な基準としては確定していません。「APCAがあればWCAGは不要」ということにはなりません。
現実的な使い分け
実務としては、次のような位置づけで捉えるのが現実的です。
- WCAG 2.x：最低限クリアすべき準拠ライン。法的・契約的な要件として守る。
- APCA：UXや設計判断の補助軸。「本当に読めるか」を確認するためのセカンドオピニオン。
どちらか一方ではなく、両立させる。WCAG 2.x をベースラインとして守りつつ、APCAの視点で「体感としての読みやすさ」を補完する。この二段構えが、今のところ一番バランスの取れたアプローチではないかと思います。
APCA基準で実際にチェックするには？
ブラウザ拡張でのチェック
Chrome や Edge 向けに、APCA 対応のコントラストチェッカーがいくつか公開されています。実際の画面上でテキストを選択し、Lc 値を確認できるものもあります。
特にダークモードの確認とは相性が良く、「この暗い背景でこのグレー、本当に読めるのか？」を Lc 値で客観的に判断できるのは助かります。
デザイン段階でのチェック
Figma 向けにも APCA 対応のプラグインが出ています。フォントサイズやウェイトを含めた評価ができるため、デザインの段階で「この組み合わせは読みやすいか」を確認しやすくなります。
デザインレビューの場で「なんとなく読みにくい」ではなく「Lc 値がこれだけしかない」と示せるのは、チーム内のコミュニケーションとしても有効です。
個人的に使っていておすすめなのは “Contrast” です。簡単な切替でAPCA, WCAGどちらも気軽にチェックすることができます。
https://www.figma.com/ja-jp/community/plugin/748533339900865323/contrast
いずれのツールも「APCA contrast checker」などで検索すると見つかりますので、気になった方は試してみてください。
日本語フォントのサイズやウェイトをAPCA基準でより正しく評価したいという方は、以下の記事で紹介されている「APCAコントラスト日本語フォント検証」を試してみるとよいでしょう。
では今、どう考えればいい？
ここまでの内容を踏まえた情報の整理と、それに基づく私なりの提案は以下の通りです。
WCAG 2.x の数値は引き続き守る。
これは変わりません。アクセシビリティ準拠の基本ラインとして、4.5:1 / 3:1 の基準は今後も押さえるべきものです。
ただし「読めるかどうか」は別の軸でも確認する。
コントラスト比をパスしていても、ダークモード・小さな文字・日本語の漢字など、条件によっては読みにくい場合があります。数値だけで安心せず、実際の画面で、実際の文字サイズで確認する習慣を持つことが大切です。
APCAは「違和感を言語化するための道具」として使う。
「なんか読みにくい気がする」というデザイナーの直感を、Lc値という数値に変換できる。それだけでも、レビューや意思決定の場面で大きな武器になります。
終わり
これまで、アクセシビリティにおけるコントラストは「4.5:1」という、いわば絶対的なルールとして語られてきました。しかし今回見てきたように、ディスプレイの進化やUIの多様化、そして日本語特有の事情によって、そのルールだけでは説明しきれない場面が増えてきています。
APCAという新しいアプローチは、「コントラストは、色・サイズ・ウェイト・背景のすべてが組み合わさって決まるデザイン要素である」という、デザイナーが直感的にわかっていたことを、改めて数値で裏付けてくれるものです。
コントラストは読みやすさを設計するための武器です。
WCAG 2.xとAPCA、2つの基準を手元に置きながら、「本当に読みやすいか」をあらためて問い直してみてはいかがでしょうか。
enechainでは、エネルギー取引に特化したプロダクトを作っています。マーケット画面や市況データの表示など、一画面あたりの情報量が非常に多く、情報の優先度と視認性のバランスは常に向き合っているテーマです。今回の整理を通じて自分自身もクリアになった点が多くあったので、引き続きプロダクトに活かしていきたいと思います。
enechainでは、一緒にプロダクトを成長させ、信頼できるブランドを育てていける仲間を募集中です。興味のある方はぜひTech Recruit Portalをご覧ください。
