WCAG 達成基準 · Level AAA
WCAG 2.4.13: フォーカスの外観
WCAG 2.4.13 は、キーボードフォーカスインジケーターが、ユーザーがどの要素にフォーカスがあるかを明確に確認できるよう、最小サイズおよびコントラストの要件を満たすことを求めています。この達成基準は、キーボードや支援技術に依存する人々が、自分の現在位置を見失うことなくインターフェースを操作できるようにするものです。
- Level AAA
- Wcag
- Wcag 2 2 aaa
- 操作可能
- アクセシビリティ
このルールの意味
WCAG 2.4.13 Focus Appearance は、キーボードフォーカスインジケーターの視覚的な見え方について、正確で測定可能な要件を定めた、WCAG 2.2 で導入されたレベルAAAの達成基準です。より下位の達成基準である 2.4.11(Focus Not Obscured、レベルAA)はフォーカスされた要素が完全には隠れないことを保証し、2.4.7(Focus Visible、レベルAA)は何らかのフォーカスインジケーターが存在することだけを求めていますが、2.4.13 はさらに踏み込み、そのインジケーターが「どの程度見えなければならないか」を定義しています。
この達成基準に合格するには、キーボードフォーカスインジケーターが次のすべての条件を満たす必要があります。
- 最小面積: フォーカスインジケーターは、フォーカスされていないコンポーネントの周囲長に 2 CSS ピクセルを掛けた値以上の面積を持たなければなりません。実務的には、一般的な長方形のボタンの場合、フォーカスアウトラインの面積がボタンの周囲長 × 2px 以上である必要がある、ということです。つまり、境界全体を囲む少なくとも 2px の太さのフォーカスリングであれば要件を満たします。
- フォーカスインジケーターのコントラスト比: フォーカスインジケーターを構成するピクセルは、フォーカスされている状態とされていない状態の間で、少なくとも 3:1 のコントラスト比を持たなければなりません。たとえば、ボタンがデフォルト状態で白い背景を持つ場合、その周囲に描かれるフォーカスリングは、その白い背景に対して少なくとも 3:1 のコントラストを持つ必要があります。
- 内包コンテンツのコントラストを低下させないこと: フォーカスインジケーターは、フォーカスされたコンポーネント内のテキストやその他のコンテンツのコントラストを、4.5:1(18pt 未満 / 太字 14pt 未満のテキスト)または 3:1(大きなテキストおよび非テキストコンテンツ)を下回るように低下させてはなりません。
コンポーネントが合格するには、これら3つの条件すべてを同時に満たす必要があります。十分な大きさがあってもコントラストが不十分なフォーカスインジケーターは不合格です。同様に、コントラストが高くても小さすぎるインジケーターも不合格です。
WCAG 仕様では、1つの顕著な例外が定義されています。ブラウザのデフォルトのフォーカスインジケーター(ユーザーエージェントのデフォルト)が要件を満たしている場合、制作者はカスタムスタイルを追加する必要はありません。ただし、ブラウザのデフォルトは大きく異なります。Chromium ベースのブラウザは一般的に青いアウトラインを提供しますが、Safari は特定の配色では十分なコントラストを欠くリングを描画する場合があります。制作者は、デフォルトのインジケーターが閾値を満たしているかを確認するか、堅牢なカスタムスタイルを提供するべきです。
この達成基準は、すべてのインタラクティブかつフォーカス可能なコンポーネントに適用されます。リンク、ボタン、フォーム入力、セレクトメニュー、チェックボックス、ラジオボタン、ARIA ロールで構築されたカスタムウィジェットコンポーネント、そして tabindex によってフォーカス可能にされたあらゆる要素が対象です。また、疑似要素のみで CSS によって作成されたフォーカスインジケーターや、JavaScript によるクラス変更で制御されるフォーカスインジケーターにも適用されます。
なぜ重要か
フォーカスの可視性は、幅広いユーザーにとって重要なナビゲーションの手がかりです。フォーカスインジケーターが細い、コントラストが低い、あるいはまったく存在しない場合、これらのユーザーはページ内での空間的な位置感覚を失い、自分がどこにいるのか、次にどこへ行けるのかを把握できなくなります。
キーボードのみのユーザー — 震え、麻痺、反復性ストレス障害などの運動障害のある人を含め — は、ナビゲーションを完全にキーボードに依存しています。これらのユーザーにとって、見えない、あるいはかろうじて見える程度のフォーカスインジケーターは単なる不便ではなく、インターフェース全体を利用不能にします。世界保健機関によると、約 13 億人が何らかの障害を抱えており、その中でも運動障害はマウスを避ける、あるいは使用できない人々の最大カテゴリの1つです。
スクリーンリーダーをフルには使わず、拡大ソフトを利用するロービジョンのユーザーも、位置把握のためにフォーカスリングに依存しています。高いズームレベルでは、1px のデフォルトアウトラインはビューポートによって切り取られたり、似た色の背景に対して単に見えなくなったりすることがあります。これらのユーザーは、まさに高倍率ではマウスでの精密なターゲティングが難しいために、キーボードでナビゲーションすることがよくあります。
ADHD、不安障害、外傷性脳損傷などの認知・注意関連の障害は、ページ全体にわたる視覚情報を追跡することを難しくする場合があります。非常に目立ち、明確に区別されたフォーカスインジケーターは、ユーザーの現在位置に対する明白なアンカーを提供することで、ナビゲーションの認知負荷を軽減します。
状況的な障害も重要です。屋外で輝度を下げたノートPC画面でテストしている開発者や、加齢に伴うコントラスト感度の低下がある高齢ユーザーは、臨床的な診断がなくても、細いまたは低コントラストのフォーカスリングに苦労する可能性があります。
現実のシナリオを考えてみましょう。送金のためのオンラインフォームに 10 個の入力フィールドと 4 つのアクションボタンがある銀行のサイトがあります。パーキンソン病のあるユーザーがキーボードでフォームをタブ移動します。フォーカスインジケーターが、白い背景に薄いグレーの 1px 点線アウトラインのデフォルトである場合、そのユーザーは現在どのフィールドを編集しているのかを確実に追跡できません。受取人フィールドを通り過ぎてフォーカスが移動したことに気づかず、誤った口座に送金を送信してしまうかもしれません。堅牢で高コントラストのフォーカスアウトラインがあれば、これは完全に防げたはずです。
アクセシビリティを超えて、明確なフォーカスインジケーターはすべてのユーザーにとってユーザビリティの向上でもあります。フォームやメニューをキーボードで頻繁に操作するパワーユーザー — 開発者、データ入力担当者、スクリーンリーダーユーザーなどに一般的なパターン — は、素早く信頼できる位置把握の恩恵を受けます。また、間接的な SEO シグナルもあります。アクセシビリティの高いサイトは、直帰率が低くタスク完了率が高い傾向があり、どちらもポジティブなランキング要因と相関しています。
関連する Axe-core のルール
WCAG 2.4.13 には手動テストが必要です。なぜなら、自動ツールはあらゆるブラウザのレンダリングコンテキストにおいて、フォーカスインジケーターのサイズとコントラストを完全には評価できないからです。Axe-core には、2.4.13 の失敗を直接検出する単一の自動ルールはありません。その理由は技術的なものです。
- 自動化が不十分な理由: フォーカスインジケーターの正確なピクセル面積を算出するには、すべてのインタラクティブ要素に対してキーボードフォーカスをシミュレートし、レンダリングされたアウトラインの形状(ブラウザ、OS、ズームレベル、CSS に依存)を測定し、インジケーターのピクセルとその周囲のピクセルとのコントラスト比を計算し、これらのいずれも内包コンテンツのコントラスト要件に違反していないことを検証する必要があります。現在のどの自動アクセシビリティエンジンも、すべてのコンポーネントに対してこれらのステップを確実に実行できてはいません。Axe-core は(2.4.7 に関連して)フォーカススタイルがまったく存在しないことは検出できますが、存在するスタイルが 2.4.13 の面積とコントラストの閾値を満たしているかどうかを測定することはできません。
- フォーカス関連ルールによる部分的なカバー: Axe-core の
focus-visibleルールは、要素に可視のフォーカスインジケーターがあるかどうかをチェックします。要素にoutline: noneやoutline: 0が指定され、代替の視覚的インジケーターがない場合、このルールはそれを検出します。しかし、このルールに合格しても 2.4.13 準拠が保証されるわけではありません。技術的には可視なアウトラインがあっても、依然として細すぎたりコントラストが低すぎたりする可能性があります。 - 手動テストが決定的な方法: テスターは、フォーカス状態のすべてのインタラクティブコンポーネントを目視で確認し、アウトラインの寸法を測定または推定し、カラコントラストアナライザーを使ってコントラスト比を検証する必要があります。このため、WCAG は axe-core の観点から 2.4.13 を手動テスト専用の達成基準として位置づけています。
テスト方法
- 自動スキャン(部分的なシグナルのみ): ページに対して axe DevTools または Lighthouse を実行します。
focus-visibleやfocus-order-semanticsに関連する失敗がないか確認します。これらは 2.4.13 の違反を直接検出するわけではありませんが、フォーカススタイルが完全に抑制されている要素を表面化させる場合があります。これは前提となる失敗です。Chrome DevTools では、Accessibility パネルを開き、「Tab」インスペクションモードを使ってフォーカス可能な要素を順にたどります。 - 視覚的なキーボードナビゲーションテスト: マウスを切断するか脇に置きます。Tab キーを押して、ページ上のすべてのインタラクティブ要素を移動します。フォーカスされた各要素について、フォーカスインジケーターを目視で確認します。「明確に見えるリングまたは他のインジケーターがあるか」「少なくとも 2px の太さがあるように見えるか」「周囲の背景に対して強くコントラストしているか」を自問します。フォーカス位置の把握に迷ったり苦労したりする要素があればメモします。
- コントラストの測定: WebAIM Contrast Checker や Colour Contrast Analyser デスクトップツールを使用します。コンポーネントにフォーカスを当てた状態でスクリーンショットを撮ります。フォーカスインジケーターのピクセルの色と、そのすぐ隣接する背景の色をサンプリングします。コントラスト比が少なくとも 3:1 であることを確認します。
- 寸法の測定: ブラウザの DevTools(Chrome または Firefox)を使用します。フォーカスされた要素を選択し、その computed styles を確認します。
outline-width、outline-offset、フォーカスリングとして使用されているbox-shadowをチェックします。要素の周囲長(2 × 幅 + 2 × 高さ)に 2px を掛けて最小面積を算出します。インジケーターのレンダリングされた面積がこの値以上であることを確認します。 - スクリーンリーダー + キーボードテスト(NVDA + Firefox): Firefox でページを開き、NVDA を起動します。Tab キーと矢印キーでナビゲートします。視覚的なフォーカスインジケーターが NVDA の読み上げるフォーカスと同期して移動することを確認します。特に、JavaScript でフォーカス管理が行われるカルーセル、モーダル、アコーディオンなどのカスタムウィジェットに注意を払います。
- VoiceOver + Safari(macOS/iOS): Command + F5 で VoiceOver を有効にします。Tab キーでインタラクティブ要素をナビゲートします。VoiceOver カーソル(黒いアウトラインボックス)が適切な CSS フォーカスインジケーターの代わりになっていないことを確認します。ページ自体が独立してフォーカスインジケーターを提供しなければなりません。
- ハイコントラストモードでのテスト: Windows でハイコントラストモード(設定 → 簡単操作 → ハイコントラスト)を有効にします。ページを再読み込みし、キーボードナビゲーションテストを繰り返します。ハイコントラストモードでは、OS によって一部の CSS フォーカススタイルが上書きされます。可視のインジケーターが依然として表示されることを確認します。必要に応じて、CSS のメディアクエリ
forced-colors: activeを使用してスタイルを条件付きで調整します。
修正方法
ブラウザのデフォルトアウトラインを削除 — 不適切
<!-- 多くのスタイルシートはデフォルトのフォーカスアウトラインをグローバルに抑制している -->
<style>
* {
outline: none; /* サイト全体のすべてのフォーカスインジケーターを削除 */
}
a:focus, button:focus {
outline: 0; /* 冗長な削除。代替が提供されていない */
}
</style>
<button>Submit Payment</button>
ブラウザのデフォルトアウトラインを削除 — 適切
<!-- 優れたカスタムインジケーターを提供する場合にのみデフォルトを削除する -->
<style>
/* :focus-visible が適用されるときにのみデフォルトアウトラインを抑制し、強力な代替を提供する */
:focus-visible {
outline: 3px solid #0057b8; /* 3px により、典型的な要素で面積要件を満たせる */
outline-offset: 2px; /* オフセットにより、インジケーターを要素の縁から離し視認性を高める */
}
/* forced-colors(Windows ハイコントラスト)ではシステムキーワードを使用して尊重する */
@media (forced-colors: active) {
:focus-visible {
outline: 3px solid ButtonText;
}
}
</style>
<button>Submit Payment</button>
有色背景上の低コントラストなフォーカスリング — 不適切
<style>
.cta-button {
background-color: #0057b8;
color: #ffffff;
}
.cta-button:focus {
outline: 2px solid #3399ff; /* 濃い青の背景に薄い青のアウトライン: コントラスト比は約 1.4:1 — 不合格 */
}
</style>
<button class='cta-button'>Book Now</button>
有色背景上の低コントラストなフォーカスリング — 適切
<style>
.cta-button {
background-color: #0057b8;
color: #ffffff;
}
.cta-button:focus-visible {
/* 白いアウトラインは濃い青のボタンに対して強いコントラスト(約 8:1)を持つ */
outline: 3px solid #ffffff;
outline-offset: 2px;
/* 白いリングの背後に濃いオフセット box-shadow を置くことで、明るいページ背景に対してもコントラストを確保 */
box-shadow: 0 0 0 5px #0057b8;
}
</style>
<button class='cta-button'>Book Now</button>
フォーカススタイルのない div ベースのカスタムインタラクティブウィジェット — 不適切
<style>
.tab-item { cursor: pointer; padding: 12px 20px; }
/* カスタムタブに対して :focus や :focus-visible のスタイルが定義されていない */
</style>
<div role='tab' tabindex='0' class='tab-item'>Reservations</div>
フォーカススタイルのない div ベースのカスタムインタラクティブウィジェット — 適切
<style>
.tab-item {
cursor: pointer;
padding: 12px 20px;
border-radius: 4px;
}
/* 明示的な :focus-visible スタイル — 3px の outline-width とオフセットで面積要件を満たす */
.tab-item:focus-visible {
outline: 3px solid #d4550a; /* 白い背景に対して 3:1 以上のコントラスト */
outline-offset: 3px;
}
</style>
<div role='tab' tabindex='0' class='tab-item'>Reservations</div>
フォーカスインジケーターとしての細い box-shadow — 不適切
<style>
.form-input:focus {
outline: none;
/* 1px の box-shadow の広がり: 多くの入力サイズに対して面積が小さすぎる可能性が高い */
box-shadow: 0 0 0 1px #005fcc;
}
</style>
<input type='text' class='form-input' placeholder='Your email' />
フォーカスインジケーターとしての細い box-shadow — 適切
<style>
.form-input:focus-visible {
outline: none;
/*
3px の広がりは、典型的な幅 300px の入力の周囲に十分な面積を提供する。
白い背景に対する #005fcc のコントラストは約 5.9:1 — 2.4.13(3:1)と 1.4.3(4.5:1)の両方を満たす。
*/
box-shadow: 0 0 0 3px #005fcc;
}
</style>
<input type='text' class='form-input' placeholder='Your email' />
よくある間違い
- CSS リセットで
outline: noneを使用し、代替のフォーカスインジケーターを提供しないこと。多くの一般的な CSS リセット(古いバージョンの Normalize.css やカスタムリセットなど)はアウトラインを一括削除します。削除する場合は必ず、サイズとコントラスト要件を満たす:focus-visibleの代替スタイルとセットにしてください。 :focusにだけフォーカススタイルを提供し、:focus-visibleには提供しないために、ボタンをマウスクリックしたときにフォーカスリングが表示され、視覚的なマウスユーザーを苛立たせてしまうこと — その結果、開発者が正しい疑似クラスの使い分けをせずにフォーカススタイルを完全に削除してしまうことにつながります。- コンポーネントの背景色に近い色のフォーカスリングを選ぶこと。たとえば、白い背景
#ffffffに対して淡い青#99ccffのリングを使用すると、コントラスト比は約 1.5:1 となり、必要な 3:1 を大きく下回ります。 - アイコンボタンやチェックボックスなどの小さなコンポーネントに
outline-width: 1pxを使用すること。24×24px のアイコンの周囲に 1px のリングを描くと、その面積は約 96 平方ピクセルですが、24×24 の要素に必要な最小面積は (24+24+24+24) × 2 = 192 平方ピクセル、つまりちょうど 2px の太さです。1px のアウトラインはこの計算に不合格です。 role='combobox'、role='listbox'、role='slider'などのカスタム ARIA ウィジェットでフォーカスの見え方をテストし忘れること。これらのコンポーネントは、ネイティブの CSS 疑似クラスを明示的に扱わない限り、JavaScript 管理のフォーカスによってそれらをバイパスしてしまうことがよくあります。aやbuttonタグにだけフォーカススタイルを適用し、input、select、textarea、およびtabindex='0'を持つあらゆる要素を無視すること。- コンポーネントライブラリやサードパーティウィジェットの深い階層でフォーカススタイルを上書きし、その上書きによって可視インジケーターが削除されていることに気づかないこと。よくある原因として、Bootstrap 4 のような UI キット(微妙な光彩の
box-shadowを設定する)があり、これが 2.4.13 の閾値を満たさない場合があります。 - Windows のハイコントラストモードでフォーカスの見え方をテストしないこと。一部の CSS の outline や box-shadow のテクニックは、ハイコントラストモードでは見えなくなります。
@media (forced-colors: active)ブロックを使用して、システムカラーに基づく可視のフォールバックを確保してください。 - 非常に大きな負の値の
outline-offsetを使用して、アウトラインを要素のボーダー内側に移動すること。これにより、インジケーターが要素の背景と重なり、実効的なコントラストが 3:1 を下回ることがあります。 - 親コンテナのフォーカスインジケーターだけで子のインタラクティブ要素にも十分だと想定すること。各フォーカス可能要素は独立して達成基準を満たさなければなりません。表の行がハイライトされていても、その行内のリンクセルに対する要件を満たしたことにはなりません。
トルコのアクセシビリティ規制との関係
2025年6月21日付官報第 32933 号で公布されたトルコ大統領通達 2025/10 は、トルコで事業を行う幅広い主体に対して、ウェブおよびモバイルのアクセシビリティ要件を法的に定めています。この通達は WCAG 2.2 を技術的な参照標準として採用し、対象主体に対してレベルAAでの適合を義務づけています。WCAG 2.4.13 Focus Appearance はレベルAAAの達成基準であるため、標準的なコンプライアンスにおいて通達によって直接義務づけられているわけではありません。
しかし、この通達の適用範囲は非常に広範です。対象主体には、公的機関や政府機関、銀行や金融サービス提供者、病院や医療機関、20万件以上の加入者を持つ通信事業者、eコマースプラットフォーム、旅行代理店、民間輸送会社、そして国民教育省(MoNE)に認可された私立学校が含まれます。これらすべての組織にとって、2.4.13 を含む該当する達成基準でレベルAAAの適合を示すことは、法的な最低ラインを超えた最高水準のアクセシビリティへのコミットメントを示すものです。
トルコの対象主体が 2.4.13 を自主的に実装することには、実務的および評判上の理由があります。特に銀行や金融サービス提供者は、キーボードナビゲーションに依存して安全な取引を行う運動障害のある顧客にサービスを提供しています。2.4.13 を満たすトルコの銀行のオンラインバンキングポータルは、規制要件を上回るだけでなく、ユーザーの誤操作リスクを低減し、企業の社会的責任を示すことにもなります。同様に、患者が予約を行ったり医療記録にアクセスしたりする病院や医療ポータルは、細かな運動制御や視力が低下した高齢者を含むすべてのユーザーが、自信を持ってインターフェースをナビゲートできるようにすべきです。
大規模な加入者基盤を持つ通信事業者は、トルコで最もトラフィックの多いデジタルサービスの一部です。彼らのカスタマーポータルやセルフサービスアプリケーションは、何百万人ものユーザーに利用されており、その中には高齢者や障害のあるユーザーも相当数含まれます。これらのプラットフォーム全体で 2.4.13 を自主的に実装することは、すべての加入者に公平なアクセスを保証し、AAA 達成基準への義務が将来的に拡大されるような規制強化があった場合にも有利な立場を確保します。
調達要件、欧州アクセシビリティ法の対象となるEU市場への輸出、あるいは社内のアクセシビリティポリシーなどを動機として、WCAG 2.2 AAA への完全な適合を目指す組織にとって、2.4.13 の実装は不可欠な要素です。Accsible のオーバーレイ SDK は、制作者レベルの CSS 修正を補完しつつ、インターフェース全体に強力で準拠したフォーカスインジケーターを提供できる、設定可能なフォーカス強調機能を備えています。
