Skip to content
ブログに戻る
チュートリアル

WCAG コントラスト比完全ガイド:AA・AAA と APCA アルゴリズム

WCAG 色コントラスト完全解説:AA の 4.5:1・AAA の 7:1 しきい値、APCA Lc アルゴリズム、色覚多様性、そして不合格な組み合わせの修正法まで。

15 分で読める

WCAG カラーコントラスト比:AA・AAA・APCA — 2026 年完全ガイド

ブランドオレンジに白文字のボタンをリリースした。4K モニターで見ると鮮やかでキレもいい。ところがアクセシビリティ監査の結果は真っ赤だった。WCAG コントラスト比はわずか 1.97:1、本文向け AA のしきい値 4.5:1 に届かない。デザイナーには問題なく見えたボタンが、世界のロービジョン人口およそ 2 億 2 千万人にとっては判読できない。本記事では WCAG 2 のコントラスト比、AAA レベル、新しい APCA Lc アルゴリズム、8 種類の色覚特性、そしてそのままビルドに組み込める JavaScript 実装までを扱う。

クイックリファレンス:WCAG と APCA のしきい値一覧

規格本文サイズ大きな文字UI・アイコン備考
WCAG AA≥ 4.5:1≥ 3:1≥ 3:1法令上の最低ライン
WCAG AAA≥ 7:1≥ 4.5:1≥ 3:1上位基準
APCA 本文Lc 75+Lc 60+Lc 45+(アイコン)ドラフト・知覚ベース

「大きな文字」とは 18pt レギュラー以上、もしくは 14pt ボールド以上(CSS で言うと ≈ 24px と ≈ 18.66px)を指す。「UI」はフォームの枠線、フォーカスリング、ページを操作するためにユーザーが認識しなければならないグラフィカルなオブジェクト全般をカバーする。ロゴと純粋に装飾目的のグラフィックはコントラスト要件の対象外だ。

WCAG カラーコントラストとは何か

WCAG コントラスト比は、テキストと背景の相対輝度を比較する 1:1(コントラストなし)から 21:1(最大)までの数値指標である。Web Content Accessibility Guidelines は本文に対して ≥ 4.5:1(AA)、より高い適合度には ≥ 7:1(AAA)を要求する。

世界中のアクセシビリティ監査の多くがこの比率を参照している。W3C は 2008 年の WCAG 2.0 でこれを公表し、2.1(2018 年)と 2.2(2023 年)で精緻化した。今では主要な規制当局のほぼ全てがこれを参照する。米国の ADA、2025 年 6 月に施行された European Accessibility Act、米連邦機関向けの Section 508、カナダの AODA。いずれも事実上の下限として WCAG 2.x AA を採用している。

法令面以外にも理由はある。世界では約 2 億 2 千万人が、全盲ではないがロービジョンの状態にある。画面は読めるが、文字と背景のコントラストが十分高いときに限る、という人々だ。色覚多様性は男性で約 8%、女性で 0.5% に見られる。高齢の読者では水晶体の黄変と瞳孔の縮小が進み、60 歳以降は知覚コントラストが機能的に 20〜30% 低下する。屋外でのスマートフォン利用では、グレアでさらに 20〜40% を失う。デスクで 4.5:1 をクリアするページは、こうしたユーザー全員がぎりぎり読める下限になる。

対象読者は、本番 UI をリリースするフロントエンドエンジニア、ブランドパレットを選ぶデザイナー、監査を回すアクセシビリティ専門家、法的リスクを担当するコンプライアンスチーム。計算自体は短いが、その先で問われる判断は長い。

WCAG 2.x コントラスト比:計算式としきい値

W3C はコントラストを 3 ステップで定義している。WCAG コントラスト比を計算するには、(1) 各色をガンマエンコードされた sRGB から線形光(linear-light)値に変換し、(2) 人間の眼の赤・緑・青への感度を表す固定係数を用いて相対輝度を求め、(3) 黒に近い値を扱うために小さなオフセットを加えて 2 つの輝度を割る。

WCAG 2.1 §1.4.3 の相対輝度の式は次の通り:

L = 0.2126 × R_lin + 0.7152 × G_lin + 0.0722 × B_lin

R_linG_linB_lin は、sRGB のガンマカーブを解いた後の線形光チャンネル値だ。緑に 0.7152 という大きな重みが付いているのは、人間の眼の緑に対する感度が強いためで、光のエネルギー単位あたり緑は青の約 7 倍「視覚的にうるさい」。

コントラスト比の式:

ratio = (L_lighter + 0.05) / (L_darker + 0.05)

+0.05 は純黒(L = 0)でのゼロ除算を防ぎ、純黒に対する純白で (1 + 0.05) / (0 + 0.05) = 21:1 という最大値を与える。最小は 1:1、同じ色同士のときだ。

依存ゼロ、どこでも動く、おおよそ 30 行のバニラ JavaScript 実装が次のもの:

// sRGB hex → 線形光チャンネル
function srgbToLinear(channel8bit) {
  const v = channel8bit / 255;
  return v <= 0.04045 ? v / 12.92 : Math.pow((v + 0.055) / 1.055, 2.4);
}

// "#RRGGBB" → 相対輝度 [0, 1]
function relativeLuminance(hex) {
  const h = hex.replace("#", "");
  const r = parseInt(h.slice(0, 2), 16);
  const g = parseInt(h.slice(2, 4), 16);
  const b = parseInt(h.slice(4, 6), 16);
  return (
    0.2126 * srgbToLinear(r) +
    0.7152 * srgbToLinear(g) +
    0.0722 * srgbToLinear(b)
  );
}

// 2 つの hex 色の WCAG 2.x コントラスト比
function contrastRatio(hexA, hexB) {
  const lA = relativeLuminance(hexA);
  const lB = relativeLuminance(hexB);
  const [lighter, darker] = lA > lB ? [lA, lB] : [lB, lA];
  return (lighter + 0.05) / (darker + 0.05);
}

// 例:白背景の上のダークスレート本文
console.log(contrastRatio("#475569", "#ffffff").toFixed(2));
// → "7.58" — AA 4.5:1 はゆとりを持ってクリア、AAA 7:1 もぎりぎり超える

カラーコンバーターに 2 つの hex コードを入力すれば、同じ数字が返ってくる。さらに APCA Lc 値、色域判定、8 チャンネル CVD プレビューも横並びで表示される。しきい値そのものは具体的だ。

要素AA 最低AAA 最低備考
本文(通常テキスト)4.5:17:118pt 未満レギュラー / 14pt 未満ボールド
大きな文字3:14.5:118pt 以上レギュラー、または 14pt 以上ボールド
UI コンポーネント / アイコン3:1WCAG 2.1 §1.4.11 で 2018 年に追加
ロゴ・装飾適用外適用外コントラスト要件なし

CSS の単位変換でつまずくケースが多い。18pt はブラウザのデフォルトで 24px、14pt は 18.66px だ。本文サイズの定番である 16px は「大きな文字」のしきい値を下回るため、より厳しい AA の 4.5:1 ルールに従う。font-weight: 700 の 20px の見出しは大きな文字に該当し、緩い 3:1 が適用される。

チームを油断させがちな細かい点が 1 つある。WCAG の「大きな文字」例外は、見出しの意味的構造ではなくユーザーの可読性を基準にしている。14px の <h2> は大きな文字ではないので、4.5:1 が必要だ。24px のマーケティングコピーの段落は大きな文字に該当し、3:1 のフロアが適用される。判定の根拠はレンダリング後のピクセルサイズと太さであって、タグ名ではない。監査ではタグと見た目の不一致が指摘される。判定基準は CSS であり、HTML のセマンティクスではない。

比率の式に出てくる +0.05 という定数には明確な由来がある。画面表面で反射する環境光(フレア項)を表しており、純黒の見かけ輝度を一定の最低値まで持ち上げる役割を担う。これがなければ、純白に対して真黒を表示する OLED ピクセルでゼロ除算が起きる。これがあるからこそ、達成可能な最大比が 21:1 になり、アクセシビリティツールでよく目にするあの数字につながる。フレアを考慮すれば、物理的に 21:1 を超えられるディスプレイは存在しない。WCAG の目盛りはそこで頭打ちになる。

AA か AAA か:どちらを狙うべきか

AA は法的な下限、AAA は理想形のレベルだ。商用サイトの大半は AA を目標にする。AAA を通そうとするとブランドカラーをグレースケール寄りに寄せざるを得ず、マーケティングチームがそれを拒むからだ。判断のポイントは「高ければ高いほど良い」ではなく、ユーザーリーチとブランド表現のトレードオフにある。

場面推奨レベル理由
一般的な商用サイトAAADA / EAA 適合の基準ライン。裁判では WCAG 2 AA が引用される
政府・公共サービスAAASection 508 や EU の同等規制が AAA を推奨
医療・教育AAAユーザー層がアクセシビリティ要件の高い側に偏る
社内ダッシュボードAA利用者層が既知。ROI トレードオフが許容できる
マーケティングのランディングページAA + ブランド例外ヒーローや CTA でブランド色を許容、本文はあくまで AA

AAA を狙ったときに最初に表面化する隠れたコストは、彩度の高いブランドオレンジを白背景に対して 7:1 で通そうとした瞬間に分かる。通らないのだ。オレンジをブランドではなくなるレベルまで暗くするか、AA に妥協して暗背景の上でオレンジを使い AAA を楽勝で取りに行くかの 2 択になる。アクセシビリティ意識の高い企業を含めて、本文には AA、エラーメッセージや法的告知のような重要なテキストにだけ AAA を目指す、という運用に落ち着いている企業は多い。

規制側は AAA の普及を待ってはいない。ADA の 2024 年版 Web アクセシビリティ規則は WCAG 2.1 AA を引用する。2025 年 6 月施行の European Accessibility Act は対象デジタルサービス全般に WCAG 2.1 AA を要求する。米連邦政府の Section 508 は WCAG 2.0 AA を基準とする(可能なら AAA も推奨)。カナダの AODA、オンタリオ州のアクセシビリティ法も WCAG 2.0 AA を指している。パターンは一貫している。AA がボーダー、AAA がゴールだ。

APCA:新しい知覚ベースのアルゴリズム

APCA(Advanced Perceptual Contrast Algorithm、Myndex 名義の Andrew Somers が設計)は WCAG 3 の有力候補アルゴリズムだ。WCAG 2 の対称的な比率に代えて、-108 から +108 までの極性付き Lc スコアを返す。符号はコントラストがどちらの方向に走るか(明背景に暗文字 vs 暗背景に明文字)を、絶対値は実際の発光ディスプレイ上での知覚コントラストを表す。

APCA が議論される理由は、WCAG 2 の対称式が現実世界の 2 つの効果を取りこぼしているからだ。

  • 極性の非対称性。 暗背景に明文字と、明背景に暗文字では、WCAG 上の比率が同じでも読みやすさは異なる。WCAG 2 は両方向で同じ数字を返す。APCA は返さない。
  • ディスプレイのモデリング。 WCAG 2 の式は印刷物の輝度モデルから派生したものだ。APCA は典型的なオフィス照明下の sRGB ディスプレイに合わせて調整されており、ユーザーが実際に見る環境に近い。

トレードオフ。APCA はより複雑(極性を意識した指数とフォントウェイト補正が絡む)で、まだ規制上の標準にはなっていない。Adrian Roselli の 2026 年 4 月の解説が APCA の現在地について明快にまとめている。技術的には有望だが、WCAG 3 自体がまだ Silver トラックの初期ドラフト段階にあり、APCA は公式アルゴリズムとして批准されていない。

APCA の Bronze レベルしきい値(多くのチームが実務で狙う下限)は次のようになる。

用途推奨 Lc最低 Lc
本文(16px、ウェイト 400)90+75
大きな文字(24px、ウェイト 400)75+60
UI 要素・テキスト以外のアイコン60+45
スポットテキスト・プレースホルダー30+30

APCA が注目される理由(そしてカラーコンバーターが両指標を横並びで表示する理由)は、WCAG 2 と判定が分かれるケースにある。

  • #FFA500(オレンジ)の上に #FFFFFF。WCAG 2 は 1.97:1 を返し、AA の明確な不合格。APCA も Lc 38 前後で同様に不合格だ。両方のアルゴリズムが NO と言うのに、「見た目はいい感じだから」とこの組み合わせをそのまま出してしまうデザイナーは少なくない。
  • #767676(中間グレー)の上に #FFFFFF。WCAG 2 は 4.54:1 を返し、AA 4.5:1 をぎりぎり超え技術的にはパス。APCA はこのペアを約 Lc 60 と判定し、本文向け APCA Bronze の 75 しきい値を下回る。WCAG は通り、APCA は落ちる。ユーザーの体感は APCA の判定の方に近い。白地の上のグレーは、比率の示唆よりも本文サイズでは読みづらい。
  • #3b82f6(Tailwind blue-500)の上に #000000。WCAG 2 は 5.71:1 を返し、AA に余裕で合格。APCA は約 Lc 65 で本文の Lc 75 最低ラインを下回る。ダークモードで定番の「暗背景に明るい青文字」は、まさに WCAG では通るが APCA がフラグする典型例だ。

どちらか片方を選ぶ必要はない。本番プロダクトチームが落ち着く現実解はこうだ。監査が WCAG 2 AA をチェックする以上、規制ベースラインとして WCAG 2 AA を維持する。一方で、ダークモード設計や彩度の高いブランド色については「実際に読めるのか」のサニティチェックとして APCA を並走させる。カラーコンバーターは両方の数字を 1 行に表示するので、別々のチェッカー間でコンテキストスイッチする必要がない。

色覚多様性とコントラスト以外の話

コントラスト比は色のアクセシビリティの半分にすぎない。男性のおよそ 8%、女性の 0.5% は、教科書に出てくる三色型の色覚とは異なる見え方をする。最も多い変異であるデュータノマリーは、成功とエラーの状態に多用される赤緑ペアのど真ん中に位置している。WCAG 1.4.1(「色の使用」)は色だけを情報の唯一の媒介にすることを明確に禁じている。そのために存在する条文だ。

色覚特性の全体像は 3 つのグループに分かれる。二色型(dichromacy。錐体が 1 つ欠ける)、異常三色型(anomalous trichromacy。錐体が 1 つずれている)、まれな全色盲(monochromacy)系。

種別通称影響を受けるチャンネル出現率(男 / 女)
Protanopia赤色盲L 錐体 欠損1.0% / 0.01%
Deuteranopia緑色盲M 錐体 欠損1.1% / 0.01%
Tritanopia青色盲S 錐体 欠損0.003% / 0.003%
Protanomaly赤色弱L 錐体 偏移1.3% / 0.02%
Deuteranomaly緑色弱M 錐体 偏移5.0% / 0.4%
Tritanomaly青色弱S 錐体 偏移0.01% / 0.01%
Achromatopsia全色盲全錐体 欠損0.003%(極めて稀)
Cone monochromacy部分的グレー錐体が 1 種のみ0.001%

デュータノマリーだけで男性人口の 5%、つまり 20 人に 1 人だ。赤いエラーインジケータと緑の成功インジケータがほぼ同じオリーブ褐色に見える人々である。解決策はカラーシステムを再設計することではなく、2 本目のチャンネルを足すことだ。赤いエラーアイコンに「×」の形と「Error」の文字を組み合わせれば、上の表にあるどの変異でも判別できる。ただの赤い点では判別できない。

CVD をコードでシミュレートするには 2 種類の標準的な行列を使う。二色型には Brettel-Viénot-Mollon(1997)、異常三色型には Machado-Oliveira-Fernandes(2009)だ。Brettel のアプローチは、入力色を残りの 2 つの錐体応答が張る平面に射影する。Machado は錐体の偏移を重症度でパラメータ化する。どちらも SVG フィルターや CSS マトリクスとして実装できる。カラーコンバーターでは 8 つの変異全てをワンクリックでプレビューできるため、ページを離れずにブランド色をスペクトル全体でスキャンできる。

ページに貼り付けて ID で参照すれば、ブラウザ内で簡易プロタノピア(赤色盲)シミュレーションができる短い SVG フィルターを示す。

<svg style="display: none">
  <filter id="protanopia">
    <feColorMatrix type="matrix" values="
      0.567 0.433 0.000 0 0
      0.558 0.442 0.000 0 0
      0.000 0.242 0.758 0 0
      0.000 0.000 0.000 1 0"/>
  </filter>
</svg>

<style>
  .preview-protanopia { filter: url(#protanopia); }
</style>

ページのラッパーに .preview-protanopia を当てれば、プロタノピアでの見え方を再現できる。デューテラノピア・トリタノピアの行列でも同じ要領で(Brettel 論文に係数が記載されており、大半の CVD シミュレータライブラリにバンドルされている)。Chrome DevTools の Rendering パネルの「Emulate vision deficiencies」にも同じシミュレータが組み込まれているが、ざっくり確認するには便利、CI でスクリーンショットをキャプチャするには不向きだ。

シミュレーションのさらに奥にある原則。2 つの状態の違いを色だけに任せてはいけない。アイコンは形で差を付け(× vs )、状態はテキストラベルで(「Error」vs 「Success」)、カテゴリはパターンで(塗りつぶし vs ハッチング)。色は他のシグナルを補強する手段であり、代替物ではない。

コントラストチェッカーは見つけられないが、CVD シミュレータが拾うタイプの不具合がある。色相だけで区別された円グラフのセグメント、国を色分けする地図の凡例、緑・黄・赤のグラデーションに頼ったステータスピル。これらは背景に対しては WCAG 2 を通過しつつ、デューテラノピアの読者が互いに比較したときに判別できないことがある。ルールは「デザインの中で隣り合う色の間」での可読性を確認することであって、周囲のキャンバスに対してだけ確認することではない。同じ明度で隣接する 2 つの slate-500 セグメントは、色相を回しても区別できない。隣接領域の間に輝度の段差を入れれば、どの CVD 変異でもチャートは判別可能になる。

全色盲(Achromatopsia)と錐体一色型(cone monochromacy)はまれだが、明示的に設計対象に含める価値がある。色相による差を全て潰すからだ。全色盲のユーザーは輝度しか知覚せず、色分けされた UI はグレースケール写真のように見える。ページ全体に filter: grayscale(1) をかけても破綻しないデザインであれば(DevTools で試してみるといい)、「色だけを唯一のシグナルにしない」原則の最も厳格なバージョンを通過したことになる。最も安価に実行できるアクセシビリティテストであり、トグルした瞬間に意外な数の不具合があぶり出される。

Tailwind と Material のパレットを監査する

フロントエンドの仕事の大半は、既製パレット(Tailwind v4、Material 3、Radix、shadcn)のいずれかを使っている。アクセシビリティの問いは「このランプのどのストップから文字が読めるようになるのか」に変わる。答えは、ドキュメントに書かれているよりも経験則寄りだ。

Tailwind v4 の slate ランプを純白の背景に対して並べると、WCAG と APCA の数字は次のようになる。

Tailwind クラス近似 hex対 白 WCAGAA 本文AAA 本文APCA Lc(概算)
slate-400#94a3b82.56:1~38 ✗
slate-500#64748b4.76:1~60 ✗ 本文
slate-600#4755697.58:1~78 ✓ 本文
slate-700#33415510.35:1~90 ✓ 本文

そこから出てくる実務上のルール。

  • 本文には slate-600 以上が必要。 slate-500 は WCAG AA を通るが APCA の本文しきい値で落ちる。コンプライアンス的には合格でも、体感は厳しい。slate-600 が安全な下限。
  • UI ラベルと補足テキストは slate-500 でよい。 UI コンポーネントは 3:1 で足りる。slate-500 の 4.76:1 は十分に楽で、しかも周辺の視覚的コンテキストがテキストを補ってくれる。
  • プレースホルダーは slate-400 か、それより淡くてよい。 プレースホルダーは装飾扱いで WCAG 1.4.3 の対象外だが、それはフィールド上に常時表示のラベルがある場合に限る。「インラインラベル兼プレースホルダー」のパターンは本文と同じしきい値を満たさなければならない。
  • slate-100 や slate-200 の上に純黒は強すぎる。 17:1 超に達している。可読性を損なわずに柔らかい印象を出したいなら、本文色を slate-700 や slate-800 に。

Material 3 も似たトーナルパレット構造を採用する。surface-container-high はトーン 92 付近(非常に明るい)、on-surface はトーン 10 付近(ほぼ黒)に位置する。Material 仕様により、同系列の on-surface と任意の surface-* トークンの組み合わせは AA を通ることが保証されている。ただし on-surface-variant(トーン 30)と surface-container(トーン 94)の組み合わせは検証なしに使わないこと。本番に流れたのを実際に見た典型的なミスだ。

既存パレットがコントラストで落ちる場合、最もきれいな修正経路は OKLCH だ。hex を当てずっぽうにいじる代わりに、色を OKLCH に変換し、C(彩度)と H(色相)を固定したまま、コントラストが通るまで L(明度)を下げる。OKLCH の L チャンネルは知覚ベースなので、ブランドの認識性を保ったまま対比だけを締められる。HEX → OKLCH コンバーターは一発でこの変換を行う。姉妹記事の OKLCH 解説 では数学を解説している。

ダークモードには専用の段落を割く価値がある。WCAG 2 の対称的な比率は、定義上、ライトモードとダークモードの同じ組み合わせを同じ数字で通す。極性に敏感な APCA は、ダークモードの本文を同じ hex ペアのライトモードよりも読みづらいと頻繁にフラグする。同じ数値比であっても、暗の上の明は常に明の上の暗より知覚コントラストを失う。眼の順応特性として知られた効果だ。リリース前に、ダークモードの全ペアで APCA を回し直すこと。

コントラストチェッカーと CI ワークフロー

デザイナーもエンジニアもそれぞれお気に入りのチェッカーを持っている。実務的な問いは「現実のワークフローにどの組み合わせで組み込むか」だ。2026 年現在の状況は次のとおり。

ツールWCAG 2APCACVD シミュパレット監査
WebAIM Contrast Checker
Adobe Color
Stark(Figma プラグイン)
Polypane(ブラウザ)
Chrome DevTools カラーピッカー✓(実験)
axe DevTools✓(ページ単位)
Go Tools カラーコンバーター✓(8 種)✓(Tints/Shades)

本番プロダクトの圧力に耐えるワークフローはこんな形になる。

  1. Figma 段階で、デザイナーが各フレームに Stark を走らせて不合格ペアを早期に洗い出す。Stark は hex がコードベースに入る前に明らかな違反を捕捉する。
  2. hex 引き渡し時、エンジニアは値をカラーコンバーターに貼り、WCAG 比 + APCA Lc + 色域判定 + CVD プレビューを 1 行で受け取る。ダークモードや彩度の高いブランド色のペアなら、Stark が見落とすかもしれない「WCAG パスで APCA フラグ」のケースを 2 指標で拾える。
  3. PR の段階で、axe-core/playwright がレンダリング済み DOM を走査し、動的状態も含めてコントラスト違反を検知する。デザインファイルが見落とすフォーカスリング・ホバー状態・disabled の表示をこの工程で捕まえる。
  4. QA 工程で、Chrome DevTools の Rendering タブでプロタノピア・デューテラノピア・トリタノピアを切り替え、クリティカルなフローを抜き取り確認する。DevTools のカラーピッカーは要素にホバーするだけで WCAG 比をその場に表示する。

Pa11y、Lighthouse CI、@axe-core/playwright はいずれも、より広いアクセシビリティ監査の一部としてコントラスト断言を提供する。どれも現時点では APCA はチェックせず、全て WCAG 2 を見る。現実的な落とし所は「CI では WCAG 2 AA を強制、ブランド色とダークモードについては APCA Lc を手動でサニティチェック」だ。

規模の大きいデザインシステムチームから借りる価値のあるパターンがある。コントラストチェックをページレベルの QA ではなく、トークン検証のステップに組み込む。デザイントークンがソースファイル(JSON・YAML・TypeScript モジュール)からコンパイルされるなら、システムが許す全ての --text-* × --surface-* の組み合わせを列挙し、最低 WCAG 比をアサートするスクリプトを足す。スクリプトはミリ秒で走り、誰かがトークン値を変更したリグレッションを捕まえ、デザインチームのドキュメントを兼ねるコントラスト行列を出力する。レンダリング済みページに依存せず、トークンだけで動くので、UI が出荷される前に不具合を捕捉する。

このワークフロー中のその場限りの変換、つまりデバッグ中に hex、RGB、HSL、OKLCH を行き来する作業には、HEX → RGBHEX → HSLHEX → OKLCHRGB → HEX のスポーク群が、ツールチェーンが要求するどの色フォーマットの往復にも対応する。

よくある落とし穴と直し方

アクセシビリティ監査を何年も回していると、同じ 6 つの失敗が繰り返し出てくる。それぞれに有効な修正がある。

  1. 薄いグレーのプレースホルダー。 #999999 を白地に置くと 2.85:1 で AA 不合格。#666666 まで濃くする(5.74:1、AA パス)か、より望ましいのはプレースホルダーをラベル代わりに使うパターン自体をやめ、フィールド上に常時表示のラベルを置くこと。プレースホルダーに情報を担わせない。

  2. ブランドオレンジに白文字のボタン。 白地に #FFA500 で 1.97:1。AA を大きく下回る。ブランドを守る修正は、コントラストの向きを反転させることだ。オレンジ背景に暗い文字(例:#451a03)を載せるか、白文字のままボタンを深い彩度の茶オレンジに沈める。リリース前にカラーコンバーターで確認すること。

  3. ダークモードの明るいブルーリンク。 #000000 上の #3b82f6 は 5.71:1 で WCAG AA はパスするが APCA Lc は約 65、本文の Lc 75 しきい値を下回る。OKLCH を取り出して L を ≈ 0.63 から 0.75 まで上げ、C と H を固定すれば、ほぼ #7aa5f8 に落ち着き、APCA Lc 80+ の余裕と同じ色相が手に入る。

  4. #CCCCCC の disabled テキスト。 白に対して 1.61:1。WCAG 1.4.3 は純粋な装飾テキストを比率ルールの対象外とするが、disabled の UI コントロールは装飾ではなく、「現在利用不可」という情報を伝えている。淡い色には色以外の手がかり(取り消し線、ロックアイコン、「Disabled」ツールチップ)を必ず添えて、CVD やロービジョンのユーザーも状態を理解できるようにする。

  5. 色相だけで区別するステータスアイコン。 赤い × と緑の なら、形がすでに区別を担っているので OK。赤い点と緑の点は NG。形と色を併用すること。カラーコンバーター の CVD プレビューを使えば、失敗ケースが一瞬で見て取れる。

  6. グラデーション背景の上の文字。 #3b82f6 から #a78bfa へのグラデーションに白文字を置くと、中央ではコントラストを通り、ラベンダー寄りの端で落ちる。修正は、グラデーションの最悪点に対してコントラストを成立させるか、半透明の暗いスクリムを重ねて実効背景輝度を既知のしきい値以下に押さえることだ。

それぞれの修正は数分で済む。回避できる監査サイクルは数週間規模だ。

FAQ

WCAG AA のコントラスト比とは何か?

WCAG AA は本文と背景の間で ≥ 4.5:1 を、大きな文字(18pt 以上レギュラー、または 14pt 以上ボールド)とフォーム枠線のような UI コンポーネントには ≥ 3:1 を要求する。AA は ADA・EAA・Section 508 の下での法的下限で、商用サイトの大半がここを狙うのは、ブランド色をグレースケール寄りに引っ張らずに規制ラインをカバーできるからだ。

AAA を満たすにはどれくらいのコントラスト比が必要か?

WCAG AAA は通常の本文に ≥ 7:1、大きな文字に ≥ 4.5:1 を要求する。AAA はユーザー層がアクセシビリティ要件の高い側に偏る医療・教育・政府サイトに推奨される。AAA を通すにはブランド色をグレースケール隣接の値まで均す必要がしばしば生じるため、多くの商用プロダクトは AA で止まる。

APCA とは何か、それは WCAG 3.0 なのか?

APCA(Advanced Perceptual Contrast Algorithm)は、Andrew Somers / Myndex によって設計された WCAG 3 Silver プロジェクトの候補アルゴリズムだ。対称比の代わりに -108 から +108 までの極性付き Lc スコアを使う。2026 年時点で WCAG 3 はまだ初期ドラフトであり、APCA は正式に批准されていない。今日満たすべき規制基準は WCAG 2.1 / 2.2 AA だ。

ダークモードはコントラストのアクセシビリティを助けるか?

場合による。自動的に助けにはならない。WCAG 2 の対称比はライトモードとダークモードの同じ組み合わせを同じように通すが、極性に敏感な APCA はダークモードの本文を同じ hex ペアのライトモードより読みづらいと頻繁にフラグする。リリース前にダークモードを WCAG と APCA の両方で必ず再テストすること。明の上の暗が失う知覚コントラストは、対称比では捉えられない。

なぜブランド色は WCAG AA を通らないのか?

中明度・高彩度の色(オレンジ、黄、ライムグリーン、ライトブルーの多く)は相対輝度が白に近すぎて 4.5:1 を越えられない。修正の方向はこうだ。ブランドの色相はアクセントや大きな見出しに残し、本文には同じ色相ファミリーのより暗いトーンを当てる。色相をずらさずに L チャンネルだけ下げるのに OKLCH を使う。カラーコンバーターが最も近い合格シェードを一手で見つけてくれる。

WCAG 2 の比率と APCA のスコアは互換性があるか?

互換性はない。WCAG 2 は対称比(1〜21)を返し、APCA は極性付き Lc スコア(-108 〜 +108)を返す。両者の関係は非線形で、WCAG で 4.5:1 のペアが、どちらの色が上に来るかで APCA では Lc 60 にも Lc 75 にもなりうる。互いの翻訳ではなく、独立した 2 つのチェックとして扱うこと。

小さな UI アイコンにコントラストを使ってよいか?

使ってよいが注意点がある。WCAG 2.1 §1.4.11 は UI コンポーネントとグラフィカルなオブジェクトに ≥ 3:1 を要求する。可視のテキストラベルとペアになった装飾アイコンであれば、コントラスト要件は緩和される(意味はラベルが担う)。単独で立つアイコン(例:ラベルなしの虫眼鏡)の場合は、周囲の背景に対して 3:1 をきちんと満たすこと。

シミュレーターを使わずに色覚多様性をテストするには?

Chrome DevTools → Rendering → 「Emulate vision deficiencies」で Protanopia・Deuteranopia・Tritanopia・Achromatopsia を切り替える。これにカラーコンバーターの 8 種 CVD プレビュー(最も多い Deuteranomaly は男性の 5%)を組み合わせれば、異常三色型までカバーできる。監査レポート用には、各シミュレーション下でスクリーンショットを撮り、レビュアーが失敗モードをインラインで見られる形にする。

まとめ

本記事全体を支える 5 つのポイント。

  • AA 4.5:1 は法的な下限。 本文には必ず満たすこと。さもないとコンプライアンス上の指摘が続く。
  • AAA 7:1 は医療・教育・政府向け。 商用ブランドのほとんどは設計上 AA で止まる。
  • APCA Lc は実際の可読性のサニティチェック。 WCAG 2 と並走させる。特にダークモードと彩度の高いブランド色について。
  • 色は唯一のシグナルではない。 あらゆる色のキューは形・文字・パターンと併用する。デューテラノマリーだけで男性ユーザーの 5% を占める。
  • OKLCH の L が正しいツマミ。 色がコントラストで落ちたら、色相をずらさずに直すには S でも B でもなく L を下げること。

カラーコンバーターに 2 つの hex コードを入力すれば、WCAG 比、APCA Lc、色域判定、8 種 CVD プレビューが横並びで見られる。本記事で説明した監査を片付けるのに、6 つのツールを 1 つのビューで置き換えるのが最速の道筋だ。