キーボードで使えるナビゲーション設計ガイド：フォーカス順とUI実装の基本

キーボードだけでWebサイトを操作するとき、利用者はTabキーでリンクやボタンを移動し、EnterキーやSpaceキーで選択します。

この操作が途中で止まる、現在位置が見えない、表示の順番と移動順が食い違うと、目的の情報や機能へ到達できません。

本記事では、一般的なサイトナビゲーションを中心に、フォーカス順、スキップリンク、開閉メニュー、タブ、モーダルの設計と確認方法を整理します。

キーボード操作で使う二つの基本用語

フォーカスとは、次のキー入力を受け取る要素を示す状態です。

リンク、ボタン、入力欄などへTabキーで移動すると、通常は輪郭や背景色の変化によって現在位置が示されます。

Tab順序とは、TabキーとShift＋Tabキーでフォーカスが移る順番です。

見た目だけではなく、内容の意味と操作の流れに沿って移動できることが求められます。

なお、キーボード操作は、物理キーボードを使う人だけのための設計ではありません。

スクリーンリーダー、音声入力、スイッチ入力など、キーボード相当の操作を利用する支援技術にも関係します。

ナビゲーション設計の三原則

「DOM順と視覚順を常に完全一致させる」という機械的なルールではありません。

複数の順序が考えられる場合でも、意味と操作性を保ち、利用者が次の移動先を予測できることが判断基準です。

まず標準HTMLで操作の土台を作る

リンクとボタンを役割で使い分ける

別のページや場所へ移動する要素には<a href="...">、開閉や送信などの処理を実行する要素には<button>を使います。

標準HTMLの要素には、ブラウザが提供するフォーカス機能とキー操作が備わっています。

<div role="button">を使うと、フォーカス、Enterキー、Spaceキー、無効状態などを実装側で補う必要があるため、標準要素を選べない理由がある場合に限ります。

役割の判断例は、リンクとボタンを使い分ける実装ガイドでも確認できます。

tabindexは0と-1を目的別に使う

• tabindex="0"：要素を文書内の自然なTab順序に加えます。標準HTMLで足りる場合は追加しません。
• tabindex="-1"：Tabキーでは到達させず、スクリプトやページ内リンクからフォーカスを移す対象に使います。
• 正の値：独自の優先順を作るため、HTMLの変更に追従しにくくなります。原則として使いません。

Tab順序を直すときは、正のtabindexで上書きする前にHTMLの並びを見直します。

フォーカス表示を消さない

:focus-visibleを使うと、ブラウザがキーボード操作などで表示が必要だと判断した場面にフォーカススタイルを適用できます。

a:focus-visible,
button:focus-visible,
input:focus-visible,
select:focus-visible,
textarea:focus-visible {
  outline: 3px solid #0b57d0;
  outline-offset: 3px;
}

色だけに頼らず、輪郭の太さや位置の変化でも現在位置を示します。

固定ヘッダー、Cookieバナー、追従ボタンなどが、フォーカスされた要素を完全に隠していないかも確認します。

フォーカスの設計と検証を詳しく確認する場合は、キーボード操作とフォーカス表示の実務ポイントが参考になります。

スキップリンクとページ構造で移動を短くする

全ページで長いヘッダーやナビゲーションを繰り返し通過させると、本文へ着くまでのキー操作が増えます。

スキップリンクは、ページ先頭から主要な本文へ直接移動するためのリンクです。

<a class="skip-link" href="#main-content">本文へスキップ</a>

<header>...</header>
<nav aria-label="主なナビゲーション">...</nav>
<main id="main-content" tabindex="-1">...</main>

スキップリンクは、最初のTab操作で見えるようにします。

リンク先へ移動したあと、フォーカス位置も本文へ移ったことを実機で確認します。

<header>、<nav>、<main>、<footer>などの要素と、内容を示す見出しを併用すると、支援技術からページの区切りを把握しやすくなります。

サイトナビゲーションは開閉UIとして設計する

一般的なWebサイトのナビゲーションは、デスクトップアプリの「メニュー」と同じものではありません。

通常は<nav>、リスト、リンクを使い、サブナビゲーションを開く要素だけをボタンにします。

role="menu"やrole="menubar"を付けると、利用者はアプリケーションメニューに近い矢印キー操作を期待します。

その操作モデルを実装しない通常のサイトナビゲーションには付けません。

開閉ボタンに必要な状態

<nav aria-label="主なナビゲーション">
  <ul>
    <li>
      <button type="button"
        aria-expanded="false"
        aria-controls="services-nav">
        サービス
      </button>
      <ul id="services-nav" hidden>
        <li><a href="/service-a/">サービスA</a></li>
        <li><a href="/service-b/">サービスB</a></li>
      </ul>
    </li>
    <li><a href="/contact/">お問い合わせ</a></li>
  </ul>
</nav>

aria-expandedは開閉状態を伝え、aria-controlsは操作対象との関係を示します。

表示中のサブナビゲーションはTabキーで移動でき、閉じている間はフォーカス対象から外します。

キー操作を仕様書に書く

矢印キーによる項目移動は、通常のサイトナビゲーションに必須ではありません。

アプリケーションメニューとしてmenuやmenubarを実装する場合は、ARIA Authoring Practices Guideのキー操作モデルを一式で実装します。

複合コンポーネントのフォーカス管理

タブはTabキーと矢印キーの役割を分ける

ロービングtabindexとは、複数の選択肢のうち一つだけをTab順序に置き、内部の移動を矢印キーで行う方法です。

• Tab：選択中のタブへ入り、次のTab操作でタブリストの外へ出ます。
• 左右矢印：水平タブの前後へ移動します。
• 上下矢印：aria-orientation="vertical"を指定した垂直タブの前後へ移動します。
• Enter、Space：手動選択方式のタブを有効にします。
• Home、End：先頭または末尾へ移動します。これは任意の操作です。

水平タブで上下矢印まで奪うと、ページのスクロールを妨げる場合があります。

パネルを即座に表示できるなら、フォーカス移動と同時に選択しても構いません。

読み込みに時間がかかる場合は、矢印キーでフォーカスだけを動かし、EnterキーまたはSpaceキーで選択する方式にします。

アコーディオンは見出し内のボタンで開閉する

<h3>
  <button type="button"
    aria-expanded="false"
    aria-controls="shipping-panel"
    id="shipping-heading">
    配送について
  </button>
</h3>
<div id="shipping-panel"
  aria-labelledby="shipping-heading"
  hidden>
  <p>配送条件を説明します。</p>
</div>

見出しは内容の位置を示し、ボタンは開閉操作を担当します。

開閉のたびにaria-expandedとhiddenの状態を同期します。

モーダルとナビゲーションドロワーを区別する

モーダルとは、閉じるまで背景の内容を操作できない重ね合わせ画面です。

モーダルとして扱う場合は、開いたときに内部へフォーカスを移し、TabキーとShift＋Tabキーを内部で循環させ、Escapeキーで閉じ、閉じたあとは原則として起点へフォーカスを戻します。

aria-modal="true"は、視覚的にも操作上も背景を利用できない場合にだけ指定します。

画面端から出るナビゲーションドロワーであっても、背景を操作できる設計なら、モーダルの属性やフォーカストラップを無条件に付けません。

見た目ではなく、背景を操作できるかどうかで判断します。

候補リストと通知はフォーカスを奪わない

検索候補を表示するコンボボックスでは、入力欄、候補リスト、現在の候補の関係を示し、上下矢印、Enter、Escapeの動作を定めます。

操作結果を伝える通知では、通常はフォーカスを通知へ移さず、role="status"や適切なライブリージョンで変化を伝えます。

緊急性の低い通知にrole="alert"を多用すると、読み上げを中断させる場合があります。

通知の実装は、ステータスメッセージとaria-liveの使い分けで詳しく解説しています。

SPAの画面遷移では変化を利用者へ伝える

SPAではURLと表示内容が変わっても、ブラウザによる通常のページ読み込みが起こりません。

そのため、画面タイトルを更新し、遷移先の主見出しや本文開始位置へフォーカスを移すなど、利用者が新しい画面へ移ったと分かる方法を設計します。

毎回同じ場所へ機械的に移すのではなく、遷移の起点と次の作業を考えて移動先を決めます。

読み上げの確認では、スクリーンリーダーの仕組みと実装ポイントも参考になります。

WCAG 2.2で確認する達成基準

現行のW3C勧告であるWCAG 2.2を基準にすると、キーボードナビゲーションには次の達成基準が関係します。

これらを満たすだけで、ページやサイト全体のAA適合が確定するわけではありません。

WCAG 2.2の追加基準と適合範囲は、WCAG 2.2で追加された達成基準の解説も併せて確認してください。

キーボードだけで行う手動テスト

1. マウスやトラックパッドを使わず、ページを再読み込みします。
2. 最初のTab操作でスキップリンクが見え、本文へ移動できるか確認します。
3. Tabキーでヘッダー、ナビゲーション、本文、フッターを順に巡回します。
4. Shift＋Tabキーで逆方向にも戻り、順序が破綻しないか確認します。
5. すべての位置でフォーカス表示を確認し、固定表示に隠れないか見ます。
6. リンクはEnterキー、ボタンはEnterキーとSpaceキーで操作します。
7. 開閉UIを開き、内部へ移動し、閉じたあとのフォーカス位置を確認します。
8. タブやコンボボックスでは、定めた矢印キー、Home、End、Escapeの動作を確認します。
9. モーダルでは、内部のTab循環、Escapeによる終了、起点への復帰を確認します。
10. 可能であれば、対象利用者が使うブラウザとスクリーンリーダーの組み合わせでも確認します。

自動検査は、属性の不足や一部の構文エラーを見つける助けになります。

実際の移動順、フォーカスの見え方、開閉後の位置は、キーボードを使った手動確認が必要です。

設計から回帰テストまでの運用

• 設計：各コンポーネントについて、Tab順序、内部キー操作、開閉時のフォーカス移動、終了方法を表にします。
• 実装：標準HTMLを優先し、ARIAは不足する名前、役割、状態を補うために使います。
• レビュー：見た目だけでなく、Tabキー、Shift＋Tabキー、Enterキー、Spaceキー、Escapeキーで確認します。
• 回帰テスト：ナビゲーション、固定ヘッダー、モーダルなどを変更したときに、手動テストを再実施します。

キー操作を実装担当者の判断だけに置くと、似た部品の挙動が分かれます。

デザイン仕様、実装仕様、テスト項目で同じ操作を参照できる状態にすると、改修後も確認を続けやすくなります。

公式仕様と実装パターン

• W3C「Web Content Accessibility Guidelines (WCAG) 2.2」
• W3C WAI「Developing a Keyboard Interface」
• W3C WAI「Menu Structure」
• W3C WAI「Disclosure Pattern」
• W3C WAI「Tabs Pattern」
• W3C WAI「Dialog (Modal) Pattern」

ARIA Authoring Practices Guideの例は、そのまま貼り付ける完成品ではなく、パターンを理解するための参考実装です。

対象ブラウザと支援技術で動作を確認してから採用します。

迷わない操作は順序、表示、終了方法で決まる

キーボードナビゲーションでは、すべての機能へ到達できるだけでは足りません。

意味に沿って移動し、現在位置を確認でき、開いた部品から標準的な方法で戻れることまでを一つの仕様として設計します。

まず標準HTMLを選び、複合コンポーネントにだけ必要なフォーカス管理を加え、最後にキーボードだけで一連の操作を確かめてください。