Keyboard behavior
Every key the widget responds to, and why focus never leaves the input.
The widget follows the combobox pattern: focus stays in the text input the entire time, and the keyboard moves a highlight over the results rather than moving focus onto them.
| Key | Does |
|---|---|
The hotkey (default cmd+k / ctrl+k) | Opens the modal from anywhere on the page |
↑ / ↓ | Moves the highlighted result up or down, wrapping at the ends |
↵ | Opens the highlighted result |
⌘↵ / ctrl+↵ | Opens the highlighted result in a new tab |
esc | Closes the modal; in inline mode, clears the query first, then blurs |
Tab | Moves focus out of the widget entirely (the widget does not trap Tab) |
Why focus stays in the input
Moving focus onto each result as you press ↓ would fire a blur/focus cycle on every keystroke and confuse screen reader users mid-navigation. Instead, the input keeps focus throughout, and aria-activedescendant points at the currently highlighted result — see Accessibility for how this is exposed to assistive technology.
Typing while a result is highlighted
Typing a character while a result is highlighted always continues the query in the input — it never gets captured by the highlighted row. Only the keys listed above are intercepted; every other keystroke reaches the input normally, including while composing CJK input (see IME behavior).
Mobile
The mobile sheet keeps the same ↑/↓/↵ behavior for an attached hardware keyboard, and adds a persistent, always-visible Cancel control as the touch equivalent of esc.