キーボード操作可能のガイドライン

2.1.1 キーボード (レベル A)

すべての機能や操作を、キーボードだけで利用できるようにする

作成日: 2024.4.10 / 最終修正日: 2026.5.6

この達成基準は、マウス以外の方法で操作する利用者が、キーボード（主にTabキー、Enterキー、Spaceキー、矢印キー）のみでも、サイトのすべての機能を利用できるようにすることを目的としています。

実践すべきこと

すべての操作をキーボードで完結させる

• リンクの遷移、ボタンの押下、フォームの入力、メニューの開閉など、すべての操作がキーボードだけで実行できるようにする。
• ドラッグ＆ドロップなどのポインタ操作が必要な機能には、キーボードで同じ結果を得られる代替手段（例：「上へ」「下へ」と移動させるボタン）を用意する。

運用者への注意

キーボードのみでのテスト

• 新しい機能やページを追加した際は、キーボード操作（Tabキー、Shift+Tabキー、Enterキーなど）だけで、目的の操作（例：お問い合わせの完了、商品の購入など）が最後までできるかテストする。

開発者への注意

HTML標準要素の利用（最重要）

• リンクには <a>、ボタンには <button>、入力には <input> など、標準のHTML要素を使用する。これらはデフォルトでキーボード操作に対応している。
• デザイン上の理由で <div> や <span> を使ってボタンを自作する場合、tabindex="0" を付与してフォーカスを受け取れるようにし、さらにJavaScriptでEnterキーとSpaceキーによる決定操作を実装する。

非表示要素へのフォーカス管理

• 狭い画面向けのハンバーガーメニューやアコーディオンが「閉じている」状態のときは、見えないリンクにフォーカスが当たらないよう、CSSの display: none; や visibility: hidden;、またはHTMLの inert 属性を用いて非表示にする。

今のWeb環境で気をつけたい点

• カルーセル（スライダー）の操作： タッチ操作でスワイプして操作する画像スライダーでも、キーボードだけで「次へ」「前へ」と切り替えられるボタンを併設するとよいです。
• 無限スクロール： 自動で読み込みが続くと、キーボードだけではフッターへたどり着きにくくなることがあります。「さらに読み込む」など、利用者の操作で読み込みを進める手段を検討するとよいです。

参考リンク

解説書 達成基準 2.1.1: キーボード

2.1.2 キーボードトラップなし (レベル A) 非干渉

キーボード操作で、特定の場所から抜け出せなくなる状態を作らない

作成日: 2024.4.10 / 最終修正日: 2026.5.6

この達成基準は、キーボード利用者がページ内を移動している際、広告、動画プレイヤー、モーダルウィンドウなど特定の項目やエリアにフォーカスが入ったあと、そこから抜け出して他の場所へ移動できなくなる状態を防ぐことを目的としています。

実践すべきこと

抜け出す方法の確保

• 特定のエリアにフォーカスが入った場合、Tabキーやその他の標準的なキー操作だけで、そのエリアの外へ移動できるようにする。
• もし標準のキー操作（Tabキー）だけで抜け出せない場合は、「Escキーで閉じる」「このエリアを抜けるボタン」などの、抜け出すための手段と方法を明示する。

運用者への注意

外部サービスの埋め込みチェック

• YouTubeなどの動画プレイヤー、SNSの埋め込みタイムライン、チャットボットなどをサイトに配置した際は、それらにキーボードでフォーカスを当てた後、正しくページの続き（後続のコンテンツ）へ移動できるかを確認する。

特定の操作で止まっていないかの確認

• キーボードだけで一通りページを閲覧し、どこかのエリアに入った瞬間にフォーカスがループしてしまい、フッターやメニューなどの他の場所に二度と行けなくなる箇所がないかをチェックする。

開発者への注意

モーダルウィンドウの適切な制御

• モーダルウィンドウを開いている間、フォーカスをモーダル内に閉じ込める（背景にフォーカスを飛ばさない）ことはアクセシビリティ上正しい実装だが、Esc キーや「閉じるボタン」へのフォーカス移動によって、利用者の意思でモーダルを終了できるように実装する。

JavaScriptによるフォーカス奪取の回避

• JavaScriptで focus() メソッドを使用する際は、利用者が予期しないタイミングで特定の場所に戻されるような実装を避け、操作の自由を保てるようにする。

今のWeb環境で気をつけたい点

• サードパーティ製ウィジェット： 外部のチャットや広告バナーには、キーボード操作が不十分なものがあり、フォーカスが戻りにくくなることがあります。導入時に Tab で出入りできるか、Esc で閉じられるかなどを検証するとよいです。
• 複雑な UI： 自作のカレンダー、ドラッグ＆ドロップ、インタラクティブな地図などは、フォーカス管理を誤ると抜け出しにくくなることがあります。設計段階からキーボード経路を確認するとよいです。

参考リンク

解説書 達成基準 2.1.2: キーボードトラップなし

2.1.3 キーボード (例外なし) (レベル AAA)

お絵描きツールや地図の移動などを含め、画面上の「すべての機能」を例外なくキーボードだけで操作できるようにする

作成日: 2024.4.10 / 最終修正日: 2026.5.27

この達成基準は、マウス以外の入力方法（キーボードやスイッチインターフェースなど）を使う利用者が、ウェブサイト上のすべての機能を利用できるようにすることを目的としています。レベルAの基準（2.1.1）で許容されていた「軌跡に依存する入力（お絵かきツールなど）」の例外をなくし、キーボード操作でも完結できることを求めています。

実践すべきこと

すべての機能のキーボード対応（例外の排除）

• ウェブページ上のすべての機能（地図の操作、ドラッグ＆ドロップ、イラストの描画ツール、スライダーなどを含む）を、キーボード操作のみで実行できるように設計・実装する。

運用者への注意

導入ツールの選定基準

• 外部のウィジェット（例えば3Dモデルのビューアーや、複雑なウィジェットなど）をサイトに導入する際、ポインタのドラッグ操作だけでなく、キーボードの矢印キーなどで視点移動や拡大縮小ができるかを事前に確認する。

開発者への注意

複雑なUIに対する代替操作の実装

• ドラッグ＆ドロップ： ポインタで要素を掴んで移動させるUIには、要素の横にメニューボタン（「上へ移動」「下へ移動」など）を設け、Enterキーだけで同じ操作ができるようにする。
• 軌跡が必要な入力： 地図上の特定の範囲をフリーハンドで囲むような機能には、数値を直接入力して範囲を指定するテキストフィールド（代替手段）を併設する。

今のWeb環境で気をつけたい点

• レベルAAAの難易度と優先度： 「例外なし」ですべての機能をキーボード対応させることは、Webブラウザ上で動くグラフィックツールや高度なアプリケーションなどにおいては、開発コストが上がるか、根本的にUI設計を見直す必要があるため、「レベルAAA」に設定されています。まずは例外事項を許容しつつサイトの基本操作をキーボードで可能にする 2.1.1（キーボード）を満たすことが優先ですが、業務システムやデータ入力ツールなど、利用者がマウス以外の入力方法で業務を遂行する必要があるアプリケーションにおいては、この「例外なし」の対応が重要になります。
• カンバン方式UIとアクセシビリティ： タスクをカードのようにドラッグ＆ドロップで動かすUI（カンバンボード）は、ポインタ操作では直感的である反面、キーボードで操作する利用者にとっては操作しにくくなりがちです。Spaceキーでカードを持ち上げ、矢印キーで移動先を選び、Enterキーでドロップするようなキーボード向けの操作ロジックを備える必要があります。

参考リンク

解説書 達成基準 2.1.3: キーボード (例外なし)

2.1.4 文字キーのショートカット (レベル A)

単一の文字キーによるショートカットの誤作動を防ぐ

作成日: 2024.4.10 / 最終修正日: 2026.5.6

この達成基準は、修飾キー（Ctrl、Alt、Cmdなど）を伴わない、文字キー単体（英数字や記号のみ）のショートカットによる誤操作を防ぐことを目的としています。特に、画面上のテキストを読み上げる音声入力を利用する人が、言葉を発した際に意図せずショートカットが実行されてしまう問題や、キーの押し間違いによる混乱を回避します。

実践すべきこと

以下のいずれかのメカニズムを提供する

• 解除可能：ショートカットをオフにする設定を用意する。
• 再割り当て可能：一つ以上の修飾キー（例：Ctrl）を組み合わせるように変更できる、または別のキーに割り当てられるようにする。
• フォーカス時のみ有効：そのショートカットが、特定のUIコンポーネントにフォーカスがある時だけ動作するように制限する。

運用者への注意

ヘルプドキュメントの整備

• 独自のショートカットを導入している場合は、その一覧と、無効化・変更する方法をヘルプページや設定画面に明記する。

デフォルト設定の検討

• 多くの利用者にとって利便性が高いショートカットであっても、アクセシビリティの観点からは「デフォルトでオフ」にするか、初回利用時に確認を促すなどの配慮を検討する。

開発者への注意

キーイベントの実装

• JavaScriptの keydown や keyup イベントを使用してショートカットを実装する際、input 要素や textarea 要素の中にフォーカスがあるときはショートカットが動作しないように制御する（これは一般的なマナーだが、本基準でも重要）。

設定保存の仕組み

• 利用者がショートカットを「無効」または「再割り当て」した設定を、ブラウザの localStorage やサーバー側に保存し、次回のアクセス時にも維持されるように実装する。

今のWeb環境で気をつけたい点

• 音声認識ソフトとの干渉：音声入力を利用する人が「Hello」と言った際、もし「H」が「ホームへ移動」というショートカットに割り当てられていると、入力しようとした瞬間にページが遷移してしまいます。これが「文字キー単体」のショートカットが注意点として挙げられる大きな理由です。
• Webアプリ（SaaS）の普及：Google GMailの「j」「k」による移動や、Slackの「k」によるダイレクトメッセージ検索など、高度なWebアプリでは便利な機能ですが、これらも設定からオフにできるよう設計されています。自社開発のツールでも同様の配慮が必要です。
• ブラウザ標準機能との衝突：ブラウザ自身が持つショートカットや、スクリーンリーダーなどの支援技術が予約しているキー操作を奪わないよう、慎重に設計する必要があります。

参考リンク

解説書 達成基準 2.1.4: 文字キーのショートカット

目次へ戻る