WCAG 2.2の達成基準「2.1.2 キーボードトラップなし」は、キーボードで入れる操作部品から、キーボードだけで抜けられることを求めるLevel Aの基準です。
フォーム、モーダルダイアログ、独自に実装した操作部品などでフォーカスが動かなくなると、マウスを使わない利用者はページの続きへ進めません。
WCAG 2.2の全体像を押さえたうえで本基準を読むと、キーボード操作に関する要件の位置づけがわかりやすくなります。
キーボードトラップとフォーカスの意味
フォーカスとは、キーボードからの入力を現在受け取るリンク、ボタン、入力欄などの位置です。
TabキーやShiftキーとTabキーで操作対象を移すと、通常はフォーカスも前後へ移動します。
キーボードトラップとは、フォーカスが特定の操作部品や領域に入ったあと、キーボードだけでは外へ移せなくなる状態です。
達成基準2.1.2では、キーボードでフォーカスを入れられるなら、キーボードで離脱できなければなりません。
離脱に通常とは異なるキー操作が必要な場合は、その方法を利用者へ知らせます。
状況ごとに確認する要件
| 状況 | 確認事項 |
|---|---|
| 一般的なリンク、ボタン、入力欄 | TabキーとShiftキーを押しながらのTabキーで前後の要素へ移動できる |
| 矢印キーを使う独自の操作部品 | 部品内を操作したあとも、標準的なキー操作で部品の外へ移動できる |
| 特殊なキーで離脱する操作部品 | フォーカスが入る前、または部品内で、離脱に使うキーを確認できる |
| モーダルダイアログ | 開いている間はフォーカスを内部で管理し、閉じるボタンやEscキーで終了できる |
通常のフォームでは標準の移動を妨げない
一般的なリンク、ボタン、入力欄は、ブラウザが提供するフォーカス移動をそのまま利用できるように実装します。
Tabキーを押すたびに「名前入力欄、メール入力欄、送信ボタン、その次のリンク」のように、操作の流れに沿ってフォーカスが進む状態が基本です。
JavaScriptでキー入力を処理する場合は、Tabキーの既定動作を止めたまま同じ要素へフォーカスを戻していないか確認します。
キーボード操作の基本と実現方法もあわせて確認すると、フォーム以外の操作部品を含むページ全体を点検できます。
モーダル内のフォーカス循環はトラップと同じではない
モーダルダイアログを開いている間、Tabキーによるフォーカスをモーダル内で循環させる設計は、背景を誤って操作させないためのフォーカス管理です。
モーダルをキーボードで閉じられず、ページ本体へ戻れない場合にキーボードトラップとなります。
モーダルでは次の動作を一組として実装します。
- 開いた直後に、モーダル内の適切な要素へフォーカスを移す。
TabキーとShiftキーを押しながらのTabキーで、モーダル内の操作要素を前後に移動できるようにする。- キーボードで操作できる、わかりやすい「閉じる」ボタンを置く。
Escキーでも閉じられるようにする。- 閉じたあと、原則としてモーダルを開いたボタンへフォーカスを戻す。
aria-hiddenなどの属性で状態を切り替えるだけでは、閉じる操作、フォーカスの移動、背景の操作制限まで自動的に整うわけではありません。
実装全体を確認する場合は、アクセシビリティに配慮したモーダルダイアログの設計も参考になります。
特殊な離脱操作には説明が必要
独自の編集領域や複雑な操作部品では、Tabキーを部品内の機能に使うため、別のキー操作で外へ出る設計が必要になることがあります。
この場合は「どのキーを押せばフォーカスを外へ移せるか」を、フォーカスが入る前、または部品内で確認できるようにします。
「専用のショートカットがあります」とだけ書くのではなく、実際に押すキーと移動先がわかる説明にします。
誤解しやすい実装例
tabindex="0"だけでトラップになるわけではない
要素にtabindex="0"を指定すると、その要素は通常のフォーカス移動に加わります。
この指定だけでフォーカスが固定されるわけではなく、キーイベントで移動を止める処理や、同じ領域へフォーカスを戻し続ける処理が重なると問題になります。
モーダル内の循環だけを失敗と判定しない
モーダル内でフォーカスが循環していても、閉じる操作をキーボードで実行できれば、利用者はモーダルを終了してページへ戻れます。
確認する対象は「循環しているか」だけではなく、「終了方法があり、その方法をキーボードで使えるか」です。
自動検査だけで合否を決めない
axeやWAVEなどの検査ツールは点検の補助にできますが、実際のキー操作でフォーカスを外へ移せるかは手動で確認します。
キー入力に応じたJavaScriptの動作や、モーダルを閉じたあとのフォーカス位置まで順にたどると、利用者が操作を続けられるかを判断できます。
キーボードトラップの手動テスト
- マウスを使わず、
Tabキーでページ内のリンク、ボタン、入力欄へ順に移動する。 - 各要素から次の要素へ進めることを確認する。
Shiftキーを押しながらTabキーを押し、逆方向にも戻れることを確認する。- 矢印キーを使う独自の操作部品では、部品内を操作したあとに外へ出られるか確認する。
- モーダルを開き、内部を前後に移動したあと、「閉じる」ボタンと
Escキーの両方を試す。 - モーダルを閉じたあと、フォーカスが開く前の位置、または操作の流れに沿った位置へ戻ることを確認する。
- 特殊な離脱操作が必要なら、キーの説明を操作前または操作中に確認できることを確かめる。
途中でフォーカスが見えなくなった場合も、その位置と直前のキー操作を記録します。
「抜けられない」「戻れない」「閉じたあとに現在位置がわからない」のいずれかが起きた箇所は、フォーカス管理を見直します。
実装とテストのチェックリスト
- キーボードで入れる操作部品から、キーボードだけで外へ出られる。
- 通常のフォームでは、ブラウザの標準的なフォーカス移動を妨げていない。
- 特殊な離脱キーが必要な場合は、具体的な操作方法を示している。
- モーダルにはキーボードで操作できる閉じる手段がある。
- モーダルを閉じたあとも、利用者が操作を続けられる位置へフォーカスが戻る。
- 自動検査の結果だけで終えず、前後方向のキー操作を手動で試している。
達成基準2.1.2への対応では、フォーカスを単に移動させるのではなく、利用者が現在位置を把握しながら次の操作へ進める流れを保つことが必要です。
当社では、Webアクセシビリティの導入と改善を支援するUUU ウェブアクセシビリティを提供しています。
キーボード操作を含むアクセシビリティ改善に取り組む際は、サービスの詳細をご覧ください。