WCAG 2.2 の新達成基準「隠されないフォーカス」
W3C が勧告している WCAG (Web Content Accessibility Guidelines) 2.2 (日本語訳) では、「隠されないフォーカス (Focus Not Obscured)」という達成基準が新たに追加されています。
ユーザインタフェース コンポーネントがキーボードフォーカスを受け取るとき、コンテンツ制作者が作成したコンテンツによって、そのコンポーネントの全体が隠されるようなことがない。
出典 : WCAG 2.2 達成基準 2.4.11「隠されないフォーカス (最低限)」(レベル AA)
ユーザインタフェース コンポーネントがキーボードフォーカスを受け取るとき、コンテンツ制作者が作成したコンテンツによって、そのコンポーネントのどの部分も隠されることがない。
出典 : WCAG 2.2 達成基準 2.4.12「隠されないフォーカス (高度)」(レベル AAA)
この達成基準は、キーボード操作によってフォーカスを受け取ることができる UI コンポーネント (例 : リンク、フォーム入力要素、ボタン) にフォーカスが当たったとき、「フォーカスが当たっている」ことが隠されることなく視認できることを求めています。
スティッキーヘッダーや Cookie バナー、オーバーレイ広告、通知など、メインコンテンツに重なる別のコンテンツがある場合、ユーザーが Tab (あるいは Shift + Tab) キーでフォーカスを順次移動させるうちに、フォーカス箇所がその重なりの下に隠れてしまうことがあります。そうなると、ユーザー (ここでは主に、目は見えるものの、障害などによってマウスを使うことができず、キーボード操作またはそれに準じるスイッチコントロールや音声入力などに依存している人) が操作可能な対象を見失ってしまう恐れがあるため、その防止策として、この達成基準が規定されています。
「最低限」をどう解釈するか
この「隠されないフォーカス」には、上記の引用の通り、適合レベルが異なる二つの達成基準があります。「最低限」(レベル AA) ではフォーカスされているコンポーネントが部分的にでも視認できればよく、「高度」(レベル AAA) ではフォーカスされているコンポーネントの全体が視認できなければならない、という違いがあります。
ここで気を付けなければならないのは、「最低限」で求められている「部分的」というのは、「(キーボードフォーカスを受け取ることができる) コンポーネント」そのものの一部分であるということです。たとえば、フォーカスされたコンポーネント自体は隠れて見えないもののフォーカスインジケーターだけは見えるという場合、たとえそれがフォーカス箇所を認知する手がかりとして実質的に機能するとしても、この「最低限」の達成基準は満たさないということになります (フォーカスインジケーターをコンポーネントと分離して見やすくするために CSS で outline-offset を設定していたりすると、このようなケースに該当しやすいかもしれません)。このあたりは Adrian Roselli 氏のブログ記事「2.4.11: Adversarial Conformance」を見ると、デモがあるので具体的にイメージしやすいと思います。
ところで、この「最低限」の要件を満たすだけでは、結局のところ、フォーカスされているコンポーネントが一体何であるか、ユーザーが理解できない可能性があります。WCAG において「最低限」が許容されているのは、フォーカス箇所が一部分でも視認できれば、あとはユーザー自身が (Tab キーや上下矢印キーを用いて) 画面をスクロールすることで、フォーカスされているコンポーネントの全容を見ることが一応は可能だからなのでしょう。本来そのひと手間をユーザーにかけさせるのはユーザー体験としてスマートではないので、基本的には「高度」の要件を満たすようにしたいものです。
達成基準のテストと満たすためのテクニック
この「隠されないフォーカス」の達成基準を満たしているかどうかをテストするには、ウェブページ上で Tab キー (および Shift + Tab キー) を用いてフォーカスを順次移動させながら、フォーカスを受け取ることができるすべての UI コンポーネントにおいて、「フォーカスが当たっている」ことが視認できるかを目視で確認します。ビューポートの下部に重なるもの (例 : Cookie バナー) があれば、Tab キーでフォーカスを下方に移動させるうちにフォーカス箇所が隠れてしまうかもしれませんし、ビューポートの上部に重なるもの (例 : スティッキーヘッダー) があれば、Shift + Tab キーでフォーカスを上方に移動させるうちにフォーカス箇所が隠れてしまうかもしれません。レスポンシブデザインを採用しているウェブサイトの場合は、ページレイアウトが変わるブレークポイント (あるいは代表的なデバイス種別の画面サイズ) ごとにテストするのがよいでしょう。
この達成基準を満たすためのテクニックとして代表的なのは、CSS の scroll-padding を実装することです。重なるもの (スティッキーヘッダーなど) のサイズ (高さなど) を超えるパディング値を設定しておくことで、フォーカス箇所が隠れてしまうことを防ぐことができます。Cookie バナーのように、表示されているときとされていないときがあり、それぞれに対して異なる scroll-padding の値を適用したい場合は、:has() セレクタを用いるなどで対応することもできます。このあたりは TetraLogical の記事「Sticky content: focus in view」を見ると、デモがあるので具体的にイメージしやすいと思います。
なお、scroll-padding の値は、ユーザーがブラウザの画面表示をズームしたり文字サイズを変更する可能性を考慮に入れて、em や rem といった相対値を用いるのがよいでしょう。達成基準 1.4.4 テキストのサイズ変更 (レベル AA) の考えかたに基づいて、200%までズームしてもフォーカス箇所が隠れないようにするのがよいのかなと個人的には思います。
ところで、scroll-padding を用いてもフォーカス箇所が隠れてしまう問題をうまく解決できないこともあるかもしれません (たとえば、メインコンテンツに覆いかぶさるような広告など)。その場合は、当該コンテンツ (広告) そのものの提示を見直したいところです。
他の達成基準が適用されるケース
メインコンテンツに重なるコンテンツがある場合でも、それが半透明なデザインになっていて、フォーカス箇所が覆われているものの透けて見えるようなケースがあるかもしれません。その場合は、この「隠されないフォーカス」の達成基準には抵触しないとみなされます。ただし、達成基準 1.4.11 非テキストのコントラスト (レベル AA) および 達成基準 2.4.13 フォーカスの外観 (レベル AAA) には抵触する可能性があるので、別途その観点で検証する必要があります。
また、メインコンテンツに重なるコンテンツによってフォーカス箇所が隠れてしまうケースであっても、別の達成基準に基づいて検証するのが適切なケースもあります。たとえば、モーダルウィンドウを開いているときに、キーボード操作によるフォーカス移動がモーダルウィンドウ内にとどまらず、非アクティブであるはずの背景側にフォーカスが移動してしまうようなケースです。この場合、そもそもフォーカスの制御が適切に実装できていないことが問題であると言えるので、達成基準 2.4.3 フォーカス順序 (レベル A) の観点で検証するのが妥当でしょう。
WCAG 2.2 が勧告されて1年以上が経ち、私自身も実際の案件で WCAG 2.2 に基づいたウェブアクセシビリティ診断をさせていただくことが増えていますが、この「隠されないフォーカス」の達成基準を誤解なく適用するには (ほとんどの方にはまだ馴染が薄いこともあり) 上述のように留意点がいろいろあるなというのが実感です。この記事が、WCAG 2.2 をスコープに入れる形でアクセシビリティ向上に取り組むチームにとって、ご参考になれば幸いです。