TabキーなどでWebページを操作するとき、現在選ばれているリンクやボタンが見えなければ、次の操作先を判断できません。
フォーカスとは、キーボード入力を受け付ける対象が選ばれている状態です。
その位置を枠線や色の変化で示す視覚的な目印を、フォーカスインジケーターと呼びます。
WCAG 2.2の達成基準2.4.7「フォーカスの可視性」は、キーボードで操作できるインターフェースにおいて、この目印を見える状態にすることを求めるLevel AAの基準です。
達成基準2.4.7が求めること
W3Cの達成基準2.4.7が求めているのは、キーボードフォーカスがどこにあるかを視覚的に確認できる操作方法を用意することです。
リンク、ボタン、入力欄などにフォーカスが移ったとき、利用者が現在位置を識別でき、フォーカスがある間は目印が消えないようにします。
ブラウザの標準表示を利用しても、CSSで独自の表示を用意しても構いません。
ただし、標準の枠線を消す場合は、代わりになる目印を必ず提供する必要があります。
フォーカス表示が必要な理由
キーボードで操作する利用者は、フォーカスの位置を手がかりにしてリンクを開いたり、ボタンを押したり、フォームへ入力したりします。
フォーカスが見えないと、操作できる要素があっても、現在どこを操作しようとしているのか判断しにくくなります。
明確なフォーカス表示は、キーボード利用者だけでなく、画面の細部を捉えにくい利用者にも現在位置を伝える助けになります。
コントラストや太さとの関係
達成基準2.4.7の中心は「フォーカスインジケーターが見えること」です。
一方、独自に設定した表示のコントラストや、フォーカス表示の大きさを評価するときは、関連する達成基準と分けて確認する必要があります。
| 達成基準 | 確認する内容 |
|---|---|
| 2.4.7 フォーカスの可視性（Level AA） | キーボードフォーカスの位置を視覚的に確認できるか |
| 1.4.11 非テキストのコントラスト（Level AA） | 独自に設定した状態表示が、隣接する色から識別できるか |
| 2.4.13 フォーカスの外観（Level AAA） | フォーカス表示の大きさや、フォーカス前後の見え方の変化が十分か |
したがって、「青い2pxの枠線にすれば常に適合する」とは限りません。
色や太さの指定は実装の出発点であり、実際の背景色や部品の状態を使って見え方を確認します。
フォーカスインジケーターの実装方法
ブラウザの標準表示を残す
独自のデザインが不要であれば、ブラウザが提供する標準のフォーカス表示を残す方法があります。
button:focus {
outline: auto;
}
標準表示を使う場合も、サイトの背景や周囲の装飾に埋もれず、実際に見えることを確認します。
CSSで見える枠線を設定する
標準表示が分かりにくい場合は、フォーカスを受け取る要素にCSSで枠線を設定します。
a:focus,
button:focus,
input:focus,
select:focus,
textarea:focus {
outline: 2px solid #0000ff;
outline-offset: 2px;
}
outline-offsetを指定すると、枠線と要素の境界を離せるため、既存の枠線と重なりにくくなります。
入力欄の背景色を変える方法もありますが、色の変化だけに頼らず、枠線などの形でも現在位置を示すと確認しやすくなります。
JavaScriptを使う場合も表示を消さない
動的な部品ではJavaScriptでフォーカス時の見え方を切り替えることもできますが、基本的な表示はCSSだけでも実装できます。
スクリプトを使う場合は、フォーカスを受け取った直後にフォーカス自体を外したり、目印を短時間で消したりしないようにします。
よくある失敗と改善方法
代替表示なしで枠線を消す
次の指定は、ブラウザの標準的なフォーカス表示を消してしまいます。
button:focus {
outline: none;
}
outline: noneを使う必要がある場合は、同じフォーカス状態に対して、見える枠線や背景の変化を別途設定します。
薄い色や細かな変化だけに頼る
薄い灰色の細い枠線は、白い背景では見えても、別の背景や表示環境では見分けにくくなることがあります。
通常時とフォーカス時を並べ、ページ内の異なる背景でも現在位置を識別できるか確認します。
一部の部品だけを確認する
ボタンだけにスタイルを設定しても、リンクや入力欄、選択メニューなどに表示がなければ、ページ全体の確認は完了しません。
サイト独自の操作部品がある場合は、その部品も含めてキーボードで順に確認します。
キーボードによるテスト手順
- ページの先頭からTabキーを押し、フォーカスが移るたびに現在位置を目で追います。
- ShiftキーとTabキーを使って逆方向にも移動し、同じように目印が見えるか確認します。
- リンク、ボタン、入力欄、選択メニューなど、フォーカスを受け取る各要素を確認します。
- 明るい背景と暗い背景、通常時と選択時など、見え方が変わる場所でも目印を識別できるか確認します。
- フォーカスを移動するまで目印が残り、途中で消えないことを確認します。
フォーカスがそもそも目的の部品へ移らない場合は、表示だけでなくキーボード操作の実装も確認します。
その切り分けには、WCAG 2.2「2.1.1 キーボード操作」の実装とテストも参考になります。
自動テストは手動確認を補う
AxeやWAVEなどの自動テストツールは、アクセシビリティ上の問題を探す補助として利用できます。
ただし、ページ内のすべての状態でフォーカスが実際に見えるかどうかは、キーボードを使った手動テストでも確認します。
カラーチェッカーを使う場合も、数値だけで判断せず、実際の部品と背景の組み合わせを見ます。
実装と確認のチェックリスト
- フォーカスを受け取る各要素に、見える目印がある
- ブラウザ標準の枠線を、代替表示なしで消していない
- 背景色や部品の状態が変わっても、現在位置を識別できる
- フォーカスがある間、目印が消えない
- TabキーとShiftキー＋Tabキーで実際に確認している
- 自動テストの結果だけで判定していない
フォーカスの可視性を実装する要点
達成基準2.4.7への対応では、フォーカスインジケーターを消さず、利用者が現在位置を追える状態を保ちます。
CSSの指定だけで完了とせず、ページ内のすべての操作部品をキーボードでたどり、背景や状態が変わっても見えるか確認することが欠かせません。
設計から運用までの確認項目は、キーボード操作とフォーカス表示を整える実務ガイドでも詳しく紹介しています。
当社では、Webアクセシビリティを導入しやすくするUUU ウェブアクセシビリティを提供しています。
アクセシビリティ向上に関心がある方は、サービスの詳細をご覧ください。