WCAG 2.2の達成基準2.4.11「フォーカスが隠れない（最低限）」は、キーボードフォーカスを受け取った操作要素が、制作者の配置したコンテンツによって完全に隠れないことを求めるLevel AAの基準です。
キーボードフォーカスとは、Tabキーなどでページ内を移動したときに、次の操作対象として選ばれているリンク、ボタン、入力欄などの状態を指します。
マウスを使わない利用者は、フォーカスされた要素とその表示を手がかりに現在位置を判断するため、固定ヘッダーや通知バナーの裏に操作対象が隠れると、操作を続けにくくなります。
フォーカスの基本から確認したい場合は、キーボード操作とフォーカス表示の実務解説も参照してください。
達成基準2.4.11が求める状態
判定の中心は、キーボードフォーカスを受け取ったユーザーインターフェース要素が、制作者の用意した別のコンテンツによって完全に隠れていないかどうかです。
ここでいう制作者のコンテンツには、画面に追従するヘッダーやフッター、Cookie同意バナー、開いたまま残るチャット画面、ポップアップなどが含まれます。
| 確認する基準 | 求められる状態 |
|---|---|
| 2.4.11（Level AA） | フォーカスされた要素が完全には隠れておらず、少なくとも一部を視認できる。 |
| 2.4.12（Level AAA） | フォーカスされた要素のどの部分も、制作者のコンテンツに隠されない。 |
| 2.4.7（Level AA） | キーボードフォーカスを示す表示を視認できる。 |
2.4.11では一部が見えていれば直ちに不適合とはなりませんが、「見える部分がわずかでもよい」という設計目標を示すものではありません。
フォーカスされた要素の全体をできるだけ見せ、隠れる頻度を減らすほうが、利用者は現在位置を把握しやすくなります。
WCAG 2.2で追加された達成基準の全体像を把握すると、2.4.11と関連基準の役割を整理できます。
二つの注記をどう読むか
- 利用者が位置を変えられるコンテンツ：適合性を確認するときは、利用者が動かす前の初期位置を対象にします。
- 利用者が開いたコンテンツ：フォーカス対象を一時的に覆っても、キーボードフォーカスを次へ進めずに対象を再表示できるなら、完全に隠れたものとは扱いません。
二つ目の注記は「キーボード操作をしてはいけない」という意味ではありません。
判定のポイントは、覆っているコンテンツを閉じるなどして、フォーカスを別の要素へ移さずに元の対象を再表示できることです。
フォーカスが隠れる代表的な場面
固定ヘッダーと固定フッター
画面の上端や下端に固定した領域は、TabキーやShiftキーとTabキーで移動した先のリンクや入力欄を覆うことがあります。
ブラウザが対象までスクロールしていても、固定領域の裏に要素全体が入れば、利用者には移動が起きなかったように見えます。
通知バナーと開いたままのパネル
Cookie同意バナー、通知、チャット画面などがページ上に残る設計では、背後にある操作要素を完全に覆う可能性があります。
表示領域を押し縮めて本文を再配置する、操作が終わったら閉じる、重ならない位置に表示するといった設計で、フォーカス対象との重なりを避けます。
モーダルとポップアップ
モーダルを開いたのにフォーカスが背後のページへ移動できる状態では、見えない要素を操作してしまうおそれがあります。
モーダルを開いたら内部へフォーカスを移し、閉じるまで背後へ移動させず、閉じたら起点へ戻す設計が必要です。
実装の詳しい考え方は、アクセシブルなモーダルダイアログの設計ガイドで確認できます。
実装方法
重なりを生まないレイアウトを優先する
最初に検討したいのは、フォーカスのたびにスクロール位置を補正することではなく、操作要素と固定コンテンツが重ならないレイアウトです。
- 通知やパネルを重ねず、本文を押し下げる。
- 画面幅に応じて本文を再配置し、パネル用の領域を確保する。
- 閉じられるコンテンツには、キーボードで操作できる明確な閉じる手段を用意する。
- モーダルを開いている間は、フォーカスをモーダル内で管理する。
レイアウトで重なりを解消できれば、個々の操作要素へ複雑な補正処理を加えずに済みます。
固定ヘッダーにはscroll-paddingを使う
scroll-padding-topは、スクロール領域の上側に確保したい余白をブラウザへ伝えるCSSプロパティです。
固定ヘッダーの高さと値をそろえると、フォーカス対象へスクロールしたときに、対象がヘッダーの裏へ入りにくくなります。
:root {
--sticky-header-height: 60px;
}
html {
scroll-padding-top: var(--sticky-header-height);
}
.site-header {
position: sticky;
top: 0;
height: var(--sticky-header-height);
}ヘッダーの高さが画面幅によって変わる場合は、各表示条件に合わせて値も更新します。
設定後は、ページ内リンクによる移動だけでなく、TabキーとShiftキーとTabキーの両方向で確認してください。
JavaScriptによる補正は対象を限定する
元の実装例のように、すべてのリンク、ボタン、入力欄でscrollIntoView()を呼ぶと、フォーカスが移るたびに画面が動き、かえって現在位置を追いにくくなる場合があります。
まずレイアウトとCSSで解決し、動的なパネルなど特定の部品で問題が残る場合に限って、その部品の表示条件と重なりを確認してスクロール処理を加えます。
処理を加えた後は、キーボード操作の順序、スクロール量、拡大表示時の挙動を実際の画面で再確認します。
手動テストの手順
- デスクトップ幅だけでなく、狭い画面や拡大表示など、固定領域の大きさが変わる条件を用意します。
- 通知バナー、チャット画面、メニューなど、操作中に残るコンテンツを表示します。
- ページの先頭からTabキーで進み、末尾側からはShiftキーとTabキーで戻ります。
- フォーカスされたリンク、ボタン、入力欄などが、別のコンテンツで完全に隠れていないか確認します。
- 要素の一部が見えていても、フォーカスを示す枠線や背景変化を視認できるか、2.4.7の観点で別に確認します。
- 利用者が開いたコンテンツに覆われた場合は、フォーカスを次へ進めずに元の対象を再表示できるか確認します。
自動検査ツールは関連する実装上の問題を見つける補助になりますが、固定領域との重なりや画面条件ごとの見え方をすべて判定できるとは限りません。
この達成基準は視覚的な遮蔽を扱うため、キーボードによる目視確認を中心にし、スクリーンリーダーではモーダルを開閉した際のフォーカス移動など、関連する挙動を確認します。
実装とレビューの要点
- 2.4.11の最低条件は「完全に隠れないこと」であり、可能な限り全体を見せる設計を目指す。
- 固定ヘッダーや通知の重なりは、レイアウトと
scroll-paddingで先に解消する。 - JavaScriptによるスクロール補正は、問題が再現する部品に限定する。
- 自動検査だけに頼らず、TabキーとShiftキーとTabキーで往復して確認する。
- フォーカス対象の遮蔽とフォーカス表示の視認性を分けて判定する。
参考資料
当社では、Webアクセシビリティの導入と改善を支援するUUU ウェブアクセシビリティを提供しています。
キーボード操作やフォーカス表示を含むサイト全体の改善に関心がある方は、サービスの詳細をご覧ください。