代表的な面接トピック

フロントエンド面接:キーボード操作に対応したコマンドパレットの設計

フロントエンド普通
Offer.cc 編集チーム公開日 更新日

質問

ユーザーがキーボードで開く、検索する、実行することができるコマンドパレットを設計してください。フォーカスの移動、ショートカットの競合、動的な結果に対するアナウンス、およびアクセシビリティテストについて説明してください。

プロンプトと適用範囲

このフロントエンドの質問では、複雑なインタラクションのキーボードモデルとアクセシビリティが問われます。単にいくつかのkeydownハンドラを割り当てるだけでなく、開く、検索する、選択する、実行する、閉じる、フォーカスを復元するという完全なステートマシンを定義し、適切なrole、name、およびstateをスクリーンリーダーに公開してください。

面接官が評価している点

  • dialog、combobox、listbox、menuのセマンティクスを区別できているか。
  • Tab、矢印キー、Enter、Escape、Home、Endが一貫した動作をしているか。
  • フォーカスの視認性、復元、動的な結果、ローディング、およびエラーが処理されているか。
  • グローバルショートカットが入力欄、支援技術、またはブラウザのデフォルト操作を奪わないように配慮されているか。

最初に尋ねるべき明確化のための質問

コマンドがグループ化されているか、最近使用したものか、非同期で検索されるか、モバイルに別のエントリポイントがあるか、ショートカットを設定可能にするか、実行によってページ遷移、ダイアログの表示、またはページ状態の変更が発生するかを確認します。また、マウスやタッチのサポート、結果の件数制限、許容される読み込み遅延についても確認してください。

30秒での回答構成

inputとresultsの周囲に名前付きのモーダルdialogを使用し、comboboxとlistboxの明示的な関係を持たせます。起動元を保存して開いたときにinputへフォーカスを当てます。矢印キーでアクティブな項目を移動し、Enterで実行し、Escapeで閉じてフォーカスを復元します。結果の状態変化をアナウンスし、安全なコンテキストでのみショートカットをトリガーし、キーボード、スクリーンリーダー、自動テストですべての遷移をテストします。

詳細な回答

1. セマンティックの境界を選択する

外側には名前付きのdialogを使用し、インタラクションがそれを必要とする場合はinputにcomboboxセマンティクス、結果にはlistbox、選択肢にはoptionを使用します。階層構造のコマンドには、いたるところにrole="menuitem"を追加するのではなく、menuパターンに従います。ARIAは実際の動作を説明するものであるべきで、不適切なDOM構造を覆い隠すためのものではありません。

2. フォーカスとキーボードのステートマシンを設計する

起動元を記録し、開いたときにinputにフォーカスを合わせます。矢印キーで結果内を移動し、HomeとEndで両端にジャンプし、Enterで現在の項目を実行し、Escapeで閉じます。Tabの動作は選択したパターンと一致している必要があり、dialogの背面にフォーカスが外れないようにしなければなりません。閉じる際、失敗時、または遷移時には、起動元または適切なターゲットにフォーカスを復元します。

3. 動的な結果とアナウンスを処理する

非同期検索が結果を更新する間もinputのフォーカスを維持し、aria-activedescendantまたは実際のフォーカスを更新し、ローディング、空、エラー、および結果件数の状態を公開します。文字が入力されるたびにリスト全体を読み上げることは避け、簡潔なステータス領域を使用し、選択された名前、ショートカット、無効状態を知覚可能にします。

4. ショートカットとデフォルトの動作を制御する

開く前に、現在のフォーカス、修飾キーの組み合わせ、およびプラットフォームを確認します。入力欄、エディタ、またはスクリーンリーダーのモードからショートカットを奪わないようにしてください。ブラウザの動作を意図的に置き換える場合にのみpreventDefaultを呼び出し、コピー、貼り付け、検索、支援技術の操作を維持します。ショートカットだけが唯一のエントリにならないよう、視覚的なボタンを提供します。

5. 実行、失敗、テストを観測可能にする

実行前に選択されたコマンドを表示し、非同期処理の進行状況を公開するか重複送信を防止し、失敗時には再試行パスを用意してコンテキストを保持します。キーボードのみの操作パス、視認可能なフォーカス、フォーカストラップ、Escapeによる復元、動的な結果、ズーム、低速ネットワーク、および少なくとも1つのスクリーンリーダーでテストを行います。機密性の高い入力を記録することなく、オープン、検索、失敗、キャンセルをログに記録します。

優れた回答例

私ならinputと結果を名前付きdialogでラップします。開く際には起動元を保存してinputにフォーカスし、アクティブなoptionが明確になるようaria-controlsとaria-activedescendantでinputとlistboxを接続します。矢印キーとHome/Endで選択を移動し、Enterで実行し、Escapeで閉じてフォーカスを復元し、Tabが背面に届かないようにします。非同期検索はローディング、空、エラー状態を簡潔にアナウンスします。ショートカットはフォーカスとプラットフォームを確認し、ブラウザのデフォルトを維持し、視覚的なボタンの代替手段を持ちます。テストはキーボード、スクリーンリーダー、ズーム、低速ネットワーク、再試行、視認可能なフォーカスを網羅し、テレメトリからは機密性の高いクエリを除外します。

よくある間違い

  • 開く、閉じる、フォーカス復元の状態を定義せずにkeydownを処理すること。
  • 任意のコンテナにmenu、menuitem、またはcomboboxのroleを付与すること。
  • 動的な更新後にフォーカスが失われ、スクリーンリーダーがアクティブなオプションを識別できなくなること。
  • グローバルショートカットを捕捉して、入力、コピー/貼り付け、または支援技術の動作を損なうこと。
  • 視覚的なエントリポイントを提供せず、ユーザーにショートカットの暗記を強いること。
  • キーボード、ズーム、スクリーンリーダー、低速ネットワークではなく、マウスクリックと自動テストのみをテストすること。

フォローアップの質問

実際のフォーカスを移動すべきか、それともaria-activedescendantを使用すべきか?

構造とスクリーンリーダーのサポート状況に応じて、どちらも機能します。実際のフォーカスは直接的ですが、inputとoptionのインタラクションを管理する必要があります。aria-activedescendantはinputのフォーカスを維持しますが、安定した参照、知覚可能なoption、実機でのテストが必要です。

結果がない場合にフォーカストラップを回避するにはどうすればよいか?

inputにフォーカスを維持し、明示的な空の状態を表示し、Escape、クエリの編集、および視覚的なボタンを許可します。非インタラクティブなプレースホルダーにフォーカスを移動させてはなりません。

ナビゲーション後、フォーカスはどこへ移動するか?

遷移先は、見出しやメインコンテンツなど、適切なターゲットを選択する必要があります。ユーザーが同じページに留まる場合は、起動元またはコンテキストを復元します。失敗した場合は、クエリとエラーを表示したままパレットを開いた状態に保ちます。

ショートカットがブラウザと競合しないことをどのように確認するか?

サポートされているプラットフォームと組み合わせをリストアップし、入力欄、エディタ、フォーム、スクリーンリーダー環境でテストします。意図的に置き換える場合にのみデフォルト動作を抑止し、設定やボタンの代替手段を提供します。

公開情報ソース

関連する質問