Webアクセシビリティのキーボード操作｜実装方法と確認ポイント

マウスを使わなくても、リンクの移動、フォーム入力、メニューの開閉、送信といった操作を完了できることは、Webアクセシビリティの基本です。

キーボード操作は、画面を読み上げる支援技術を使う人、細かなポインター操作が難しい人、けがなどで一時的にマウスを使いにくい人に必要です。

マウスを使える人にとっても、フォームや管理画面を素早く移動する手段になります。

この記事では、実装時に迷いやすいフォーカス順序、フォーカス表示、キーボードトラップ、HTMLとARIAの使い分けを、確認手順まで含めて整理します。

キーボード操作に対応する理由

キーボード操作可能とは、マウスやタッチ操作に頼らず、キーボードまたは同等の入力手段で必要な機能を利用できる状態です。

視覚障害のある人が使うスクリーンリーダーの仕組みと実装上の配慮でも、キーボードによる移動と操作は大きな役割を持ちます。

ただし、「視覚障害のある人は全員キーボードだけを使う」という意味ではありません。

利用する支援技術や入力方法は人によって異なるため、特定の利用者像だけを前提にせず、複数の操作方法を妨げない設計が必要です。

WCAGでも、コンテンツの機能をキーボードで操作できることが基本的な要件として扱われます。

一方、キーボード対応だけでWebサイト全体のアクセシビリティ適合や法令対応が完了するわけではありません。

適用される基準、契約条件、組織の方針は個別に確認する必要があります。

最初に確認する四つの操作

キーボード対応は、キーイベントを追加する作業だけではありません。

利用者が現在位置を把握し、予想できる順序で移動し、目的の機能を実行して、元の操作へ戻れることまでを一つの流れとして設計します。

キーの役割は、対象となるUIの種類によって異なります。

ページ全体に同じキー処理を追加するのではなく、リンク、ボタン、メニュー、ダイアログなど、それぞれの役割に合う操作を選びます。

標準のHTML要素から実装する

ネイティブHTML要素とは、ブラウザが役割と基本操作をあらかじめ理解できる要素です。

<a>、<button>、<input>などを用途どおりに使えば、独自のキー処理を追加する範囲を減らせます。

<a ​href="/contact/">お問い合わせ</a>

<button ​type="submit">送信</button>

<label ​for="name">お名前</label>
<input ​id="name" ​name="name" ​type="text">

一方、次のように<div>へクリック処理だけを付けると、要素の役割もキーボードでの操作方法も利用者へ十分に伝わりません。

<div ​onclick="submitForm()">送信</div>

見た目がボタンであり、実行する機能もボタンなら、最初から<button>を使うほうが実装意図も明確です。

フォーカス順序と表示を整える

ページの流れに沿って移動させる

フォーカスは、現在キーボード操作の対象になっている要素を示す状態です。

Tabキーで移動したとき、見出しから本文、入力欄、送信ボタンへと、内容を読む流れに沿ってフォーカスが進むようにします。

見た目だけを並べ替えてHTML上の順序を変えないと、画面で見える位置とキーボードの移動順が食い違うことがあります。

非表示のメニューや閉じたダイアログ内の要素へフォーカスが移る状態も避けます。

現在位置を見えるようにする

利用者が現在位置を判断できるように、フォーカスの枠や背景変化を消さず、実際の背景上で見分けられる表示にします。

サイトのデザインに合わせて標準の枠を変更する場合も、代わりの表示を用意します。

a:focus,
button:focus,
input:focus,
select:focus,
textarea:focus ​{
 ​ ​outline: ​3px ​solid ​#005fcc;
 ​ ​outline-offset: ​3px;
}

この色と太さは実装例であり、どの配色でも同じ見え方を保証する値ではありません。

ヘッダー、本文、ボタンなど、背景の異なる場所でフォーカスが見えるかを確認します。

フォーカス表示の設計と検証は、キーボード操作とフォーカス表示の実務でも詳しく確認できます。

キーボードトラップを防ぐ

キーボードトラップとは、ある要素へフォーカスを移した後、キーボードではそこから抜けられなくなる状態です。

モーダルを開いている間にフォーカスをモーダル内へ保つ設計は、それだけでキーボードトラップになるわけではありません。

キーボードで操作できる閉じるボタンを用意し、必要に応じてEscキーでも閉じられ、閉じた後に開始位置へ戻れることが必要です。

次のコードは、モーダルを開いたときのフォーカス移動、Escキーでの終了、閉じた後のフォーカス復帰だけを示す簡略例です。

モーダル内のTabキーによる移動範囲や、背景側を操作させない処理は、採用するダイアログの構成に合わせて別途設計します。

const ​modal ​= ​document.getElementById('settings-modal');
let ​opener ​= ​null;

function ​openModal() ​{
 ​ ​opener ​= ​document.activeElement;
 ​ ​modal.hidden ​= ​false;
 ​ ​modal.querySelector('button').focus();
}

function ​closeModal() ​{
 ​ ​modal.hidden ​= ​true;
 ​ ​if ​(opener) ​opener.focus();
}

document.addEventListener('keydown', ​(event) ​=> ​{
 ​ ​if ​(event.key ​=== ​'Escape' ​&& ​!modal.hidden) ​{
 ​ ​ ​ ​closeModal();
 ​ ​}
});

ARIAは標準HTMLを補うために使う

ARIAは、標準HTMLだけでは表しにくいUIの役割、名前、状態を支援技術へ伝えるための属性です。

ARIAを追加しても、フォーカス移動やキー操作が自動的に実装されるわけではありません。

ボタンを作るなら<button>を選び、独自UIが必要な場合に限って、役割と状態に合うARIA属性とキーボード操作を組み合わせます。

モーダルでは、ダイアログであること、見出しとの関係、開閉状態を支援技術へ伝える必要があります。

属性を付ける前に、ARIAで役割と状態を伝える基本を確認すると、標準HTMLとの使い分けを整理できます。

利用場面から操作経路を確認する

根拠を確認できない成功率や問い合わせ削減数を示すより、利用者が完了すべき操作を具体的にたどるほうが、実装の欠けを見つけやすくなります。

行政手続きのフォームを想定する

ページ上部の案内から申請フォームへ移動し、各入力欄へ記入し、確認画面を経て送信するまでを、マウスなしで試します。

入力エラーが出た場合は、どこを直すのかが分かり、修正後に送信操作へ戻れるかも確認します。

オンラインショップを想定する

検索、商品選択、数量変更、カート、購入確認という一連の操作をキーボードでたどります。

途中で開くメニューやダイアログだけでなく、閉じた後に次の操作を続けられるかまで確認します。

これらは実在サイトの改善成果を示す事例ではなく、テスト対象を具体化するための想定場面です。

公開前のキーボード確認項目

• TabキーとShift＋Tabキーで、すべての操作対象へ前後に移動できる
• フォーカスの移動順が、画面の内容と操作の流れに合っている
• 現在フォーカスされている要素を視覚的に判別できる
• リンク、ボタン、フォーム、メニューを適切なキーで操作できる
• 非表示の要素へフォーカスが移動しない
• モーダルやメニューをキーボードで閉じられる
• 動的なUIを閉じた後、開始した要素へフォーカスが戻る
• クリック専用の<div>や<span>が残っていない
• ARIAの役割と実際のキー操作が食い違っていない

最後にマウスを使わず、主要な操作を最初から最後まで実行します。

単独のボタンが押せるだけでは、ページ全体を利用できるとは判断できません。

移動、現在位置の把握、実行、終了、元の位置への復帰を一続きで確認することで、利用者が途中で操作を断念する障壁を見つけやすくなります。