JIS X 8341-3:2016のガイドライン2.1「キーボード操作可能」は、ウェブコンテンツの機能をキーボードインタフェースから利用できるようにする考え方です。
レベルAとAAの適合を確認する際は、達成基準2.1.1「キーボード」と2.1.2「キーボードトラップなし」が中心になります。
ただし、Tabキーでリンクやボタンへ移動できるだけでは十分ではありません。
操作対象へ移動し、機能を実行し、入力内容を変更し、開いた画面を閉じて次の場所へ進めるところまで確認する必要があります。
「キーボード操作可能」が意味すること
キーボードインタフェースとは、物理キーボードだけでなく、キーストロークを生成する代替キーボードや入力支援の仕組みも含む考え方です。
そのため、キーボード対応は、マウスやタッチ操作が難しい人だけでなく、視覚障害のある人、手指の細かな操作が難しい人、支援技術を利用する人にも関係します。
フォーカスとは、現在キーボード操作の対象になっている要素です。
利用者はTabキーなどでフォーカスを移動し、EnterキーやSpaceキーなど、その要素に応じた操作で機能を実行します。
現在位置が見えなかったり、移動順序が不自然だったりすると、機能がキーボードから利用できても操作は難しくなります。
ガイドライン2.1の達成基準
JIS X 8341-3:2016のガイドライン2.1には、次の三つの達成基準があります。
レベルAとAAの実装確認では、レベルAの2.1.1と2.1.2を満たす必要があります。
| 達成基準 | レベル | 確認する内容 |
|---|---|---|
| 2.1.1 キーボード | A | 個々のキーストロークに特定のタイミングを要求せず、原則としてすべての機能をキーボードインタフェースから操作できるか。 |
| 2.1.2 キーボードトラップなし | A | キーボードで入ったコンポーネントから、キーボードだけでフォーカスを外せるか。標準的でない操作が必要なら、その方法を利用者へ知らせているか。 |
| 2.1.3 キーボード（例外なし） | AAA | すべての機能をキーボードインタフェースから操作できるか。軌跡に依存する機能があるコンテンツは、この基準には適合できない。 |
達成基準2.1.1を実装するポイント
達成基準2.1.1は、マウスで使える機能にキーボードからも到達できることだけを求めているのではありません。
リンク先への移動、ボタンの実行、フォームへの入力、メニューの開閉、選択肢の変更など、一連の操作をキーボードで完了できる必要があります。
標準のHTML要素を優先する
リンクにはa要素、ボタンにはbutton要素、入力欄には対応するフォーム要素を使うと、ブラウザが標準のキーボード操作を提供します。
見た目だけをボタンらしくしたdiv要素やspan要素へクリック処理だけを追加すると、フォーカスできない、キーで実行できない、役割が支援技術へ伝わらないといった問題が生じます。
| 要素 | 代表的な確認操作 | 確認内容 |
|---|---|---|
| リンク | Tab、Enter | フォーカスでき、リンク先へ移動できる。 |
| ボタン | Tab、Enter、Space | フォーカスでき、意図した機能を実行できる。 |
| チェックボックス | Tab、Space | 項目へ移動し、選択状態を切り替えられる。 |
| 選択リスト | Tab、矢印キー | 項目へ移動し、候補を選べる。 |
独自の操作部品では、期待されるキー操作が部品の種類によって異なります。
単にすべてをEnterキーで動かすのではなく、標準のHTML要素で実現できない理由を確認したうえで、役割、状態、キー操作、フォーカス移動を一体として設計します。
軌跡に依存する機能の例外を広げすぎない
2.1.1には、機能そのものが利用者の動きの軌跡に依存する場合の例外があります。
たとえば自由な筆跡を描く機能は軌跡そのものに意味がありますが、項目をある場所から別の場所へ移す操作は、移動経路ではなく始点と終点が目的になる場合があります。
後者では、ドラッグ操作だけにせず、切り取りと貼り付けや移動ボタンなど、キーボードで使える方法を用意できるか検討します。
達成基準2.1.2で防ぐキーボードトラップ
キーボードトラップとは、キーボードでコンポーネント内へ移動できるのに、キーボードだけでは外へ出られない状態です。
プラグイン、埋め込みコンテンツ、モーダルダイアログ、独自のメニューなどで起こることがあります。
モーダルを開いている間、フォーカスをモーダル内部で循環させる設計そのものが、直ちに問題になるわけではありません。
閉じるボタンをキーボードで操作でき、閉じ方が分かり、閉じた後にフォーカスがモーダルを開いたボタンなどの論理的な位置へ戻れば、利用者は操作を続けられます。
Escキーで閉じる方法も一般的ですが、画面上の「閉じる」ボタンを操作できることも確認します。
標準的なTabキーや矢印キーでは外へ出られず、別のキー操作が必要な場合は、その方法をコンポーネントへ入る前または入った時点で知らせます。
説明がコンポーネントの外へ出た後にしか読めない配置では、抜け方を知る手がかりになりません。
フォーカス表示と時間制限は別の達成基準
キーボード操作を実用に耐えるものにするには、ガイドライン2.1以外の達成基準も併せて確認します。
特に、フォーカスの順序と見え方は、キーボード利用者が現在位置を理解するために必要です。
| 関連する達成基準 | キーボード確認との関係 |
|---|---|
| 2.4.3 フォーカス順序 | Tabキーで移動する順序が、内容と操作の意味に沿っているかを確認する。 |
| 2.4.7 フォーカスの可視化 | 現在フォーカスされている要素を視覚的に識別できるかを確認する。 |
| 2.2.1 タイミング調整可能 | 制限時間がある場合に、利用者が解除、調整、延長できるかを確認する。 |
| 2.2.2 一時停止、停止及び非表示 | 自動的に動く、点滅する、スクロールする、更新される情報を利用者が制御できるかを確認する。 |
なお、WCAG 2.1以降の達成基準2.1.4は「文字キーのショートカット」です。
文字、数字、記号だけで作られたショートカットを無効化または再設定できるようにするか、対象のコンポーネントへフォーカスがあるときだけ有効にすることを求めています。
これはJIS X 8341-3:2016のガイドライン2.1に含まれる達成基準ではなく、時間制限を扱う基準でもありません。
キーボードだけで確認する手順
検証では、個々の要素だけでなく、問い合わせ、購入、予約、検索など、利用者が完了させたい一連の操作を選びます。
マウスやタッチ操作を使わず、次の順序で確認すると問題の位置を特定しやすくなります。
- ページの先頭からTabキーで進み、ShiftキーとTabキーで戻れるかを確認する。
- すべてのリンク、ボタン、入力欄などへ到達できるかを確認する。
- Enterキー、Spaceキー、矢印キーなど、要素に応じたキーで操作できるかを確認する。
- メニュー、アコーディオン、タブ、モーダルを開き、内部を操作して閉じられるかを確認する。
- 閉じた後や入力エラーの発生後に、フォーカスが利用者の次の操作につながる位置にあるかを確認する。
- 移動中のフォーカスが常に見え、画面外や固定ヘッダーの背後に隠れないかを確認する。
- ページの途中でフォーカスが消えたり、同じ場所から抜け出せなくなったりしないかを確認する。
ブラウザの自動検査は、フォーカス順序が自然か、独自部品を実際に操作できるか、モーダルを閉じた後の位置が適切かといった判断をすべて代行するものではありません。
実際のキー操作による確認を残します。
実装時に起こりやすい問題
outline: noneなどでフォーカス表示を消し、代わりの視覚表示を用意していない。- マウスのクリックやホバーだけでメニューを開き、キーボードから同じ機能を使えない。
- 正の値を持つ
tabindexを多用し、画面の見た目とフォーカス順序が一致しない。 - モーダルを閉じる操作が画面上のアイコンのクリックだけになっている。
- ドラッグ操作に、選択して移動するボタンなどの代替手段がない。
- 入力エラーが表示されても、エラーの説明や修正対象へキーボードでたどれず、どこを修正すべきか分からない。
フォーカス表示、移動順序、モーダルなどの確認例は、関連記事のキーボード操作とフォーカス表示を整える実務でも詳しく解説しています。
確認時に押さえる要点
- Tabキーで到達できるだけでなく、実行、変更、終了までキーボードで完了できるかを確認する。
- 標準のHTML要素を優先し、独自部品では役割、状態、キー操作、フォーカス移動をまとめて設計する。
- キーボードトラップを防ぎ、標準的でない抜け方が必要なら事前に操作方法を知らせる。
- フォーカス順序とフォーカス表示を、関連する達成基準として別途確認する。
- 自動検査だけで終えず、代表的な利用手順をキーボードだけで最後まで試す。
当社では、表示や閲覧を補助するUUU ウェブアクセシビリティウィジェットツールを提供しています。
ウェブアクセシビリティの改善を検討している方は、サービスの詳細をご覧ください。
なお、キーボード操作の成立、フォーカス順序、独自部品の操作性は、元のHTML、CSS、JavaScriptでも確認する必要があります。