WCAG 2.2の達成基準2.4.12「フォーカスが隠れない（強化）」は、キーボードで操作している要素が、固定ヘッダーや通知バナーなどの作成者が配置したコンテンツに少しでも隠れないことを求めるLevel AAAの基準です。
現在どの要素を操作しているかを目で追える状態に保つため、実装ではスクロール位置だけでなく、重なって表示される部品の設計も確認します。
達成基準2.4.12が求めること
キーボードフォーカスとは、Tabキーなどで選ばれ、次のキー操作を受け取る状態です。
リンク、ボタン、入力欄などは、フォーカスを受け取るユーザーインターフェースコンポーネントに当たります。
W3Cの達成基準2.4.12は、コンポーネントがキーボードフォーカスを受け取ったとき、そのどの部分も作成者が配置したコンテンツに隠れないことを求めています。
| 達成基準 | 適合レベル | フォーカス対象に求められる状態 |
|---|---|---|
| 2.4.11 フォーカスが隠れない（最低限） | AA | コンポーネント全体が隠れていない |
| 2.4.12 フォーカスが隠れない（強化） | AAA | コンポーネントの一部も隠れていない |
2.4.12は、ページ上の要素を常に表示し続ける基準ではありません。
判定するのは、その要素がキーボードフォーカスを受け取った時点です。
判定対象を取り違えない
作成者が配置したコンテンツには、固定ヘッダー、固定フッター、Cookie同意バナー、通知、非モーダルダイアログなど、ページやアプリ側が表示する重なりが含まれます。
ブラウザー自身のメニューや通知など、ページの作成者が制御していない表示は、この達成基準の判定対象ではありません。
また、2.4.12が直接判定するのはフォーカスを受け取ったコンポーネントです。
コンポーネントの外側に描画されるフォーカスインジケーターは別に確認する必要があるため、2.4.7「フォーカスの可視性」と併せて試験します。
固定要素でフォーカスを隠さない実装
スクロール領域に余白を確保する
固定ヘッダーや固定フッターがあるページでは、CSSのscroll-paddingでスクロール領域の上端と下端に余白を設けられます。
次の例は、上部に60pxの固定ヘッダー、下部に20pxの固定領域がある場合の基本形です。
html {
scroll-padding-top: calc(60px + 1rem);
scroll-padding-bottom: calc(20px + 1rem);
}
固定領域の高さだけでなく、フォーカスの輪郭を確認できる余白も加えています。
実際の値は、ヘッダーやフッターの表示上の高さに合わせ、画面幅や文字拡大で高さが変わる状態も試験します。
scroll-paddingはW3Cが示す十分な達成方法の一つですが、採用すれば無条件に適合するわけではありません。
W3CのCSS Technique C43と同様に、最後は各フォーカス対象が実際に隠れないことを確認します。
通知バナーとダイアログの重なりを設計する
Cookie同意バナーや通知を画面に固定する場合は、背後の操作要素を覆わない配置にするか、バナーの高さをスクロール余白へ反映します。
操作を終えるまで背後を使わせないダイアログであれば、フォーカスをダイアログ内に移し、キーボードで閉じられるモーダルとして設計します。
見た目だけをモーダル風にして背後へフォーカスが移動すると、隠れた要素を操作する状態が残ります。
JavaScriptによるスクロールは必要な範囲に絞る
ページ内のすべてのリンクや入力欄を、フォーカスのたびに画面中央へ移動させる実装は避けます。
大きな位置移動が繰り返されるうえ、独自コンポーネントなどを対象から漏らす可能性があるためです。
CSSとレイアウトで解決できない可変の重なりに限り、実際に隠れた対象を最小限スクロールさせる方法を検討します。
よくある失敗と修正方針
| 状態 | 問題 | 修正方針 |
|---|---|---|
| 固定ヘッダー | Tab移動したリンクの上部がヘッダーの背後に入る | 上端のscroll-paddingを実際の高さに合わせる |
| 固定フッター | 画面下部のボタンが一部隠れる | 下端の余白を確保するか、狭い画面では固定を解除する |
| Cookie同意バナー | 背後の入力欄へフォーカスが移り、バナーに覆われる | 重ならない配置にするか、適切なモーダルとしてフォーカスを管理する |
| ポップアップ | 表示中のポップアップが現在の操作対象を覆う | 重なりを避け、表示とフォーカスの移動順を見直す |
キーボードによるテスト手順
- 固定ヘッダー、固定フッター、通知、Cookie同意バナーなど、重なる可能性がある要素を表示します。
- Tabキーでリンク、ボタン、入力欄、独自コンポーネントを順に移動します。
- ShiftキーとTabキーで逆方向にも移動します。
- フォーカスを受け取ったコンポーネントの一部が、作成者が配置したコンテンツの背後に入っていないか目視します。
- フォーカスインジケーターも見えること、操作順が自然であることを別の確認項目として試験します。
- 画面幅を変えた状態や文字を拡大した状態でも同じ操作を繰り返します。
キーボード操作全体の確認方法は、キーボード操作とフォーカス表示の実務解説も参照してください。
自動ツールとスクリーンリーダーの役割
自動チェックツールは関連する実装上の問題を探す補助になりますが、画面サイズやバナーの状態ごとの視覚的な重なりを一括して判定する手段にはなりません。
スクリーンリーダーによる確認は、読み上げ内容やフォーカス順の検証に役立ちますが、コンポーネントが画面上で隠れていないかは目視で確認します。
確認の要点
- Level AAAでは、フォーカスを受け取ったコンポーネントの一部も隠さない。
- Level AAの2.4.11と、Level AAAの2.4.12を混同しない。
- 固定要素の高さを
scroll-paddingへ反映し、実際の画面で確認する。 - 通知やダイアログでは、表示の重なりとフォーカス管理を一緒に設計する。
- 自動ツールだけで完了せず、キーボード操作と目視で試験する。
達成基準の背景や具体例は、W3CのUnderstanding SC 2.4.12でも確認できます。
当社では、ウェブアクセシビリティの導入と改善を支援するUUU ウェブアクセシビリティを提供しています。
サイトの操作上の課題を確認したい場合は、サービスの詳細をご覧ください。