ページをキーボードで操作していると、Tabキーを押したのに、次に選ばれたリンクやボタンが見当たらないことがあります。画面の上に固定されたヘッダーや、下から重なる通知の裏へ、操作対象が入り込んでいるかもしれません。画面上の位置が分からなくなると、次のキーで何を操作するのかも確かめにくくなります。
この問題を扱うのが、ウェブのアクセシビリティ指針WCAG 2.2の「Focus Not Obscured」、フォーカスを隠さないための達成基準です。最小条件では、対象の一部が見えている状態を認めています。ただし、それだけで操作対象も、その周囲の目印も十分に見えるとは限りません。何を見て判断する条件なのかを、固定フッターの例から整理します。［1、2］
簡単にまとめると？
- WCAG 2.2の2.4.11は、キーボードフォーカスを受け取った部品が、制作者のコンテンツで完全に隠れないことを求めます。一部分の遮蔽も認めない2.4.12とは条件が異なります。
- 判断する中心はリンクやボタンなどの部品本体です。外側のフォーカス枠が見えるかどうかは、別の達成基準も合わせて確認します。
- 重なる領域を確保する、内容を押し下げる、開いたパネルを適切に閉じるなど、表示の重なりとキーボード操作を一緒に設計する必要があります。
フォーカスは、次に操作する場所を示す
キーボードフォーカスとは、キー入力や操作の対象になっている場所です。たとえばリンクにフォーカスがあるときには、通常Enterキーでそのリンクを開けます。マウスのポインターを動かさずにページを進む人にとって、現在のフォーカスが見えることは、操作を続ける手がかりになります。
多くの画面では、ボタンやリンクの周囲に枠を出す、背景を変えるなどしてフォーカスを示します。ところが、フォーカスそのものが移っていても、対象が別の表示の裏に隠れていれば、その変化は見えません。「キーを押しても反応しない」と感じたり、見えていない対象を操作してしまったりする原因になります。W3Cの解説は、キーボードだけでなく、その操作方式を利用するスイッチや音声入力などの利用者にも関わる問題として説明しています。［2］
特に起こりやすいのが、画面端に残り続ける固定ヘッダーやフッター、上に重なる非モーダルのパネルです。ページの内容がスクロールしても固定領域は動かないため、本文中のリンクがそこへ入り込むと、表示上は別の層に覆われます。フォーカスの移動順が正しくても、重なり方まで正しいとは限らないのです。
「全部隠れない」と「一部も隠れない」を分ける
WCAG 2.2の達成基準2.4.11「Focus Not Obscured (Minimum)」はレベルAAの条件です。キーボードフォーカスを受け取ったユーザーインターフェース部品が、制作者の作ったコンテンツによって完全には隠れないことを求めています。ここでいう部品は、利用者が一つの機能を持つ操作対象として受け取るものです。HTMLの要素一つと、必ずしも一対一にはなりません。［1、2］
一方、2.4.12「Focus Not Obscured (Enhanced)」はレベルAAAの条件で、部品のどの部分も隠れないことを求めます。AAの最小条件とAAAの強化条件は、同じ判定を別名で呼んだものではありません。なお、一つの達成基準を満たすことと、ページ全体がWCAGのAAやAAAに適合することも別です。
たとえば、高さ300の表示領域の下80を、不透明な固定フッターが覆うと考えます。上端を0とすると、フッターは220から300の範囲です。同じ高さ40のボタンでも、上下の位置によって次のように見え方が変わります。単位や値は説明用で、実際のブラウザーの自動スクロールを測ったものではありません。
| ボタンの範囲 | 見える高さ | この重なり方だけの判定 |
|---|---|---|
| 240〜280 | 0／40 | 全部隠れるため、2.4.11の最小条件を満たさない |
| 200〜240 | 20／40 | 一部が見えるため2.4.11の最小条件は満たすが、2.4.12は満たさない |
| 160〜200 | 40／40 | このフッターによる遮蔽はなく、両基準の遮蔽条件を満たす |
一部が見えるケースでは、残った部分だけでボタンの内容が読めるかどうかは、文字の位置や大きさにもよります。したがって、2.4.11の最低条件を満たしたからといって、その見え方を設計上の目標にする必要はありません。W3Cの解説も、部分的に隠れる程度と頻度を減らし、できるだけ全体が見えるようにすることを勧めています。［2］
ボタン本体と、外側のフォーカス枠は別に見る
2.4.11で評価するのは、基本的にフォーカスを受け取った部品本体です。その外側に描かれたフォーカス枠は、部品が完全に隠れているかを判断するときの本体には含めません。枠が部品の内側にある場合や、本体の見た目の変化でフォーカスを示す場合は、その表示も本体の一部になります。［2］
この区別が必要なのは、「ボタンは見えるが、フォーカスの目印が分からない」という状態があるためです。部品の一部が見えていて2.4.11を満たしても、外側の枠が完全に覆われれば、フォーカス表示の可視性を扱う2.4.7「Focus Visible」の問題が残り得ます。また、半透明の幕で本体が透けて見える場合も、色の差が弱まり、非テキストのコントラストを扱う1.4.11の条件を満たさないことがあります。［1、2］
確認するときは、「対象そのものがどこにあるか」と「今そこを操作していると分かるか」を続けて見ます。前者だけ、あるいは目立つ枠の色だけを点検しても、もう一方の問題は見落とせます。
自動で現れる通知と、自分で開いたパネル
重なる内容がどのように現れたかも、条件を読むうえで重要です。ページ側が初めから置いた固定フッターや、利用者の直接の操作なしに現れた通知は、フォーカスを受け取った部品を完全に隠してはいけません。「スクロールすれば見えるはず」と考えるだけでは、利用者が開いた内容に関する次の扱いを適用できません。
2.4.11の注記では、利用者が開いた内容について、フォーカスを先へ進めずに対象を再び表示できるなら、制作者のコンテンツで視覚的に隠れた状態とは扱わないと説明しています。たとえば自分で開いたチャットパネルがリンクを覆ったとき、フォーカスをそのリンクに残したままEscapeキーでパネルを閉じられる仕組みです。閉じるボタンを探すために別の部品へフォーカスを移さなければならない状態とは、条件が違います。［1、2］
また、利用者がツールパネルなどを自由に動かせる画面では、可動コンテンツの初期位置を評価するという注記があります。これは、利用者によるどの配置でも絶対に重ならないよう保証する条件とは異なります。ただし、初期位置から操作対象を覆ってよいという意味ではありません。
重ねる前に、表示領域と操作の戻り方を決める
修正の考え方は、上にかぶさるものをすべて消すことだけではありません。固定領域のぶんを見越してスクロール後の位置を調整する、パネルを開いたら本文を押し下げる、横の領域を確保して本文を折り返す、といった方法があります。W3Cの解説はCSSのscroll-paddingも対応方法の一つとして挙げていますが、どのスクロール領域に何が重なるかを確かめて使う必要があります。［2］
画面の手前で操作を完結させるモーダルダイアログにも、別の条件があります。表示したときにフォーカスをその中へ移し、閉じるまでは背後の操作対象へ進まない、適切なモーダルの動作なら、背後に見えないフォーカスが残る問題を避けられます。見た目だけをダイアログ風にして、フォーカスが背後へ抜ける実装では同じ効果になりません。常にモーダルへ変えるのが最善とも限らないため、通知の必要性と操作の流れを合わせて選びます。
実際の点検では、ヘッダーやフッターを表示したまま、Tabキーで進み、Shift＋Tabキーでも戻ってみます。狭い画面、文字を大きくした状態、開いたパネルがある状態でも、操作対象とフォーカスの表示を追えるか確かめます。固定領域の高さや本文の折り返しが変わるため、通常の幅で一度見えただけでは足りません。これは動作を探るための点検例で、WCAG全体の適合評価を置き換えるものではありません。
フォーカスを隠さない設計は、枠を描く処理に加えて、その枠と操作対象をどこへ表示するかまで扱います。固定表示の便利さを保ちながら、利用者が今どこを操作しているのかを見失わずに済む。その関係を、表示の重なりとキーボードの動きの両方から整えていきます。
参考資料
- W3C — Web Content Accessibility Guidelines (WCAG) 2.2。W3C Recommendation、2024年12月12日固定版。達成基準2.4.11、2.4.12、2.4.7、1.4.11、適合要件5.2.1を参照。達成基準の要件と説明用の注記を区別して使用。
- W3C WAI — Understanding Success Criterion 2.4.11: Focus Not Obscured (Minimum)。2026年6月15日更新、2026年10月16日取得版。規定を補足する解説文書。部品とフォーカス表示、利用者が開いた内容、モーダルダイアログ等の説明を参照。
出典：W3C / World Wide Web Consortium。原資料の著作権表示は各文書を参照。図1と位置の比較表は、上記の条件を説明するために作成した例です。