WCAG 2.2「2.1.1 キーボード操作」Level Aとは？実装とテストの基本

WCAG 2.2の達成基準2.1.1「キーボード操作」は、Webコンテンツの機能をキーボードインターフェースから利用できることを求めるLevel Aの基準です。
マウスを使えない人だけでなく、スクリーンリーダー、スイッチ、音声入力など、キーストロークに相当する入力を利用する人にも関わります。

実装で確認するのは、Tabキーでリンクに移動できるかだけではありません。
メニューを開く、ダイアログを閉じる、フォームを送信する、項目を並べ替えるといった処理を、キーボードだけで最後まで完了できるかが問われます。

達成基準2.1.1が求めること

キーボードインターフェースとは、物理キーボードに限らず、ソフトウェアがキーストローク入力を受け取るための仕組みです。
キーボードと同等の入力を送る支援技術も、この仕組みを利用します。

• すべての機能：ポインターで実行できる機能には、キーボードから同じ結果へ到達できる手段を用意します。
• 個々のキー入力に特定のタイミングを求めない：短時間の連打や、一定時間の長押しが成功条件になる操作を避けます。
• 例外は操作方法ではなく機能の性質で判断する：入力の軌跡そのものが結果になる機能は例外になり得ます。

ドラッグ＆ドロップを使っているという理由だけで、例外になるわけではありません。
項目の並べ替えのように開始点と終了点で目的を表せる機能なら、上下移動ボタンなど、キーボードで実行できる代替手段を用意できます。

一方、自由な線を描くように、移動の軌跡そのものが結果になる機能は例外の対象になり得ます。
基準が認めているのは、このような「機能そのものが軌跡に依存する場合」であり、実装がたまたまポインター操作を採用している場合ではありません。

この基準は、マウスやタッチ操作の提供を妨げるものではありません。
複数の入力方法を残したうえで、キーボードからも必要な操作を完了できる状態にします。

標準HTML要素を優先する

ボタン、リンク、入力欄などは、用途に合う標準HTML要素で実装するのが基本です。
ブラウザーがキーボード操作、フォーカス、役割などの土台を提供するため、独自要素で同じ挙動を再現するよりも実装漏れを減らせます。

<button type='button'>保存する</button>
<a href='/help/'>ヘルプを見る</a>

<label for='name'>氏名</label>
<input id='name' name='name' type='text'>

• <button>は、一般的なブラウザーでEnterキーまたはスペースキーから実行できます。
• hrefを持つ<a>は、Tabキーでフォーカスを移し、Enterキーでリンク先を開けます。
• 入力欄には、プレースホルダーだけに頼らず、対応する<label>を付けます。

標準のボタンやリンクに処理を結び付ける場合、clickイベントは名前に反してマウス専用ではありません。
ブラウザーの標準動作を壊していなければ、キーボードから要素を実行したときにも処理が呼び出されます。

カスタムUIにはキーボードの挙動を実装する

デザイン上の理由などで<div>や<span>を操作部品として使う場合は、フォーカス可能にするだけでは足りません。
役割、マウス操作、キーボード操作をそろえて実装します。

<div id='custom-button' role='button' tabindex='0'>
  詳細を表示
</div>

const customButton = document.getElementById('custom-button');

const activate = () => {
  console.log('詳細を表示');
};

customButton.addEventListener('click', activate);
customButton.addEventListener('keydown', (event) => {
  if (event.key === 'Enter' || event.key === ' ') {
    event.preventDefault();
    activate();
  }
});

• tabindex='0'で通常のTab順序に含めます。
• role='button'で、この要素がボタンであることを支援技術へ伝えます。
• clickとキーボードのイベントを、同じ処理へ接続します。
• スペースキーを扱うときは、必要に応じて既定のページスクロールを抑えます。

ただし、カスタムボタンを作る必要がなければ、最初から<button>を使う方が簡潔です。
ARIAの役割を追加しても、標準要素の挙動が自動で再現されるわけではありません。

ポインター専用の処理を見分ける

「clickイベントがあるか」だけでは、キーボード対応の成否を判断できません。
確認すべきなのは、要素へキーボードで到達でき、その機能を実行できるかどうかです。

たとえば、フォーカスできない画像のmousedownだけで次のページへ進む実装では、キーボードから同じ機能を呼び出せません。
この場合は、用途に合うボタンやリンクへ置き換えます。

<!-- 改善前：ポインター操作に依存している -->
<img src='next.svg' alt='次のページ' onmousedown='nextPage()'>

<!-- 改善後：キーボードからも実行できる -->
<button type='button' id='next-page'>次のページ</button>

フォーカスの順序と位置を保つ

フォーカスは、現在どの要素がキーボード入力を受け取るかを示す状態です。
キーボード利用者が操作位置を見失わないように、見た目と意味の流れに沿って移動させます。

まず、HTMLの並びを実際の操作順に合わせます。
フォーカス順序の考え方と実装ポイントも併せて確認すると、Tabキーで移動する流れを設計しやすくなります。

ヘッダーやナビゲーションが長いページでは、メインコンテンツへ直接移動できるリンクも役立ちます。

<a href='#main-content'>メインコンテンツへ移動</a>

<nav aria-label='主要なナビゲーション'>
  <a href='/service/'>サービス</a>
  <a href='/contact/'>お問い合わせ</a>
</nav>

<main id='main-content'>
  <h2>メインコンテンツ</h2>
</main>

この仕組みは一般にスキップリンクと呼ばれます。
実装と確認方法は、キーボード操作を助けるスキップリンクの解説で詳しく紹介しています。

blur()を使って、フォーカスを受け取った直後に強制的に外す実装は避けます。
操作位置が分からなくなり、次にどこへ進めばよいか判断できなくなるためです。

よくある失敗と改善方法

キーボードだけで確認する手順

自動テストツールはマークアップ上の問題を見つける補助になりますが、機能を最後まで操作できるかは手動で確かめます。
マウスやトラックパッドに触れず、次の順序で確認します。

1. Tabキーで前へ進む：リンク、ボタン、入力欄など、必要な操作要素へ順に移動できるかを確認します。
2. Shift＋Tabキーで戻る：逆方向にも移動でき、特定の場所から抜け出せなくならないかを確認します。
3. フォーカス位置を見る：現在位置が画面上で分かり、見た目と操作順が一致しているかを確認します。
4. 要素を実行する：リンクはEnterキー、ボタンはEnterキーとスペースキーで動作するかを確認します。
5. 一連の処理を完了する：メニューの開閉、入力、送信、並べ替えなどをキーボードだけで終えられるかを確認します。
6. 時間への依存を確認する：連打や長押しを求められず、利用者のペースで操作できるかを確認します。

AxeやWAVEなどの自動テストツールを使う場合も、この手動確認を省略しません。
自動検出の結果と実際の操作結果を組み合わせて判断します。

実装時のチェックリスト

• すべての機能へキーボードから到達できる
• 用途に合う標準HTML要素を優先している
• カスタムUIに役割、フォーカス、キーボード操作がそろっている
• フォーカスを強制的に外していない
• 見た目とフォーカス順序が一致している
• ポインター専用の機能にキーボードで使える手段がある
• 短時間の連打や長押しを成功条件にしていない
• マウスを使わずに一連の処理を完了できる

達成基準2.1.1への対応は、個々のイベントを機械的に追加する作業ではありません。
利用者がキーボードから機能へ到達し、迷わず実行し、目的の結果まで進めることを確認する作業です。

当社では、Webアクセシビリティの導入と改善を支援するUUU ウェブアクセシビリティを提供しています。
アクセシビリティ向上に取り組む際は、サービスの詳細もご覧ください。