音声入力・スイッチ操作・代替入力のアクセシビリティ：マウス以外で“操作できる”UIを作る実務ガイド（WCAG 2.1 AA）

概要サマリー（先に要点）

• Webは「マウスでクリックできる」だけでは不十分ですの。音声入力、スイッチ操作、視線入力、キーボードのみなど、多様な入力手段で同じ目的を達成できることがアクセシビリティの核心です。
• 基本戦略はとてもシンプルで、①ネイティブHTML ②キーボード完全対応 ③ラベルの一致 ④ターゲットサイズ ⑤時間・ドラッグ・複雑ジェスチャの代替を揃えること。
• 音声入力では、ボタン名やラベルが曖昧だと「押せない」。スイッチ操作では、フォーカス順序や余計なフォーカス要素があると「たどり着けない」。この違いを理解すると設計が一気に安定します。
• WCAG 2.1 AA に加えて、近年重要性が増している **2.5.x（入力モダリティ）**の実務対策（ドラッグ代替、複雑ジェスチャ回避、誤タップ防止）を中心にまとめます。

対象読者（具体）：フロントエンドエンジニア、UI/UXデザイナー、業務システム開発者、自治体/公共サイト担当、EC/予約サービス運用者、QA、アクセシビリティ担当
アクセシビリティレベル：WCAG 2.1 AA 準拠を目標（関連：2.1.x、2.4.x、2.5.x、3.3.x、4.1.2）

1. はじめに：入力手段が違うと、同じUIでも“できる/できない”が変わる

音声で操作する方、スイッチ（1つのボタン）で操作する方、視線入力を使う方、トラックボールや片手キーボードの方……入力手段が違うだけで、同じサイトが突然「操作できないもの」になることがあります。
たとえば、マウスなら押せる小さな×ボタンが、スイッチ操作ではフォーカスが当たらず到達できない。音声入力では「閉じる」と言っても、ボタン名が「icon」だと認識されず押せない。
アクセシビリティは、こうした“入力の多様性”を前提に、同じゴールへ到達できる道を複数用意することですの。この記事では、代替入力の観点からUIを点検し、直すための具体策を整理しますね。

2. 代替入力の全体像：代表的な入力手段と“困りポイント”

2.1 音声入力（Voice Control 等）

• ラベルの一致が命：ボタンの名前が曖昧だと呼び出せない
• 画面上の要素が多いと、候補番号が増えて操作が難しくなる
• 「同じ名前のボタン」が複数あると混乱が増える

2.2 スイッチ操作（Switch Control 等）

• フォーカス順序が論理的でないと、永遠にたどり着けない
• 無駄なフォーカス要素が多いと時間がかかり疲労する
• モーダルのフォーカストラップがないと迷子になる

2.3 視線入力・ヘッドトラッキング

• 小さすぎるターゲットは誤選択を誘発
• 隣接するボタンの距離が近いと操作困難
• Hover依存のUIが使いづらい

2.4 キーボードのみ

• Tabで到達できない要素があると致命的
• ドラッグ&ドロップや複雑なジェスチャは代替が必要
• フォーカス可視がないと自分の位置が分からない

3. 基本戦略：まずここを整えれば“多くの代替入力”が一気に救われる

3.1 ネイティブHTMLを使う（最重要）

• button は button
• a は link
• label と input は必ず紐付け
  これだけで、音声入力・スイッチ操作・読み上げが大きく改善しますの。

例：アイコンボタン

<button type="button" aria-label="閉じる">
  <img src="close.svg" alt="">
</button>

• 音声入力：ユーザーが「閉じるをタップ」と言える
• スイッチ：フォーカスが当たり、Enterで操作できる

3.2 フォーカス順序を論理順に（DOM順が基本）

• 見た目の順とTab順が一致
• tabindex の正値（1,2,3…）は原則禁止
• 余計なフォーカス要素を作らない（装飾リンクなど）

3.3 フォーカス可視は太く、常に見える

focus-visible でキーボード時に明確に。

:focus-visible{
  outline:3px solid #FF9900;
  outline-offset:3px;
}

3.4 ターゲットサイズを確保（誤操作を減らす）

目安：高さ・幅ともに 44px相当。
ボタン周辺の余白も含めて押せる面積を作ります。

4. 音声入力に強いUI：ラベル設計と重複回避

4.1 可視ラベルとアクセシブルネームの一致

音声入力は、画面に見えている言葉でコマンドを出すことが多いです。
だから、可視ラベルと aria-label が違うと混乱しますの。

• 悪い：画面は「送信」、読み上げ名は「submit」
• 良い：どちらも「送信」

4.2 “同名ボタン”を避ける（詳細、こちら、開く…）

音声で「詳細を押す」と言ったとき、候補が10個出ると操作が難しくなります。
解決策：動詞＋目的語にします。

• 「詳細」→「注文の詳細」
• 「開く」→「通知設定を開く」
• 「こちら」→「料金表を見る」

4.3 近接ボタンの間隔と誤操作

音声入力でも視線入力でも、ボタンが密集していると誤操作が増えます。

• ボタン間の余白を増やす
• 重要操作は配置を分ける（削除ボタンは近づけない）

5. スイッチ操作に強いUI：フォーカスの旅路を短くする

スイッチ操作は、フォーカスが順番に移動し、ユーザーがタイミングよく選びます。
つまり、フォーカスが

• 多すぎる
• 順序が変
• 見えない
  だと、操作が成り立ちませんの。

5.1 フォーカス可能要素を減らす（意味のないTab停止を作らない）

• 装飾リンク
• 無意味なtabindex="0"
• クリックできないのにフォーカスできる要素
  これらは削ります。

5.2 ロービングTabIndexで“領域内移動”を矢印に分離

タブやメニュー、リストボックスなどは

• Tab：コンポーネント間
• 矢印：コンポーネント内
  にすると、スイッチ操作でも負担が減ります。

5.3 モーダルは必ずフォーカストラップ＋復帰

• 開いたらモーダル内へ
• 背景へ逃げない
• 閉じたら元のボタンへ戻る
  これはスイッチ操作で特に重要ですわ。

6. ドラッグ＆ドロップ、複雑ジェスチャの代替（WCAG 2.5系）

6.1 ドラッグ操作の代替を必ず用意

例：並び替え

• ドラッグの代わりに「上へ」「下へ」ボタン
• キーボードで移動できるショートカット
• 位置を数値入力できる

サンプル（概念）

<button aria-label="1つ上へ移動">↑</button>
<button aria-label="1つ下へ移動">↓</button>

6.2 ピンチ・スワイプ必須は避ける

• 「スワイプしないと閉じられない」などはNG
• 必ずボタン操作（閉じる、戻る）を併設

6.3 時間制限がある操作は延長・停止を

スイッチ操作や音声入力は時間がかかりやすいです。

• セッション切れ
• 入力フォームのタイムアウト
  は、延長の導線が必要ですわ。

7. クリック/タップ以外のイベントに依存しない

7.1 mouseover だけで表示しない

ホバーで出る情報は、フォーカスでも出るように。

• ツールチップ
• メガメニュー
• 補助説明

7.2 pointerdown だけで確定しない

誤作動が増えます。基本は click で確定し、Enter/Spaceにも対応します。

8. チェックリスト（5分）：代替入力の最小確認

1. Tabだけで主要タスクが完遂できる
2. フォーカスが常に見える
3. ボタン名が具体的（「詳細」だけで終わらない）
4. 同名ボタンが多すぎない
5. ターゲットサイズが十分（44px相当）
6. ドラッグに代替操作（上下ボタン等）がある
7. モーダルがトラップ＋Esc＋復帰で動く
8. ホバー依存UIがフォーカスでも表示される
9. フォームのタイムアウトに延長がある（該当する場合）

9. ケーススタディ：並び替えUIを“誰でも操作できる”にする

Before

• ドラッグでしか並び替えできない
• 位置が分からない
• スイッチ操作で不可能

After

• 各行に「上へ」「下へ」ボタン
• “いま何番目”をテキストで表示（例：3/10）
• 移動後に role="status" で「3番目に移動しました」と通知
  これだけで、キーボード・音声入力・スイッチ操作のすべてで成立しますわ。

10. 対象読者にとっての価値（具体）

• 肢体不自由でスイッチを使う方：主要機能に到達でき、疲労が減る。
• 音声入力を使う方：ボタン名が明確で、指示が通りやすい。
• 視線入力の方：押し間違いが減り、操作が安定する。
• 高齢者：細かい操作が減り、誤タップが減る。
• 開発チーム：ネイティブ要素と標準化で回帰が減り、品質が守りやすい。

11. アクセシビリティレベルの評価（本記事の到達点）

• WCAG 2.1 AA（中心）
  • 2.1.1 キーボード：代替入力の基盤
  • 2.4.3 フォーカス順序 / 2.4.7 フォーカス可視
  • 2.5.1 ポインタジェスチャ：複雑ジェスチャ依存の回避
  • 2.5.2 ポインタキャンセル：誤操作の低減
  • 2.5.3 ラベル名の一致：音声入力で特に重要
  • 1.3.1 情報と関係：フォーム・リスト・構造
  • 3.3.x 入力支援：入力負荷を減らす
  • 4.1.2 名前・役割・値：UIの意味を正しく伝える
• 代替入力の配慮は、単に特定の人のためではなく、**“手がふさがっている”“移動中”“怪我をした”**など状況的制約にも強く効きます。

12. まとめ：マウス以外でも“同じゴールへ”行ける設計を

1. ネイティブHTML＋キーボード完全対応は、代替入力の土台。
2. ラベルを具体的にして、音声入力で呼び出せるUIにする。
3. フォーカス順序とフォーカス可視で、スイッチ操作を成立させる。
4. ターゲットサイズと余白で誤操作を減らす。
5. ドラッグや複雑ジェスチャには代替操作を必ず用意する。
6. 5分チェックを習慣化し、更新で崩れない体制にする。

入力手段が変わっても、できることが変わらない。
それは“特別な配慮”ではなく、誰にとっても安心できる品質ですわ。
あなたのプロダクトが、どんな人の手（そして声）にも自然になじむように、心を込めて応援しますね。