WCAG 1.4.11: 非テキストのコントラスト

このルールの意味

WCAG 1.4.11 非テキストのコントラストは、WCAG 2.1 で導入され、WCAG 2.2 に引き継がれているレベルAAの達成基準です。これは、次の2つのカテゴリのコンテンツの視覚的な表示と、その隣接する色との間に、最低でも3:1のコントラスト比を求めるものです。

• ユーザーインターフェイス（UI）コンポーネント: テキスト入力、チェックボックス、ラジオボタン、トグルスイッチ、ドロップダウンメニュー、ボタンなどのインタラクティブなコントロールを識別する視覚的な境界やインジケーター。コンポーネントそのものと、ホバー、フォーカス、選択中、エラーなどの視覚的な状態変化の両方を含みます。
• グラフィカルオブジェクト: アイコン、チャート、ダイアグラム、その他の意味のある画像の一部で、コンテンツを理解するために必要なもの。情報を伝えるグラフィックの各部分は、その周囲の色に対して3:1の閾値を満たさなければなりません。

コントラスト比は、前景要素とその直近の隣接色との間で測定されます。通常は背景色、境界線の色、またはチャートの隣接するセグメントです。計算には WCAG 1.4.3 で定義されているのと同じ相対輝度の式を使用しますが、非テキスト要素は判別可能性を保ったまま、やや低いコントラストでも許容されるため、閾値は 4.5:1 ではなく 3:1 になっています。

適合とは、UIコンポーネントを識別したり、グラフィック内で情報を伝えたりするすべての視覚的インジケーターが、少なくとも 3:1 の比率を達成している状態を意味します。不適合は、境界線、アイコンのストローク、チャートのセグメント、状態インジケーターがこの比率を下回り、その視覚情報なしにはコンポーネントやグラフィックを識別・理解できない場合に発生します。

WCAG 仕様では、いくつかの重要な例外が定義されています。

• 非アクティブなコンポーネント: 無効化されていて操作できないUIコンポーネントは対象外です。クリックできないグレーアウトされたボタンは、コントラスト要件を満たす必要はありません。
• ユーザーエージェントが制御する外観: 見た目がブラウザのデフォルトスタイルによって完全に制御されており、作者のCSSで上書きされていないコンポーネントは対象外です。この場合の責任はブラウザベンダーにあります。
• 本質的または装飾的なグラフィック: 特定の見た目が伝達される情報にとって本質的であるグラフィカルオブジェクト（例: 国を表す国旗）や、純粋に装飾目的のものは対象外です。ロゴも一般的にこの条項の下で対象外となります。
• テキスト: テキストおよびテキストの画像はすでに 1.4.3 と 1.4.6 の対象であり、1.4.11 の対象にはなりません。

フォーカスインジケーターは、WCAG 2.2 において特に重要視されています。達成基準 2.4.11（フォーカスの外観）はフォーカスの視認性に対してより厳しい要件を追加しますが、1.4.11 は依然としてカスタムフォーカスリングの背景に対するコントラストに適用されます。フォーカスインジケーターとして使用されるカスタムの outline や box-shadow は、この達成基準を個別に満たすために、隣接色に対して 3:1 を達成しなければなりません。

なぜ重要か

世界保健機関によると、世界で約 22 億人が何らかの視覚障害を抱えています。このうち、推定 2 億 5,300 万人の中等度から重度の視力障害者を含む多くの人々は、必ずしもスクリーンリーダーを使用するわけではなく、デジタルインターフェイスを認識し操作するために十分なコントラストに依存しています。拡大ソフト、高コントラストモード、あるいは単に厳しい照明条件下で閲覧するロービジョンのユーザーは、1.4.11 の不適合の影響を最も直接的に受ける人たちです。

実際的なシナリオを考えてみましょう。緑内障のあるユーザーが、病院のウェブサイトで保険金請求フォームに入力しているとします。フォームのフィールドは白い背景（#ffffff）に薄いグレーの境界線（#cccccc）を使用しており、そのコントラスト比は 1.6:1 に過ぎません。これは要求される 3:1 を大きく下回ります。ユーザーは入力フィールドの始まりと終わりが見えず、そこを確実にクリックしたり、フォームの構造を理解したりできません。その結果、フォーム入力を完全に諦めてしまい、個人的な損失だけでなく、機関にとっても法的なリスクが生じます。

視覚障害にとどまらず、認知障害もコントラストの低いUIコンポーネントの解釈を難しくします。注意障害や情報処理の困難さを抱えるユーザーは、インタラクティブ要素と非インタラクティブ要素の間に強い視覚的な差異があることで、ページ構造を素早く理解しています。同様に、震えや運動障害があり大きなポインタターゲットを使用するユーザーは、コントロールの境界がはっきり見えることで、正確に狙いを定めることができます。

ビジネスの観点から見ると、1.4.11 を満たすことは、モバイル画面の強い日光、低品質なモニター、色再現性の低い古いディスプレイなど、最適とは言えない環境下にいるすべてのユーザーにとっての使いやすさを向上させます。サポートコストを削減し、到達できるユーザー層を広げ、使い勝手の悪さに起因する直帰率を下げることで、間接的にSEOも強化します。法的なアクセシビリティ要件の対象となる組織にとって、このレベルAAの達成基準に不適合であることは、直接的なコンプライアンスリスクとなります。

関連する axe-core のルール

• color-contrast（部分的なカバレッジ）: axe-core の color-contrast ルールは主に WCAG 1.4.3 におけるテキストのコントラストを対象としていますが、特定のコンテキストでは非テキスト要素に対しても部分的なチェックを行います。axe は、コンポーネントの視覚的な境界や背景が 3:1 の比率に満たないことをプログラム的に判断できる場合、ボタンやフォームコントロールなどのUIコンポーネントにフラグを立てます。しかし、このルールのカバレッジは 1.4.11 に対して明示的に部分的とされています。なぜなら、非テキスト要素の多くのコントラスト不適合は自動解析では見えないためです。例えば、SVGアイコンのストロークの背景に対するコントラストや、CSSの疑似要素で実装されたカスタムスタイルのチェックボックスの境界線などは、レンダリングコンテキストなしには DOM から信頼できる形で抽出できません。CSS の border の計算済みスタイルはアクセシビリティツリーに存在していても、隣接する背景、特にグラデーション、画像、重なり合う要素などは、プログラム的に常に計算できるとは限りません。このため、axe は多くの場合、1.4.11 の違反を color-contrast ルールの needs review 指定付きで報告します。これは、ツールが潜在的な問題を検出したものの、実際にレンダリングされたピクセルをサンプリングするために、要素を目視で確認し、カラ―コントラストアナライザーを使用して人間が確認する必要があることを意味します。

自動ツールが検出できる非テキストのコントラスト不適合は全体の一部に過ぎないため、手動テストが不可欠です。Colour Contrast Analyser（TPGi）、ブラウザの DevTools のカラーピッカー、Accessible Colors などのツールを使って、レンダリングされたインターフェイスから前景色と背景色を直接サンプリングする必要があります。自動スキャンはあくまで第一段階として扱い、包括的な監査とは見なさないでください。

テスト方法

1. axe DevTools または Lighthouse で自動スキャンを実行する: axe DevTools ブラウザ拡張機能をインストールし、ページ全体のスキャンを実行します。結果パネルで、WCAG 1.4.11 のタグが付いた問題をフィルタリングするか、color-contrast の違反を確認します。非テキストのコントラストカテゴリで Needs Review としてフラグが立っている項目に注目してください。これらは手動でのフォローアップが必要です。Lighthouse（Chrome DevTools > Lighthouse タブ）では、アクセシビリティ監査を実行し、コントラスト関連の結果を確認します。ただし、Lighthouse のカバレッジも非テキスト要素に対しては部分的であることを念頭に置いてください。
2. カラ―コントラストアナライザーによる手動検査: TPGi Colour Contrast Analyser デスクトップアプリケーションをダウンロードして開きます。スポイトツールを使って、各UIコンポーネントの境界の前景色（例: テキスト入力の境界線、アイコンのストローク、チャートバーの塗り）をサンプリングし、次に隣接する背景色をサンプリングします。ツールは計算されたコントラスト比を表示します。3:1 未満の比率はすべて不適合です。すべてのインタラクティブなフォームコントロール、アイコンのみのボタン、フォーカスインジケーター、データビジュアライゼーションを体系的に確認します。
3. キーボードナビゲーションとフォーカスインジケーターのテスト: キーボードだけを使ってページ全体を Tab で移動します。フォーカスを受け取る各インタラクティブ要素について、フォーカスインジケーター（リング、アウトライン、背景の変化）が見えることを確認します。コントラストアナライザーを使って、フォーカスインジケーターの色が要素の背景に対して 3:1 を達成していることを確認します。NVDA + Firefox と JAWS + Chrome でテストし、要素が期待される順序でフォーカスを受け取り、CSS の outline: none によって視覚的インジケーターが抑制されていないことを確認します。
4. ハイコントラストモードと強制色モードでテストする: Windows では、ハイコントラストモード（設定 > 簡単操作 > ハイコントラスト）を有効にしてページを再読み込みします。Chromium ベースのブラウザでは、DevTools を開き、Rendering パネルで Emulate CSS media feature forced-colors: active オプションを有効にします。UIコンポーネントの境界が引き続き見えることを確認します。強制色モードへの準拠は 1.4.11 の厳密な要件ではありませんが、このモードでテストすることで、低コントラストの色の手がかりだけに依存している要素が明らかになります。
5. 文脈の中でグラフィカルオブジェクトを検証する: 各チャート、アイコン、ダイアグラム、情報画像について、意味を伝えるすべてのセグメントやパスを特定します。グラフィック内の隣接する色（例: 隣り合う円グラフのセグメント）や、周囲のページ背景に対してスポイトツールで色をサンプリングします。情報を伝える各部分は、それぞれが個別に 3:1 を達成しなければなりません。
6. すべてのコンポーネント状態を確認する: インタラクティブ要素には、デフォルト、ホバー、フォーカス、アクティブ、選択中、チェック済み、エラー、成功など複数の状態があります。各状態を個別にテストします。デフォルト状態では適合しているボタンの境界線が、ホバー状態で低コントラストの色に変わると不適合になる可能性があります。

修正方法

フォーム入力の境界線 — 不適切な例

<!-- Fails: light grey border (#cccccc) on white (#ffffff) = 1.6:1 ratio -->
<style>
  .form-input {
    border: 1px solid #cccccc;
    background-color: #ffffff;
    padding: 8px 12px;
  }
</style>
<label for='email'>Email Address</label>
<input type='email' id='email' class='form-input' />

フォーム入力の境界線 — 適切な例

<!-- Passes: darker border (#767676) on white (#ffffff) = 4.54:1 ratio, exceeds 3:1 -->
<style>
  .form-input {
    border: 1px solid #767676; /* Darkened to achieve sufficient contrast */
    background-color: #ffffff;
    padding: 8px 12px;
  }
  .form-input:focus {
    outline: 3px solid #005fcc; /* Focus ring at 5.9:1 against white */
    outline-offset: 2px;
  }
</style>
<label for='email'>Email Address</label>
<input type='email' id='email' class='form-input' />

アイコンのみのボタン — 不適切な例

<!-- Fails: light grey icon (#aaaaaa) on white (#ffffff) = 2.32:1 ratio -->
<style>
  .icon-btn { background: none; border: none; color: #aaaaaa; }
</style>
<button class='icon-btn' aria-label='Delete item'>
  <svg aria-hidden='true' focusable='false' width='24' height='24'>
    <path d='M3 6h18M8 6V4h8v2M19 6l-1 14H6L5 6' stroke='currentColor' stroke-width='2' fill='none'/>
  </svg>
</button>

アイコンのみのボタン — 適切な例

<!-- Passes: dark icon (#595959) on white (#ffffff) = 7:1 ratio, well above 3:1 -->
<style>
  .icon-btn { background: none; border: none; color: #595959; cursor: pointer; }
  .icon-btn:focus-visible {
    outline: 3px solid #005fcc;
    outline-offset: 2px;
    border-radius: 4px;
  }
</style>
<button class='icon-btn' aria-label='Delete item'>
  <svg aria-hidden='true' focusable='false' width='24' height='24'>
    <!-- Darker stroke ensures the icon shape is perceivable -->
    <path d='M3 6h18M8 6V4h8v2M19 6l-1 14H6L5 6' stroke='currentColor' stroke-width='2' fill='none'/>
  </svg>
</button>

カスタムチェックボックス — 不適切な例

<!-- Fails: custom checkbox uses a light border (#d0d0d0) on white background -->
<style>
  .custom-checkbox-box {
    width: 18px; height: 18px;
    border: 2px solid #d0d0d0; /* 1.3:1 ratio against white — fails */
    border-radius: 3px;
    display: inline-block;
  }
</style>
<label>
  <input type='checkbox' style='position:absolute;opacity:0;width:0;height:0' />
  <span class='custom-checkbox-box'></span>
  I agree to the terms
</label>

カスタムチェックボックス — 適切な例

<!-- Passes: border (#5a5a5a) on white = 7.2:1. Checked state tick also uses sufficient contrast -->
<style>
  .custom-checkbox-input {
    position: absolute; opacity: 0; width: 0; height: 0;
  }
  .custom-checkbox-box {
    width: 18px; height: 18px;
    border: 2px solid #5a5a5a; /* Sufficient contrast against white background */
    border-radius: 3px;
    display: inline-flex;
    align-items: center;
    justify-content: center;
    background-color: #ffffff;
  }
  .custom-checkbox-input:checked + .custom-checkbox-box {
    background-color: #005fcc; /* Blue fill on checked */
    border-color: #005fcc;
  }
  .custom-checkbox-input:checked + .custom-checkbox-box::after {
    content: '';
    display: block;
    width: 10px; height: 6px;
    border-left: 2px solid #ffffff; /* White tick on blue = 5.9:1 */
    border-bottom: 2px solid #ffffff;
    transform: rotate(-45deg) translateY(-2px);
  }
  .custom-checkbox-input:focus-visible + .custom-checkbox-box {
    outline: 3px solid #005fcc;
    outline-offset: 2px;
  }
</style>
<label class='custom-label'>
  <input type='checkbox' class='custom-checkbox-input' />
  <span class='custom-checkbox-box' aria-hidden='true'></span>
  I agree to the terms
</label>

データチャート — 不適切な例

<!-- Fails: two adjacent pie chart segments use similar light hues with <3:1 contrast -->
<svg viewBox='0 0 200 200' aria-label='Market share chart' role='img'>
  <!-- Segment A: #f5c6cb (light pink) adjacent to Segment B: #ffeeba (light yellow) -->
  <!-- Contrast ratio between these two colors is approximately 1.1:1 — fails -->
  <path d='M100,100 L100,10 A90,90 0 0,1 190,100 Z' fill='#f5c6cb' />
  <path d='M100,100 L190,100 A90,90 0 0,1 100,190 Z' fill='#ffeeba' />
</svg>

データチャート — 適切な例

<!-- Passes: use high-contrast segment fills OR add a visible border between segments -->
<svg viewBox='0 0 200 200' aria-label='Market share chart: Segment A 50%, Segment B 25%' role='img'>
  <!-- Option 1: Use a dark stroke between segments to separate them at 3:1 against both fills -->
  <path d='M100,100 L100,10 A90,90 0 0,1 190,100 Z' fill='#d63384' stroke='#ffffff' stroke-width='2' />
  <path d='M100,100 L190,100 A90,90 0 0,1 100,190 Z' fill='#0d6efd' stroke='#ffffff' stroke-width='2' />
  <!-- The white (#ffffff) stroke separates the two segments; each fill also has 3:1 against white bg -->
</svg>

よくある間違い

• 3:1 を満たしていても低DPIで見えなくなる 1px の境界線を使うこと: 色が要件を満たしていても、境界線が 1px 幅しかないと、低解像度の画面では知覚できなくなることがあります。境界線の色が適合しているだけでなく、border: 2px solid や視認性の高い box-shadow を併用して、境界が物理的にも知覚できるようにしてください。
• 背景が常に白だと想定してしまうこと: フォームフィールドやアイコンが、薄いグレーの背景（#f5f5f5）のカードやサイドバー内に表示される場合、コントラストは白ではなくそのグレーに対して測定する必要があります。白の上では適合している境界線が、色付きの背景では不適合になることがあります。
• outline: none でデフォルトのフォーカスアウトラインを削除し、同等の代替を提供しないこと: これは 1.4.11 の最も一般的な不適合の一つです。グローバルに :focus { outline: none; } を設定すると、キーボードユーザーにとってフォーカスの視認性が失われます。常に、背景に対して少なくとも 3:1 のコントラストを達成するカスタムフォーカススタイルで置き換えてください。
• 無効状態を口実にすべてのコントラストチェックを省略すること: 無効なコンポーネントは対象外ですが、開発者が disabled 属性や aria-disabled='true' を実際には付与せず、低コントラストのスタイルだけで視覚的に無効に見せることがあります。見た目は無効でも、まだインタラクティブな要素は 1.4.11 を満たさなければなりません。
• 区切りのストロークなしに、色だけでチャートのセグメントを区別しようとすること: 隣り合うチャートセグメントが色相（例: 薄い青と薄い緑）の違いだけで区別されている場合、そのコントラスト比が 3:1 未満だと不適合になります。セグメント間に 2px の白または濃色の区切り線を追加するのが確実な修正方法です。
• デフォルト状態だけにコントラスト修正を適用し、ホバー、フォーカス、エラー、成功状態を忘れること: 各インタラクティブ状態には固有の見た目があります。デフォルト状態では適合しているボタンの境界線が、ホバー時に低コントラストの色に変わることがあります。すべての状態を個別にテストする必要があります。
• アイコンを background-image として埋め込み、CSS の color によるコントラスト調整に頼ること: HTML にインラインで埋め込まれた SVG アイコンは color や currentColor に反応しますが、CSS の background-image として使用されるアイコンは CSS で色を変更できません。アイコン画像ファイル自体のコントラストが不十分な場合、アセットを差し替えない限り、CSS だけで問題を解決することはできません。
• 入力欄のプレースホルダーテキストは 1.4.11 の対象外だが、依然として規制されていることを忘れること: プレースホルダーテキストは 1.4.11 ではなく、1.4.3（テキストのコントラスト 4.5:1）に該当します。開発者が誤ってプレースホルダーテキストに 3:1 の閾値を適用してしまい、別の 1.4.3 の不適合を見落とすことがあります。
• 非適合な中間色を通過する CSS トランジションを使用すること: 要素が、適合している色から不適合な中間色を経由して、再び適合している色へとアニメーションする場合があります。開始と終了の状態が適合していても、トランジション中はコンポーネントが技術的には不適合になります。prefers-reduced-motion メディアクエリを慎重に使用し、低コントラストの状態を経由するトランジションは避けてください。
• プログレスバー、range input、トグルスイッチを見落とすこと: これらのカスタムUIコンポーネントは、1.4.11 を考慮せずにスタイル設定されることがよくあります。プログレスバーの塗りつぶされた部分はトラックに対して 3:1 のコントラストを持たなければならず、トグルのノブはトグルの背景に対して、range input のサムはトラックに対してコントラストを持たなければなりません。

トルコのアクセシビリティ規制との関係

トルコの大統領通達第 2025/10 号は、2025年6月21日付官報第 32933 号で公布され、トルコで事業を行う幅広い公的・民間組織に対して、ウェブおよびモバイルのアクセシビリティ要件を義務付けています。この通達は、WCAG 2.2 を規範的な技術標準として採用しており、レベルAAの適合がコンプライアンスのための必須水準とされています。

レベルAAの達成基準である WCAG 1.4.11 非テキストのコントラストは、したがってこの通達の下で直接的に執行対象となります。規制の対象となる組織は、自らのデジタルプロパティ上のすべてのUIコンポーネントの境界、インタラクティブなコントロールの状態、および意味のあるグラフィカルオブジェクトが、非テキストのコントラスト要件である 3:1 を満たしていることを保証しなければなりません。

大統領通達 2025/10 の対象となる組織には、あらゆるレベルの政府機関・公的機関、eコマースプラットフォーム、銀行・金融機関、病院・民間医療機関、20万人以上の加入者を持つ通信事業者、旅行代理店、民間輸送会社、国民教育省（MoNE）に認可された私立学校が含まれます。これらの組織にとって、1.4.11 を実装しないことは、単なるベストプラクティスの欠如ではなく、規制上の不適合となります。

アクセシビリティロゴ（Erişilebilirlik Logosu）は、家族・社会サービス省によって発行され、適合したデジタルサービスに対する公に見える認証マークとして機能します。このロゴを取得・表示するには、組織は 1.4.11 を含む、適用されるすべての WCAG 2.2 の達成基準において、レベルAAに完全適合していることを示さなければなりません。多くのトルコの電子政府ポータル、バンキングインターフェイス、医療フォームは、カスタムスタイルのフォームコントロールやデータビジュアライゼーションを広範に使用しているため、非テキストのコントラストは、認証プロセスにおいて監査人が特に評価しやすい達成基準です。

Accsible のオーバーレイウィジェットを使用している組織は、オーバーレイ技術が、高コントラストテーマをユーザーが有効にできるようにするなど、実行時のコントラスト調整の一部を支援できる一方で、1.6:1 の境界コントラストでレンダリングされるフォーム入力のような恒常的な構造的問題は、真の適合を達成し Erişilebilirlik Logosu を取得するために、ソースコードレベルで修正しなければならないことを認識しておくべきです。ソースレベルでの修正と、アクセシビリティウィジェットによるユーザー向けの拡張機能を組み合わせることが、トルコ法の下で最も防御可能なコンプライアンス姿勢となります。