マウスなしで使えるか確かめる：自作Webツールのキーボード操作チェック

先に知っておく基本のキー操作

確認に使うキーは、ほぼ次の5つです。

• Tab：次の操作できる要素へ進む
• Shift+Tab：ひとつ前へ戻る
• Enter / Space：ボタンやリンクを実行する
• Esc：ダイアログなどを閉じる
• 矢印キー：メニューなど、まとまった部品の中で移動する

web.dev のフォーカスに関する解説によると、フォーカスの順番は「論理的で、画面の見た目の並びと合う」ことが望ましいとされています。多くの言語では通常、上から下、左から右へ、HTMLに書かれた順に進みます。

つまり、見た目だけを div やCSSで整えたツールは、見た目と実際の順番がずれやすいわけです。そこを自分の目で見つけるのが、このチェックの狙いです。

準備：確認用の「ひと通りの操作」を決める

ツール全体を見ようとすると終わりません。最初に、そのツールで一番大事な流れを1本決めます。

説明用の例：文字数カウンターなら「文章を入力する → 結果を見る → 設定ダイアログを開く → 閉じる → 結果をコピーする」です。

この流れを、マウスに一度も触れずに最後までやり切れるかを試します。途中で詰まった箇所が、直すべき場所です。

10項目のチェック表

ページを開いたら、ブラウザやOSの設定でTabキーがページ内の操作要素へ移動するようになっているか確認します（環境によっては設定変更が必要です）。ページ内の先頭で始めるには、ページをマウスでクリックしてからリロードするか、新しいタブで開き直します。そのあとはマウスを使わず、上から順に確認してください。

• 1、区分：順番、確認すること：最初のTabでどこにフォーカスが入るか、合格の目安：ページの先頭付近の操作要素に入る
• 2、区分：順番、確認すること：Tabで進む順が、画面の見た目の並びと合うか、合格の目安：上→下、左→右で自然に進む
• 3、区分：順番、確認すること：見えているボタン・リンク・入力欄すべてに到達できるか、合格の目安：取りこぼしがない
• 4、区分：表示、確認すること：今どこにフォーカスがあるか、目で分かるか、合格の目安：枠や色の変化がはっきり見える
• 5、区分：操作、確認すること：EnterまたはSpaceで、クリックと同じ結果になるか、合格の目安：ボタンが実行される
• 6、区分：順番、確認すること：Shift+Tabで逆向きに戻れるか、合格の目安：順番が逆になり、飛ばない
• 7、区分：閉じ方、確認すること：ダイアログやメニューを開いたとき、フォーカスが中に移るか、合格の目安：開いた部品の中から操作できる
• 8、区分：閉じ方、確認すること：Escまたは「閉じる」ボタンで閉じられるか、合格の目安：キーだけで閉じられる
• 9、区分：閉じ方、確認すること：閉じたあと、フォーカスが開く前の場所の近くに戻るか、合格の目安：開いたボタンの付近から再開できる
• 10、区分：脱出、確認すること：どの部品でも、Tabや案内されたキーで抜け出せるか、合格の目安：同じ場所から動けなくならない

項目ごとの見方

1〜3（順番と到達）：見えているのに止まらない要素があれば、クリック処理だけを付けた div や span などが原因の可能性があります。MDNのキーボード操作のガイドでは、<button> や <a>、<input> などの標準要素は最初からフォーカスでき、基本的なキー操作にも対応するため、まずこちらを使う方針が示されています。独自部品にする場合は、フォーカス可能にするだけでなく、適切なキー操作も実装する必要があります。

また、tabindex に1以上の数字を付けると順番が乱れやすいため、web.dev は避けるよう勧めています。項目2で順番がおかしいときは、まずこの数字が書かれていないか探してください。

4（フォーカス表示）：枠が見えないときは、CSSで outline: none を指定している可能性があります。web.dev はこの指定がブラウザー標準のフォーカス表示を消すことに注意を促しています。独自の表示にする場合、形や背景の変化など色だけに頼らない方法が使えます。フォーカス表示のコントラスト比3:1以上はWCAG 2.2のフォーカス表示（最低限）の基準です。

5（実行キー）：標準の <button> はEnterとSpaceで実行できます。効かない場合は、ブラウザー設定や部品の実装も確認してください。

7〜9（開閉）：<dialog> 要素を showModal() で開くと、MDNによれば周囲が操作不能になり、Escで閉じられます（MDN: dialog）。開いた直後のフォーカスは、中の最初の操作要素に入るとは限らず、初期フォーカスの配置はダイアログの内容に応じて検討します。閉じた後のフォーカスは、showModal()で開いた場合、通常は開く操作をした要素に戻ります。独自実装では、開閉後のフォーカス位置を確認してください。

10（脱出）：W3CのNo Keyboard Trap（達成基準2.1.2、レベルA）は、キーボードでフォーカスが入った部品から、キーだけで離れられることを求めています。モーダルダイアログの中にフォーカスを留めること自体は問題ではありません。Escなどで閉じるか、案内されたキー操作で外へ移動できることを確認します。出口のない状態が「トラップ」です。

結果の記録のしかた

チェック表を、そのままメモにして使えます。説明用の例を示します（実際に測った結果ではありません）。

項目4：検索ボタンにフォーカスが来ても枠が見えない → 不合格
項目8：設定ダイアログがEscで閉じない → 不合格
項目9：閉じたあと先頭に戻る → 要改善

不合格の行が、そのままAIへの修正依頼の材料になります。

AIに任せる部分と、自分で確かめる部分

AIはコードを読んで、怪しい書き方を指摘するのが得意です。ただしAIはブラウザで実際に押してはいません。「たぶん動きます」という答えは確認済みの扱いにせず、必ず自分のTabキーで再確認してください。

依頼文の例

下の文は説明用の例です。【　】の部分を置き換えて使います。

次のHTML/CSS/JavaScriptを、キーボードだけで操作できるかという観点で点検してください。

点検してほしいこと：
1. クリック処理があるのに button / a / input ではない要素
2. outline: none など、フォーカス表示を消している箇所
3. tabindex に1以上の数字を付けている箇所
4. ダイアログやメニューを開く・閉じる処理で、Escキーと
   フォーカスの戻り先が考えられているか

出力形式：問題の箇所、理由、直し方の案を表で。
最後に、私がTabキーで確認すべき手順も3つ挙げてください。
実際に動かして確認したとは書かないでください。

【ここにコードを貼る】

貼るコードにAPIキー、パスワード、個人情報、社外秘の文章が混ざっていないか、送る前に確認してください。必要なら YOUR_KEY のようなダミーに置き換えます。

人が最後に見ること

AIが直したコードを受け取ったら、チェック表の10項目をもう一度最初からやり直します。1か所を直して別の場所の順番が変わることがあるためです。スマホ向けの画面に切り替えて、表示が変わる部分も同じ流れで確認します。

詰まりやすい場面と直す方向

• 見えているボタンにTabで止まらない、疑う場所：div にクリック処理だけがある、直す方向：<button> に置き換える
• どこにいるか分からない、疑う場所：outline: none、直す方向：:focus-visible で見える枠を指定する
• 順番が飛ぶ、疑う場所：tabindex="2" など、直す方向：数字を外し、HTMLの並びを直す
• ダイアログがEscで閉じない、疑う場所：自作の表示切替、直す方向：<dialog> と showModal() を検討する
• 閉じたら先頭に戻る、疑う場所：戻り先の処理がない、直す方向：開いたボタンへ focus() で戻す

最後の行の focus() は、ブラウザーで使えるJavaScriptの標準的な呼び出しです。実際に自作ツールで試してから反映してください。

まとめの代わりに：最小の確認手順

1. マウスから手を離し、ページ内でTabを押す
2. 決めておいた「ひと通りの操作」を最後まで行う
3. 10項目の表に○×を付ける
4. ×の行をAIに渡して修正案をもらう
5. 直したあと、最初からもう一度やり直す

この5手順は、ページを更新するたびに数分で繰り返せます。