Webアクセシビリティのコントラスト比：4.5対1と3対1の適用範囲・CSS実装・自動検証の落とし穴

コントラスト比は、アクセシビリティ対応のなかで数値がはっきり決まっている数少ない論点です。それでも実装が止まるのは、数値そのものではなく「どの要素にどちらの数値が効くのか」と「自動検証ツールが緑のまま通す箇所はどこか」の2点でしょう。この記事では1.4.3と1.4.11の適用範囲、計算で前提が外れる場面、トークンでの実装、axeが未判定を返す条件、CIでの合格ラインを扱います。対応全体の進め方はウェブアクセシビリティ向上の進め方｜JIS改正でWCAG 2.2へを参照してください。

まとめ：4.5対1と3対1の適用範囲と、自動検証で残る未判定の始末

数値は3つ覚えれば足ります。文字は4.5:1、大きな文字は3:1、文字でないUI部品と図形は3:1。レベルAAAを狙う場合だけ文字が7:1に上がります。判断が割れるのは数値ではなく境界で、どこまでが「大きな文字」か、どこからが「付随的」で対象外かを先に決めておきましょう。

実装は個々の要素に色を当てる方式をやめ、デザイントークンの側で前景と背景を対にして閉じるのが確実です。任意の組み合わせを許す変数設計にすると、検証すべき対が組み合わせの数だけ増えます。CSSのcontrast-color()はBaselineに到達しましたが、返るのは白か黒の2値だけで、単体ではブランド配色の判定を代替できません。

そしてもっとも事故が起きるのが検証です。axeの色コントラスト規則は、グラデーション背景や画像の上の文字を「未判定（incomplete）」として返し、violationsには載せません。CIでは違反0件と未判定0件の両方を合格条件にし、目視で判定した項目は台帳に残して次回の対象から外す。ここまで組んで適合が担保されます。

コントラスト比の達成基準：4.5:1と3:1がどこまで適用されるか

どの達成基準がどの要素に効くのかを整理します。ここを曖昧にしたまま配色を決めると、後の診断で全面的な塗り直しになります。

1.4.3が求める4.5:1と、大きな文字にだけ認められる3:1の線引き

達成基準1.4.3（コントラスト・最低限）はレベルAAで、テキストおよび文字画像に4.5:1以上を求めます。外れるのは3つだけ。大きな文字は3:1まで緩和され、付随的なもの（非アクティブなUI部品、純粋な装飾、視覚的に見えないテキスト、意味のある他の視覚的内容を含む画像の中の文字）とロゴタイプには要求がありません。

大きな文字の定義は18ポイント以上または14ポイント太字以上で、W3Cの定義には日本語や中国語のフォントでは同等のサイズを指すという但し書きが付きます。CSSでは18ポイントがおよそ24 px、14ポイント太字がおよそ18.66 px。デジタル庁デザインシステムは24 CSS px以上または18 px以上の太字を採っています（2026年8月12日時点）。換算に幅がある以上、境界付近で3:1に寄せる設計は避けましょう。なおレベルAAAでは1.4.6が効き、文字は7:1です。規格の全体像はWCAGとは何か？アクセシビリティ向上のための国際的な基準で扱っています。

文字以外に3:1を求める1.4.11が対象とするUI部品と図形の範囲

達成基準1.4.11（非テキストのコントラスト）はWCAG 2.1で追加されたレベルAAの基準で、隣接する色に対して3:1以上を求めます。対象はUI部品（部品と状態の識別に必要な視覚的情報）とグラフィカルオブジェクト（内容の理解に必要な図形の部分）の2つ。文字ではないので1.4.3のスキャンには引っかかりませんが、こちらには該当します。

漏れやすいのは、入力欄の枠線、チェックボックスの輪郭、トグルのオンとオフを見分ける部分、フォーカスリング、グラフの折れ線と凡例です。非アクティブな部品が例外である点は、無効化したボタンの文字色を薄いグレーのままにしてよい根拠になります。ただし押せない理由が伝わらないのは別の問題です。

JIS X 8341-3:2016に1.4.11が入っていない事情と発注時の扱い

国内でよく参照されるJIS X 8341-3:2016は、WCAG 2.0と一致した内容です。1.4.11はWCAG 2.1で追加された基準なので、JIS:2016の達成基準一覧には存在しません。「JIS X 8341-3:2016のAA準拠」という要件をそのまま満たすだけなら、フォーカスリングや入力欄の枠線は検査対象に入らないことになります。

この差は2026年中に埋まる見込みです。WAICは2026年6月8日にWCAG 2.2日本語訳を更新し、理由としてJIS X 8341-3改正の検討過程で生じた修正の反映を挙げました（2026年8月12日時点）。改正後のJISが2.2側に揃えば1.4.11も検査範囲へ入ります。要件定義では参照規格をJIS:2016に置いたうえで、WCAG 2.1と2.2で追加されたレベルAとAAも検査範囲に含めると明記しておく。この一文の有無で改修の発生時期が変わります。関係の整理はJIS X 8341-3およびWCAGガイドラインに基づく対応の重要性、義務の線引きはWebアクセシビリティは義務化されたのか？2024年改正法の線引きと企業がやるべきことを参照してください。

相対輝度からコントラスト比を出す計算式と、前提が外れる3つの場面

ツールの数値を鵜呑みにできない場面を見分けるには、計算の中身を知っておく必要があります。

相対輝度を求める式と、比の分母と分子に0.05を足している理由

手順は3段階です。まずsRGBの各チャンネル値を255で割って正規化する。次にガンマを外し、0.04045以下なら12.92で割り、それより大きければ0.055を足して1.055で割った値を2.4乗する。最後に赤へ0.2126、緑へ0.7152、青へ0.0722を掛けて足すと相対輝度Lが出ます。比は、明るいほうのLに0.05を足した値を、暗いほうのLに0.05を足した値で割った数です。

この0.05は画面表面で反射する周囲光を見込んだ定数で、おかげで比が発散せず最小1:1・最大21:1に収まります。緑の係数が突出している点は勘所につながり、同じ数値幅なら緑を動かすともっとも比が動く。青だけを濃くしてもほとんど改善しません。白背景で4.5:1をぎりぎり満たす無彩色は#767676のおよそ4.54:1、3:1の境界は#949494のおよそ3.03:1です。

半透明とopacityの指定は合成後の実効色に直してから測り直す

1つ目の前提外れです。計算式が受け取れるのは不透明な2色だけで、アルファ値を持つ色は扱えません。やっかいなのはopacityプロパティで、要素とその子孫を一括で半透明にするため、トークンで定義した文字色と背景色の対は保たれているのに実際の比が下がります。半透明を使うなら背景色のアルファ値で表現し、文字色は不透明のまま残しましょう。モーダル背後のオーバーレイやホバー時の薄い膜も同じ扱いです。

text-shadowや縁取りはコントラスト比の計算に反映されない

2つ目の前提外れです。写真の上に白い文字を置き、読めるようにtext-shadowで暗い影を付ける。見た目には読めても、計算式が見るのは2色だけなので影は考慮されません。縁取りも同様です。影ではなく帯を敷くほうが判定を通しやすく、帯を敷くか、文字部分だけ画像を暗くするか、文字を画像の外へ出すかの3択になります。

3つ目の前提外れが、背景がひとつに決まらない場合です。グラデーション、繰り返しの背景画像、動画の上のテロップ。背景色が座標ごとに変わるため、比は「最悪の1点」で判定してください。この判定は自動では付かず、次章の未判定の話につながります。

CSSでの実装：デザイントークンの側で色の組み合わせを閉じる設計

個別のCSSルールでコントラストを気にする方式は、規模が大きくなると破綻します。

前景色と背景色を対で定義し、任意の組み合わせを許さない設計にする

色トークンを--gray-100から--gray-900のような段階だけで定義すると、実装者は任意の2つを組み合わせられます。組み合わせは段階数の二乗で増え、そのすべての検証は現実的ではありません。代わりに、面と、その面に載せてよい文字色を対で定義します。

:root {
  --surface-base: #ffffff;
  --text-on-base: #1f1f1f;

  --surface-muted: #f2f4f7;
  --text-on-muted: #3d4451;

  --surface-accent: #14448c;
  --text-on-accent: #ffffff;
}

.card {
  background-color: var(--surface-muted);
  color: var(--text-on-muted);
}

面のトークンを決めれば文字色が一意に決まる形にすると、検証すべき組み合わせは面の数だけに縮みます。この形なら比の検証をトークン定義への単体テストとして書け、対を配列に持って相対輝度から比を計算し、4.5を下回ったら失敗させる。描画前に落ちるので修正コストが最小です。

contrast-color()とcolor-mix()を使える範囲と代替の書き方

CSSのcontrast-color()は、渡した色に対して白か黒のうち比が大きいほうを返す関数です。MDNによるとBaselineには2026年4月時点で到達しており、最新版のブラウザでは動きます（2026年8月12日時点）。

ただし返るのは2値だけで、同じ資料には中間トーンでは小さな文字の可読性を保証しないという注意書きが付いています。使うのは、ユーザーが色を選ぶ画面のように事前に組み合わせを列挙できない場合に限りましょう。color-mix()は面から派生色を作れますが、混ぜた結果の比は保証されないので検証対象に加えてください。

ダークモードと強制カラーモードへの切り替えで比が崩れる箇所の点検

ライトモードで通した配色がダークモードで崩れる箇所には傾向があります。最多は、明るい背景では十分だった薄いグレーの補助テキスト。次が枠線で、白背景に3:1あった境界線が暗い面では見えなくなります。ダークモード用の色は反転で作らず、対をもう1組定義してモードごとに検証してください。

強制カラーモード（Windowsのハイコントラストなど）はさらに事情が違い、著者の指定色がシステム側の配色に置き換わります。壊れるのは、背景画像やグラデーションだけで意味を表現している箇所。色が置き換わっても情報が残るよう、境界線や文字ラベルを併置しましょう。

フォーカスリングとフォーム入力欄の枠線に3:1を効かせる実装の勘所

1.4.11でもっとも指摘が多いのがフォーカスリングです。ブラウザ既定のアウトラインをoutline: noneで消し、代替を用意しないまま出荷するパターンが典型で、キーボード操作の利用者は現在位置を失います。フォーカス位置が読み上げに現れるかの確認はWebアクセシビリティのスクリーンリーダー対応：NVDA・VoiceOverでの実機検証と読み上げ順序の設計で扱っています。

.button:focus-visible {
  outline: 3px solid #1a56db;
  outline-offset: 2px;
}

.input {
  border: 1px solid #6b7280;
}

比を測る相手は「隣接する色」なので、ボタンの背景色とリングの色、そして外側の面の色の両方に対して3:1を確認します。outline-offsetで隙間を空けると外側の面だけを相手にすればよく、判定が単純になる。入力欄の枠線も同じで、白背景に#ccccccはおよそ1.6:1しかなく基準を満たしません。状態を支援技術へ伝える仕組みはWAI-ARIAとは何か？その概要と目的をわかりやすく解説で扱っています。

自動検証の落とし穴：violations 0は合格を意味しない

ここが本記事の中心です。自動検証と相性がよいと言われますが、それは条件が揃った場合の話です。

axeがincompleteを返す条件と、件数を見ない運用の危うさ

axe-coreのcolor-contrast規則はWCAG 2 AAの4.5:1を検査しますが、公式のルール一覧ではこの規則は「needs review」に分類されています。判定が確定しない場合に、違反ではなく未判定として返す設計です。

未判定になる代表的な条件は、背景がグラデーションのとき、背景画像の上に文字があるとき、疑似要素で背景を作っているとき、要素が画面外へ移動しているとき。いずれも前景色と背景色を一意に取れず、偽陽性を出さない方針に従って判定が保留されます。

問題はこの結果の受け取り方でしょう。CIでresults.violationsの長さだけを見ていると、未判定は何件あってもテストが通ります。グラデーションを多用したページでは判定がほぼ全件未判定になり、それでも緑になる。「違反0件」の意味は、未判定の件数と併せて読んでください。診断を三層に分ける考え方はWebアクセシビリティ診断の進め方：自動・手動・当事者検証の三層設計と外注の判断基準で扱っています。

画像内の文字とcanvasの描画文字が検査の対象から外れる理由

自動検証はDOMを走査するため、テキストノードとして存在しない文字は視界に入りません。バナー画像に焼き込まれた文字、図版のラベル、canvasで描いた文字。一方で1.4.3は「テキストおよび文字画像」を対象にしており、画像の中の文字にも4.5:1が求められます。検査されないが基準の対象である、というずれが抜け穴です。文字画像を作らない方針を規約に書きましょう。

状態と表示モードは1回のスキャンでは網羅できないという前提を置く

スキャンが見るのは、その瞬間に描画されている1つの状態だけです。ホバー、フォーカス、押下中、無効、エラー表示。これらは通常は開かれず、モーダルの中身も同様。ライトモードでスキャンすればダークモードの配色も検査されません。網羅するには状態とモードを外側から与えます。コンポーネントカタログがあるなら状態ごとに検査対象として登録し、無ければPlaywrightで状態を作ってから走らせてください。

CIへの組み込みと、未判定のまま残った項目に始末をつける運用手順

検査の限界がわかったら、それを前提に合格ラインを決めます。決めるのは失敗条件・状態の与え方・目視結果の残し方の3つです。

Playwrightとaxe-coreでincompleteも失敗として扱う

失敗条件は、違反0件と未判定0件の両方にします。未判定を許すと、前章で挙げた条件がすべて素通りします。

const results = await new AxeBuilder({ page })
  .withTags(['wcag2aa'])
  .include('main')
  .analyze();

expect(results.violations).toEqual([]);
expect(results.incomplete).toEqual([]);

この設定だと最初は未判定が大量に出ます。そこで条件を緩めるのではなく、1件ずつ処理してください。グラデーション背景の上の文字は単色の帯に変えるか両端で目視して台帳に記録する。疑似要素の背景は実背景色を持つ要素へ書き換える。多くは実装側を直すほうが早く、直した分だけ未判定が減ります。

目視で判定した結果を台帳に残し、次回以降の再検査から外す運用手順

自動では判定できない項目は残ります。画像内の文字、動画の上のテロップ、外部埋め込みのウィジェット。これらは目視で判定し、対象の場所・判定日・測った比の値・測定に使った2色・判定者・次回の再判定条件を台帳に残してください。

要は最後の1つです。「この画像が差し替わったら再判定」と書いておけば、無条件の再確認を毎回やらずに済みます。axeの側では、判定済みの要素に除外理由を添えて明示的に指定する。excludeにセレクタを並べただけの設定は、半年後に誰も説明できません。費用の考え方はWebアクセシビリティ対応の費用：診断・改修・運用の三層で見積を分解するで扱っています。

Lighthouseのスコアと達成基準への適合は別物として扱う

Lighthouseのアクセシビリティスコアは、内部でaxe-coreの一部規則を実行した結果を重み付けしたものです。したがって前節の未判定の性質をそのまま引き継ぎます。スコア100は「自動で検査できた範囲に違反が無かった」という意味であって、達成基準に適合したという意味ではありません。

実務では、Lighthouseは回帰の検知に使い、適合の判定には使わないと役割を分けましょう。リリース前の判定はaxeの違反と未判定の件数、それに目視台帳の消し込み状況で行う。既存サイトで色の対を作り直す場合は範囲の洗い出しから見積が要るため、Webアクセシビリティ対応で相談内容を整理してから声を掛けてください。

日本語サイトで全文4.5:1に寄せる判断と、それを見送るべき場面

大きな文字の3:1という免除を使うかどうかは規格上は自由ですが、日本語サイトでは推奨できません。理由を数字と運用の両面で示します。

日本語のCJK字形を踏まえると大きな文字の免除は使いにくい理由

W3Cの定義には、日本語や中国語のフォントでは18ポイントまたは14ポイント太字と「同等のサイズ」とだけ書かれ、具体的な数値は示されていません。漢字は同じフォントサイズでもラテン文字より画数が多く、線が細くなる。同じ24 pxでも英字の見え方と漢字の見え方は揃いません。

デジタル庁デザインシステムは、大きな文字を24 CSS px以上または18 px以上の太字と定義したうえで、免除を使わず全テキストに4.5:1を課す方針を採っています（2026年8月12日時点）。国の設計指針が免除を使わない側に振っている事実は判断材料になるでしょう。運用面でも、免除を使うと必要な比がフォントサイズに依存します。全文4.5:1なら判定はサイズから独立します。

ブランド色を変えられない案件で取れる3つの逃げ道と、その適用限界

とはいえ、ブランドガイドラインで色が固定された案件はあります。コーポレートカラーが中間トーンで、白文字でも黒文字でも4.5:1に届かないという状況です。取れる手は3つ。

1つ目は、面に使うのをやめること。ボタンの背景をブランド色にする代わりに枠線と文字へ使い、面は白のままにします。枠線に効くのは1.4.11の3:1なので通しやすい。2つ目は、明度だけ動かした派生色で文字用と面用を分けること。色相と彩度を保てば印象は変わらず、実務でもっとも通しやすい。3つ目は使用範囲をロゴと装飾に限ることで、1.4.3の例外に該当します。限界も明確で、リンクの文字色や状態表現に使いたいという要望は救えず、ガイドライン側を直す交渉に入ります。

全文4.5:1を採用する条件と、3:1の免除に頼る条件の切り分け

採用条件を言い切ります。新規に配色を決められる案件、トークンを自分たちで管理している案件、公共・医療・金融・教育など利用者の年齢層が広い案件では、全文4.5:1を採ってください。判定がサイズから独立し、JIS改正後の再検査も要りません。1.4.11の3:1も同時に織り込みます。

見送る条件も明示します。既存サイトの部分改修で、見出しだけが3:1と4.5:1の間にあり、色を変えると数十コンポーネントの再検証が発生する場合。ここは見出しに限って免除を使い、24 px以上をコンポーネントの制約として固定しましょう。サイズを動かせない制約付きなら後から崩れません。もう1つは期限が先に決まっている場合で、本文と操作系を先に寄せ、装飾的な見出しを次期改修へ回します。

Webアクセシビリティのコントラスト比でよくある質問｜判定と例外

実装の相談で繰り返し挙がる論点を5つ挙げます。

コントラスト比が4.4:1でした。四捨五入して合格にしてよいですか？

合格にはできません。条文は「4.5:1以上」です。ツールによっては小数第1位までしか表示せず、4.5と出ていても実際は4.45という場合があります。実務では基準ぴったりを狙わず4.7:1程度の余裕を持たせましょう。

プレースホルダのテキストにもコントラスト比の基準は掛かりますか？

掛かります。プレースホルダは非アクティブなUI部品ではなく可視のテキストなので、1.4.3の対象です。ブラウザ既定の色は白背景に対して4.5:1を下回ることが多く、指定し直す必要があります。なおラベル代わりに使う設計は、入力開始で説明が消えるため避けてください。

グラデーション背景の上に文字を置く場合、どこで比を測りますか？

文字が実際に乗る範囲のうち、もっとも比が小さくなる位置で測ります。線形グラデーションなら文字領域の両端を測り、どちらも満たすかを見てください。レスポンシブで折り返す場合は乗る範囲が変わるため、幅を変えて複数回測ります。手間を考えると、文字の背後だけ単色の帯を敷くほうが短く済むでしょう。

無効化したボタンは薄いグレーのままでよいのですか？

達成基準の上では問題ありません。1.4.3の例外に非アクティブなUI部品が含まれ、1.4.11にも同様の除外があります。ただし押せない理由が伝わるかは別の論点でしょう。無効化の代わりに、押せる状態のままエラーを返す設計に変えると、この問題は消えます。

APCAという新しい計算方法があると聞きました。今から採るべきですか？

現時点では見送ります。APCAはWCAG 3の検討で扱われている知覚ベースの計算方法で、文字の太さやサイズを込みで評価する点が現行の式より実態に近いとされます。ただしWCAG 3自体が草案の段階で、達成基準として参照できません（2026年8月12日時点）。適合の判定は2.2の式で行い、APCAは配色検討時の補助として見る使い分けです。

関連記事

• ウェブアクセシビリティ向上の進め方｜JIS改正でWCAG 2.2へ：対応全体の進め方と検査範囲の決め方。
• Webアクセシビリティ診断の進め方：自動・手動・当事者検証の三層設計と外注の判断基準：未判定項目をどの層で拾うかの設計。
• Webアクセシビリティ対応の費用：診断・改修・運用の三層で見積を分解する：色の作り直しが伴う場合の費用構造。
• Webアクセシビリティは義務化されたのか？2024年改正法の線引きと企業がやるべきこと：義務と任意の線引きを確認。
• WCAGとは何か？アクセシビリティ向上のための国際的な基準：達成基準とレベルの構成を規格側から整理。