WCAG 2.2の達成基準2.1.3「キーボード操作（例外なし）」は、コンテンツのすべての機能をキーボードインターフェースから操作でき、個々のキー入力に特定のタイミングを求めないことを定めたLevel AAAの基準です。
単にTabキーで要素へ移動できればよいわけではありません。
マウスやタッチ操作で完了できる作業を、キーボードでも最後まで完了できる必要があります。
達成基準2.1.3が求めること
機能とは、利用者の操作によって実行できる処理や、得られる結果を指します。
ページ内の移動だけでなく、メニューを開く、項目を選ぶ、並べ替える、入力内容を送信するといった一連の操作も確認対象です。
キーボードインターフェースとは、ソフトウェアがキー入力を受け取るための仕組みです。
物理キーボードだけを想定した言葉ではなく、同じ仕組みにキー入力を送る支援技術も含めて考えます。
| 確認する要件 | 実務での読み方 |
|---|---|
| すべての機能を操作できる | ポインターで完了できる作業に、キーボードから実行できる方法がある |
| 特定のタイミングを求めない | 短時間での連打や、厳密な押下間隔を成功条件にしない |
| 例外を認めない | 操作経路そのものが結果を決める機能を含む場合、2.1.3には適合できない |
2.1.1「キーボード操作」との違い
達成基準2.1.1「キーボード操作」はLevel Aで、入力経路に依存する機能には例外があります。
2.1.3は基本要件を2.1.1と共有しますが、その例外を認めないLevel AAAの基準です。
パス依存入力とは、開始位置と終了位置だけでなく、途中でどの経路を通ったかが結果を左右する入力です。
たとえば、線を自由に描く機能では、ポインターが通った軌跡そのものが結果になります。
一方、項目をある位置から別の位置へ移すだけのドラッグ＆ドロップは、必ずしもパス依存とは限りません。
「上へ移動」「下へ移動」ボタンや移動先の選択欄で同じ結果を得られるなら、キーボード操作を用意できます。
実装では標準HTMLを優先する
ボタン、リンク、入力欄などは、役割に合うHTML要素を使うのが出発点です。
標準要素にはブラウザーが提供するキーボード操作と意味があり、独自要素へ同等の挙動を追加するより実装漏れを減らせます。
<button type="button">送信</button>
<a href="#main-content">本文へ移動</a>div要素にrole="button"とtabindex="0"を加えただけでは、ボタンとしての操作は完成しません。
標準要素を使えない事情がある場合は、フォーカスを受け取れること、期待されるキーで実行できること、ポインター操作と同等の結果になることをまとめて実装します。
ドラッグ操作には結果を選べる代替手段を用意する
並べ替えや移動をドラッグ操作だけに任せると、キーボード利用者は作業を完了できません。
対象を選んで「上へ」「下へ」と移動するボタン、移動先を選ぶメニュー、位置を数値で指定する入力欄など、同じ結果に到達できる操作を用意します。
ポインターの動きを矢印キーでそのまま再現することだけが代替ではありません。
利用者が必要とするのは、同じ作業結果へ無理なく到達できる方法です。
よくある失敗と改善方法
| 失敗 | 問題 | 改善 |
|---|---|---|
クリック可能なdivを使う |
通常のTab移動やキー操作だけでは実行できない | まずbuttonやaへ置き換える |
tabindexだけを追加する |
フォーカスできても、機能を実行できない | 役割に合うキー操作と処理結果まで実装する |
| 短時間の連打を求める | 個々のキー入力に特定のタイミングが必要になる | 一回の入力、または時間に依存しない手順へ変更する |
| ドラッグだけで並べ替える | キーボードから同じ結果へ到達できない | 移動ボタンや移動先の選択手段を追加する |
なお、clickイベントを使うこと自体が失敗なのではありません。
標準のbutton要素はキーボードからも実行できるため、問題はイベント名ではなく、利用者がキーボードで機能を完了できるかどうかです。
キーボードだけで手動テストする
自動検査ツールは、要素の役割や一部のフォーカス問題を見つける助けになります。
ただし、サイト内の全機能をキーボードで完了できるかまでは自動検査だけで判断できません。
キーボード操作とフォーカス表示の実務も確認しながら、手動テストを組み合わせます。
- マウスやタッチ操作を使わず、TabキーとShift＋Tabキーで操作対象を順に移動する。
- ボタンやリンクを、要素に応じたEnterキーやスペースキーで実行する。
- メニュー、タブ、選択肢などを、画面で案内されるキー操作で扱えるか確認する。
- 入力、エラー修正、送信、ダイアログを閉じる操作など、利用者の目的を最後まで完了する。
- 並べ替えや移動を含む機能に、ドラッグ以外の方法があるか確認する。
- 短時間の連打や厳密な押下間隔を求める機能がないか確認する。
矢印キーは、すべての要素で動作すればよいわけではありません。
タブやメニューなど、その操作方法で矢印キーが想定される部品を対象に確認します。
適合判断で取り違えやすい点
- フォーカスできることだけでは、機能を操作できるとは限りません。
- キーボードで一部を操作できても、作業を完了できなければ要件を満たしません。
- 達成基準2.1.3を満たしても、それだけでWCAGのほかの達成基準まで満たしたことにはなりません。
- Level AAAの採用可否は、サイトに含まれる機能とパス依存入力の有無を確認して判断します。
実装とテストの要点
達成基準2.1.3では、ポインターで使える機能をキーボードでも最後まで操作でき、キー入力の速さに成否を依存させない設計が必要です。
標準HTMLを優先し、独自UIではフォーカス、キー操作、処理結果を一体として設計します。
そのうえで、マウスを使わない手動テストを行い、各機能の開始から完了までを確認してください。
当社では、ウェブアクセシビリティの導入を支援するUUU ウェブアクセシビリティを提供しています。
アクセシビリティ改善を進めたい方は、サービスの詳細をご覧ください。