WCAG 2.2の達成基準2.5.6「同時入力メカニズム」は、端末で利用できる入力方法をウェブコンテンツ側が不必要に制限しないことを求めるLevel AAAの基準です。
ここでいう入力方法には、キーボード、マウス、トラックパッド、タッチ、スタイラス、音声操作などが含まれます。大切なのは、最初に検出した方法へ操作を固定せず、利用者が状況に応じて別の方法へ切り替えられることです。WCAG全体の位置づけを先に確認したい場合は、WCAG 2.2の全体像も参照してください。
「同時入力メカニズム」が求めること
入力モダリティとは、利用者が端末へ情報や指示を入力する方法の種類です。2.5.6は、端末に複数の入力モダリティがあるとき、コンテンツがその一部を理由なく使えなくすることを防ぎます。
これは「考えられるすべての入力機器へ個別対応しなければならない」という意味ではありません。プラットフォームとブラウザーが利用できる入力方法を、サイトの判定やイベント処理によって排除しないことが中心です。
たとえば、タッチ対応のノートパソコンでは、画面へのタッチだけでなく、キーボードやトラックパッドも使えます。メニューをマウスで開いたあとに矢印キーで項目を移動するように、一つの操作の途中で入力方法が変わる場合もあります。
制限が認められる三つの例外
入力方法の制限が認められるのは、次のいずれかに該当する場合です。
- 本質的に必要な場合：制限をなくすと、情報や機能そのものが成り立たず、適合する別の方法でも同じ目的を実現できない場合です。
- コンテンツのセキュリティ確保に必要な場合：安全性を保つため、その制限が必要な場合です。
- 利用者の設定を尊重するために必要な場合：利用者が選んだ設定に従うため、その入力方法に合わせる必要がある場合です。
単に実装しやすいことや、特定の端末を主な対象にしていることは、この三つの例外を示す理由にはなりません。
実装で確認したいポイント
標準のHTML要素を優先する
ボタン、リンク、入力欄などは、役割に合う標準のHTML要素を使います。標準のボタンであれば、マウスやタッチだけでなく、キーボードからも操作できます。
<button type="button" id="submitButton">送信</button>標準のボタンを使えば、ブラウザーが各入力方法からの操作を処理します。独自のキー処理を重ねる場合は、同じ操作が二重に実行されないかを確認します。キーボード対応の基礎は、WCAG 2.2「2.1.1 キーボード操作」の実装とテストで詳しく解説しています。
入力方法を検出しても専用UIへ固定しない
タッチ機能の有無を検出し、その結果だけで「タッチ専用UI」と「マウス専用UI」を切り替える実装は避けます。タッチ画面がある端末でも、外付けのキーボードやマウスを併用することがあるからです。
入力方法によって表示や補助機能を調整する場合でも、ほかの方法で主要な操作を続けられるかを確認します。ページを開いたあとに入力機器を接続した場合も、再読み込みを求めず操作できる設計が望まれます。
カスタムUIは入力方法ごとに操作を確認する
div要素だけで作ったボタンや、マウスまたはタッチの一方だけに依存する部品は、別の入力方法を取りこぼしやすくなります。カスタムUIが必要な場合は、ポインター操作とキーボード操作の両方を用意し、役割、名前、状態、フォーカスの移動も整えます。
ドラッグや複雑なジェスチャーを使う機能では、同時入力メカニズムだけでなく、関連するポインター操作のジェスチャーに関する要件も確認すると、操作方法の抜けを見つけやすくなります。
よくある失敗と修正方針
| 失敗しやすい実装 | 起こる問題 | 修正方針 |
|---|---|---|
| タッチ画面を検出するとタッチ専用の操作だけを表示する | 同じ端末のキーボードやマウスを使えない | ほかの入力方法でも同じ機能へ到達できるようにする |
| マウス専用の処理だけで操作を開始する | タッチやキーボードから処理を実行できない | 標準要素を優先し、必要な代替操作を用意する |
| 最初に使われた入力方法を記録し、その後も固定する | 操作の途中で入力方法を切り替えられない | 現在の操作方法を排他的な条件として扱わない |
| ポインターで操作したあとにフォーカスを失わせる | 続きの操作をキーボードで行いにくい | 入力方法を切り替えたあとも、操作対象と現在位置が分かるようにする |
手動テストの進め方
2.5.6は、端末に複数の入力方法がある状態で、実際に切り替えながら確認します。次の順番で試すと、入力方法を固定している箇所を見つけやすくなります。
- タッチ画面とキーボード、マウスなど、二つ以上の入力方法を使える環境を用意します。
- メニュー、ダイアログ、フォーム、スライダーなど、すべての対話要素を入力方法ごとに操作します。
- マウスでメニューを開いてキーボードで項目を選ぶなど、一連の操作の途中で入力方法を切り替えます。
- 可能であれば、ページを開いたあとに外付け入力機器を接続し、そのまま操作できるか確認します。
- タッチ機能の検出によって、ほかの入力方法で必要な部品が非表示になっていないか確認します。
- 操作後のフォーカス位置、表示状態、実行結果が入力方法によって不自然に変わらないか確認します。
自動チェックツールは、要素の役割や一部のキーボード操作の問題を見つける補助にはなりますが、入力方法を途中で切り替えられることまでは確認できません。そのため、2.5.6の評価では手動テストを省けません。サイト全体の確認手順は、ウェブアクセシビリティチェックの進め方も参考にしてください。
実装とテストの要点
- 利用可能な入力方法をサイト側の判定で排除しない。
- 標準のHTML要素と入力方法に依存しにくいイベントを優先する。
- 一つの操作の途中でも、キーボード、マウス、タッチなどを切り替えて確認する。
- 例外を適用する場合は、本質性、セキュリティ、利用者設定のどれに当たるかを明確にする。
当社では、ウェブアクセシビリティを簡単に導入できるUUU ウェブアクセシビリティをリリースしております。アクセシビリティ向上にご興味がある方は、詳細をご覧ください。