UIデザインのキーボードフォーカス順序：タスクで設計するガイド

キーボードのフォーカス順序とは、マウスなどのポインティングデバイスを使わずに画面を操作するとき、どの部品からどの部品へ移るかという順序です。フォームへの入力、ダイアログの開閉、エラーの修正、元の場所への復帰まで、一連の作業として設計します。初期画面に番号を振るだけでは、画面が変化した後の動作までは伝わりません。

Pixsoのような共同編集できるUIデザインツールで画面を作るときは、見た目の状態とフォーカスの動きを一緒に記録しましょう。この記事では発注フォームを例に、画面へ注記する内容、コンポーネント側で決める動作、実装後にブラウザで確かめる点を整理します。

番号を並べる前に、利用者の作業を整理する

購買担当者が発注書を作成する場面を考えます。画面には仕入先、配送先、明細行、任意の備考、内容を確認する操作があります。注文内容の要約はデスクトップではフォームの横、スマートフォンでは下に配置します。利用者は仕入先を選び、配送先を確かめ、明細を入力してから確認へ進みます。関連する入力欄の途中で、突然要約の領域へ移るような順序は避けたいところです。

まず、操作する部品を意味のまとまりで分けます。仕入先と配送先は配送に関するグループ、品目、数量、単価は一つの明細行です。小計は情報であり、目立つからといって必ずTabキーで移動する対象になるわけではありません。一方、仕入先の詳細を開くリンクは操作なので、経路に含める必要があります。目に見えるラベルすべてを番号にすると、不要な移動が増えてしまいます。

WCAGのフォーカス順序の解説（英語）は、意味と操作性を保つ順序を求めています。すべての画面に共通する一つの視覚的な順序を指定しているわけではありません。レイアウトが変わるときも、番号が一直線に並ぶかではなく、利用者が内容を理解して作業を完了できるかを判断の基準にします。

Tabによる移動と、部品内の操作を分ける

Tabキーは一般に、操作できる部品の間を移動するために使います。一方、複数の要素で構成される部品では、グループ内の移動に矢印キーを使うものもあります。例えば仕入先のコンボボックスなら、候補を開く、候補間を移動する、選択を確定する、選択せずに閉じる動作を決めます。候補の一つひとつを、ページ全体のTab順序に常時含まれる項目として描かないようにしましょう。

フォーカス、選択、ホバーはそれぞれ別の意味を持つため、デザイン上でも分けて示します。仕入先が選択されたまま、キーボードのフォーカスが数量欄へ移ることはあります。両方を同じ見た目にすると、選択済みの値と現在の操作位置を取り違えやすくなります。

ダイアログは入口と出口の両方を決める

購買担当者が「配送先を変更」を実行したら、ダイアログ内の適切な位置へフォーカスを移します。内部の移動順序だけでなく、閉じた後の復帰先も必要です。短い編集フォームなら最初の入力欄が適切な場合がありますが、説明が長いダイアログでは、見出しや説明を先に確認できる位置が適しています。常に最初のボタンへ移すのではなく、その作業に必要な情報から考えます。

WAI-ARIAのモーダルダイアログのパターン（英語）では、開いているモーダルの内部にキーボード操作をとどめ、閉じた後は適切な位置に戻す動作が説明されています。「保存」「キャンセル」「Escapeキー」は別々に注記してください。保存後は発注を続けやすい場所へ戻り、キャンセルでは変更前の配送先を保ちます。

今回の例なら、「開く：住所1行目へ移動。キャンセルまたはEscape：要約を変更せず『配送先を変更』へ戻る。保存：要約を更新し、ダイアログを閉じて『配送先を変更』へ戻る」と記録します。保存によって元のボタンが画面からなくなる設計なら、残っている別の復帰先を指定します。存在しない要素を矢印で指しても、実装する動作は決まりません。

行の増減、エラー、狭い画面での変化を考える

発注フォームに「明細を追加」がある場合、実行後に新しい品目欄へ移動するか、追加ボタンにフォーカスを残すかを決めます。すぐに入力してほしいなら新しい行への移動が役立ちますが、どこに追加されたかも明確に示す必要があります。続けて複数行を追加する作業なら、ボタンに残す方が適している場合もあります。想定する作業に合わせて理由を残しましょう。

削除時も同じです。フォーカスのある削除ボタンが行と一緒になくなる場合は、次の行の対応する操作へ移す、次の行がなければ前の行へ移す、最後の行なら「明細を追加」へ移す、といった復帰先が必要です。「フォーカスを戻す」の一言ではなく、この三つの条件を分けて記録します。

「内容を確認」を実行した後に複数の入力エラーが見つかったら、利用者がそれらを把握し、該当欄へ移れる方法を用意します。エラーの要約から、未選択の仕入先や不正な数量へリンクする方法があります。一つの値を直しただけで、意図せず次のエラーへ移動させないでください。説明が更新されても、利用者が取り組んでいる操作は安定させます。

スマートフォンでは注文内容の要約が入力欄の下へ移ります。読み上げる順序とフォーカス順序を、開発者と合わせて確認しましょう。CSSで見た目の配置を変えても、文書内の順序が変わるとは限りません。デザインファイルだけでは実装後のブラウザの移動順序を証明できず、狭い画面のスクリーンショットだけでも不一致を見落とします。

Pixsoでフォーカスの仕様をまとめる

Pixsoの同じファイルに、通常の発注フォーム、配送先ダイアログ、行を追加した状態、削除した状態、入力エラーの状態を並べます。仕入先や品目の例をそろえておけば、データの違いに気を取られず操作経路を確認できます。操作できる要素の横に番号を置き、ラベルを隠さないように注記します。

状態が変わる箇所には、きっかけ、移動先、維持する情報を記入します。例えば「中央の行を削除 → 次の行の削除ボタンへ。残った明細の数量は維持」と書きます。コンボボックスなど部品内の移動には別の注記表現を使い、ページ全体のTab順序と区別します。視覚的な状態をプロトタイプでつないで流れを相談し、キーボードの動作は実装用の仕様として明記します。

未決の動作は、対象のコンポーネントや画面に結び付けます。「最後の行を削除したら、どこへフォーカスを移すか」は具体的なレビュー項目です。「アクセシブルにする」だけでは、決めることも確認方法も伝わりません。

実装された画面で、一連の操作を確かめる

先にマウスでクリックせず、キーボードだけで発注を始めます。前後に移動し、ダイアログを開閉し、行を追加・削除して、未入力のまま確認へ進みます。実際のフォーカス先と、その表示が見え続けているかを観察してください。狭い画面幅や拡大表示でも試し、固定表示のボタンなどがフォーカスのある部品を隠していないかを見ます。

問題は、開始状態、押したキー、期待した移動先、実際の移動先、作業への影響の順で記録します。ダイアログから正しく戻れたというブラウザ上の確認は、矢印が正しそうに見える画像より確かな証拠です。デザインの注記で意図をそろえ、その動作が実際に存在するかは動く画面で確認しましょう。

Pixsoで次の画面のフォーカス経路を整理する。