キーボード操作とフォーカス表示をどう整えるか｜見えにくい使いにくさを減らすWebアクセシビリティ実務

Webアクセシビリティの改善というと、どうしても「見た目で気づきやすい問題」に意識が向きがちです。けれど実際には、ぱっと見では問題がわかりにくいのに、利用者にとっては大きな負担になっている箇所があります。その代表が、キーボード操作とフォーカス表示です。マウスで触っている限りは自然に使えるように見えるページでも、キーボードだけで操作しようとすると、メニューに入れない、ボタンまでたどり着けない、今どこにいるのかわからない、といった不便が一気に表面化します。第4回では、こうした“見えにくい使いにくさ”に焦点を当てながら、WCAG 2.2の考え方と実務での整え方を、できるだけ具体的に整理してまいります。

この記事でわかること

• キーボード操作が重要になる理由
• フォーカス表示が見えないと何が起こるのか
• WCAG 2.2で押さえたいフォーカス関連の達成基準
• 実務で起きやすい問題と改善の方向
• UUUウェブアクセシビリティサービスとの役割分担の考え方

まず前提として、キーボード操作が必要なのは、パソコン利用者の一部だけではありません。マウスが使いにくい方、手指の細かな操作が難しい方、支援技術を利用している方、ショートカットを活用して効率よく操作したい方など、さまざまな利用者がキーボードによる移動に依存しています。また、ノートパソコンで外出先からアクセスしているときや、一時的に片手操作になっているときなど、特別な支援環境でなくてもキーボード操作のしやすさが重要になる場面は少なくありません。つまり、キーボードで操作できることは一部の利用者だけの要件ではなく、Webの基本的な操作性に関わる品質なのです。

ここでいうキーボード操作とは、主にTabキーやShift＋Tabで移動し、EnterキーやSpaceキーで実行し、必要に応じて矢印キーなども使いながらページ内を進んでいけることを指します。利用者は、リンク、ボタン、フォーム、メニュー、モーダル、タブ、アコーディオンといった要素を、マウスを使わずに順にたどれる必要があります。ところが実務では、見た目を優先した独自UIやJavaScriptの実装によって、この基本が崩れてしまうことがよくあります。たとえば、見た目はボタンなのに実際はクリックイベントだけが付いたdiv要素で、キーボードでは反応しない。開閉メニューがマウスホバー前提で、Tab移動では中の項目に入れない。モーダルを開いたあと、フォーカスが適切な位置へ移動せず、背景側へ抜けてしまう。このような状態は、利用者にとって“使えないページ”に近いものになってしまいます。

キーボード操作と並んで重要なのが、フォーカス表示です。フォーカスとは、いまキーボード操作の対象になっている要素のことです。マウス操作ではカーソル位置を目で追えますが、キーボード操作では「現在どこにいるのか」をフォーカス表示が教えてくれます。そのため、リンクやボタンに移動したとき、枠線や背景色の変化、下線、影などによって現在位置が明確にわかることが欠かせません。もしフォーカス表示がなかったり、非常に薄かったり、背景に埋もれて見えにくかったりすると、利用者は今どの項目を操作しようとしているのか把握できなくなります。これは単なる見た目の問題ではなく、操作の成立そのものに関わる問題です。

WCAG 2.2では、このフォーカスに関する要件が従来よりも強化されています。特に実務で意識したいのは、2.4.11「Focus Not Obscured (Minimum)」、2.4.12「Focus Not Obscured (Enhanced)」、2.4.13「Focus Appearance」です。これらは、キーボードで移動したときにフォーカスされた要素が隠れないこと、そしてフォーカス表示そのものが十分に視認できることを求めています。以前から2.4.7「Focus Visible」によって“フォーカスが見えること”は求められていましたが、WCAG 2.2ではさらに一歩進んで、「見えてはいるが実質的にわかりにくい」「固定要素に隠れて見えない」といった現場の困りごとにも目が向けられるようになりました。ここが今回のアップデートのとても実務的なところです。

たとえば、最近のWebサイトでは、画面上部に固定ヘッダーを置く設計が一般的です。スクロールしてもメニューや問い合わせボタンが追従するため、マウス利用者には便利に感じられます。けれど、キーボード操作でページを移動していると、フォーカスが当たったリンクや入力欄が、その固定ヘッダーの裏に隠れてしまうことがあります。利用者はTabキーで進んでいるのに、見た目には何も起きていないように感じられ、今どこへ移動したのかわからなくなってしまいます。これはまさに2.4.11で問題視される状態です。設計段階では便利に見えるUIでも、キーボードで確認すると別の姿が見えてくるという典型例です。

また、フォーカス表示そのものが極端に弱いケースもよく見られます。デザインの統一感を重視するあまり、ブラウザ標準のアウトラインを消し、代わりにごく薄いグレーの枠線やほとんど目立たない影だけを付けている例です。制作者側は「表示はしている」と考えていても、背景色とのコントラストが低かったり、要素サイズに対して変化が小さすぎたりすると、実際には気づきにくくなります。特に、リンクが多く並ぶナビゲーションや表形式のデータ、カードUIの一覧などでは、フォーカスが見えにくいだけで操作難易度が大きく上がります。フォーカス表示は飾りではなく、移動の手がかりです。目立ちすぎることを恐れるより、見失わせないことを優先すべき場面だと考えたいところです。

実務でまず確認したいのは、ページの最初から最後までTabキーだけでたどれるかどうかです。ヘッダー、グローバルナビゲーション、パンくず、メインコンテンツ、サイドバー、フォーム、フッターまで、主要な操作対象を順にたどっていけるかを見ます。このとき、移動順序が視覚的な流れと大きくずれていないか、途中でフォーカスが消えないか、フォーカスできるべきものに当たるか、逆に意味のない装飾要素にばかり当たらないかも重要です。キーボード操作の確認は、特別な検証環境がなくてもすぐ始められる点が大きな利点です。マウスを置いて、普段のサイトをTabキーで触ってみるだけでも、多くの課題が見えてまいります。

ここで注意したいのが、フォーカス順序です。たとえすべての要素にフォーカスできても、順番が不自然であれば操作はしにくくなります。たとえば、ページ上部のメニューから本文へ進む前に、見えない位置のリンクやサイドバーの細かな項目へ飛んでしまう。あるいは、カードUIの中でタイトル、画像、詳細リンク、余白のような順序で移動してしまい、どの情報がまとまりなのかわかりにくい。このような順序の乱れは、HTMLの構造やCSSの見せ方、JavaScriptによる制御の影響で起こりやすいものです。視覚上の並びと、ソース上の構造や操作順序が大きく離れていないかを意識することが大切です。

スキップリンクの有無も、キーボード操作の快適さを左右します。ヘッダーやナビゲーションが多いサイトでは、毎回ページ冒頭から細かなリンクを何度も通過しなければ本文に入れないことがあります。そのため、「メインコンテンツへ移動」のようなスキップリンクを用意し、キーボード利用者が主要な内容へすぐ進めるようにすることは非常に有効です。スキップリンクは普段は目立たなくても構いませんが、フォーカスされたときにはきちんと見える必要があります。せっかく設置していても、フォーカス時に画面外のままだったり、背景に溶け込んで読めなかったりすると、機能しません。ここでもやはり、フォーカス表示の設計が重要になります。

モーダルやドロワーメニュー、タブUIなど、JavaScriptを伴うコンポーネントは特に注意が必要です。モーダルを開いた瞬間にフォーカスがモーダル内部の見出しや閉じるボタンへ移動するか、閉じたときに元のトリガーボタンへ戻るか。ドロワーメニューを開いた状態で、背景コンテンツにフォーカスが抜けてしまわないか。タブUIで現在選択中のタブがわかり、矢印キーなど期待される操作に対応しているか。これらは、見た目が整っているだけでは十分ではありません。キーボード利用者にとって操作の流れが自然であるかどうかが問われます。最近のサイトでは動きのあるUIが増えていますが、操作の文脈が途切れないことのほうが、むしろ大切です。

スマートフォン中心の設計でも、キーボード操作の観点は無関係ではありません。タブレットで外付けキーボードを使う場合や、一部の支援技術、TVブラウザ、特殊な入力デバイスなどを考えると、キーボードやそれに準じた順次移動での操作性は依然として重要です。また、フォーカス表示が明確であることは、単にキーボード利用者だけでなく、現在操作対象を見失いやすいすべての利用者に役立ちます。つまり、フォーカスの強化はニッチな対応ではなく、全体の操作品質を上げることにつながっていくのです。

実務上の“惜しい例”をいくつか挙げてみます。第一に、グローバルナビゲーションのリンクへTab移動はできるのに、サブメニューがキーボードでは開かないケースです。第二に、ボタンにはフォーカスが当たるものの、現在位置を示す変化が背景色のごくわずかな差しかなく、ほとんど見えないケースです。第三に、問い合わせフォームへ進もうとしても、その前に大量のSNSリンクやバナーに順番に当たってしまい、本文まで遠いケースです。第四に、固定ヘッダーによってフォームの入力欄やエラーメッセージが隠れ、フォーカス位置が把握しにくくなるケースです。第五に、カルーセルやアコーディオンのような複雑なUIで、見た目には選択できそうでもキーボードでは進めないケースです。どれも、マウス操作では気づきにくいのに、キーボードでは大きなストレスになります。

改善の方向としては、まずネイティブのHTML要素を正しく使うことが基本になります。リンクにはa要素、ボタンにはbutton要素、フォーム部品には適切な入力要素を使う。これだけでも、キーボード操作や支援技術との相性はかなり良くなります。さらに、ブラウザ標準のフォーカス表示を安易に消さないこと、消す場合はそれ以上に見やすい代替表示を設計すること、固定ヘッダーや追従要素がフォーカス対象を隠さないようスクロール位置を調整すること、スキップリンクを用意すること、モーダルやタブなどはWAI-ARIAの考え方に沿って挙動を整えることが重要です。派手な新機能を足すより、基本操作を崩さないことのほうが、ずっと大きな価値になります。

ここで、UUUウェブアクセシビリティサービスとの親和性も整理しておきます。UUUのように、文字サイズ変更、コントラスト調整、行間調整、アニメーション停止、読み上げ、翻訳、ふりがな表示などの閲覧補助機能を提供するサービスは、利用者が見やすく理解しやすい表示へ近づけるという意味で大きな意義があります。たとえば、フォーカス表示が色の差で見えにくい場合に、コントラスト調整が補助的に役立つ場面はありえますし、読み上げ支援や表示調整が全体の理解しやすさを助けることもあります。

ただし、キーボード操作そのものの成立や、フォーカス順序、フォーカスが隠れないこと、モーダル内で適切に移動できることなどは、閲覧補助機能だけでは根本的に解決できません。そこはやはり、元のHTML構造、CSS設計、JavaScript実装を整える必要があります。つまり、UUUのようなサービスは“見え方や読みやすさを補助する役割”と相性がよい一方で、キーボード操作やフォーカス管理の品質そのものは、作り手側が責任を持って実装しなければならない領域です。この役割の違いを理解しておくと、「ツールを入れたのに操作しづらい」というすれ違いを避けやすくなります。

このテーマは、エンジニアだけのものでもありません。ディレクターであれば、要件定義や受け入れ確認の時点で「キーボードだけで主要導線に進めるか」「フォーカスは十分に見えるか」を確認項目に入れられます。デザイナーであれば、フォーカス表示を後回しにせず、通常状態・ホバー状態と同じように設計対象として扱えます。編集者や広報担当者であっても、スキップリンクやナビゲーションの整理、不要なリンクの多さに気づくことができます。つまり、キーボード操作とフォーカス表示は、実装の細部でありながら、サイト全体の設計思想が表れやすい領域なのです。

第4回のまとめです。キーボード操作とフォーカス表示は、見た目では気づきにくい一方で、利用者にとってはWebサイトを使えるかどうかを左右する非常に重要な要素です。WCAG 2.2では、フォーカスが見えるだけでなく、十分に視認できること、固定要素などで隠れないことがより重視されるようになりました。実務では、Tabキーだけでページを操作し、順序、到達性、表示の見えやすさ、モーダルやメニューの挙動を確認することが第一歩になります。そして、UUUウェブアクセシビリティサービスのような支援策は閲覧補助の面で価値がある一方、キーボード操作とフォーカス管理の品質は、やはりWebコンテンツそのものの設計と実装で整える必要があります。次回は、読みにくい文章をどう変えるかをテーマに、見出し、要約、やさしい日本語の整え方を見てまいります。

参考リンク

• W3C: Web Content Accessibility Guidelines (WCAG) 2.2
• W3C WAI: Understanding WCAG 2.2
• W3C WAI: Keyboard Accessible
• W3C WAI: Understanding Success Criterion 2.1.1 Keyboard
• W3C WAI: Understanding Success Criterion 2.4.7 Focus Visible
• W3C WAI: Understanding Success Criterion 2.4.11 Focus Not Obscured (Minimum)
• W3C WAI: Understanding Success Criterion 2.4.13 Focus Appearance
• W3C WAI-ARIA Authoring Practices Guide
• WAIC: Web Content Accessibility Guidelines (WCAG) 2.2 日本語訳
• WAIC: 達成基準 2.4.7 フォーカスの可視化 解説書