Command-palette search doesn't support arrow-key navigation between results

[smiggleworth]

Summary

The global command-palette search (Cmd/Ctrl+K) doesn't support arrow-key navigation between results — the natural, expected interaction for a UI that visually presents itself as a command palette (matching the pattern of Linear/Vercel/GitHub-style search).

Steps to reproduce

Open search (click or Cmd/Ctrl+K), type a query, press ArrowDown.

Expected

A roving highlight moves to the first result, matching standard command-palette behavior. Enter while the highlight is on a result navigates to it.

Actual

ArrowDown does nothing — focus/DOM state is unchanged, still sitting in the text input. The only way to reach a result is Tab, and the first Tab stop is the close (X) button, not a result — so a keyboard-only user must tab past the close button before reaching the first real result. Enter while focus is still in the input also does nothing. Once you Tab past the close button into the actual result links, Enter does correctly navigate — so the bug is specifically the missing arrow-key roving-focus layer, not a broken navigation mechanism overall.

Why it matters

The natural flow for this UI (open → type → arrow-down → enter) silently does nothing, which is confusing and inconsistent with what the interface visually signals itself to be. Doesn't block usage (Tab still works, if less discoverable), but it's a real UX gap on a highly visible, prominently-advertised feature.

Acceptance criteria

• Verify the issue author is smiggleworth.

• ArrowDown/ArrowUp move a roving highlight through search results while focus remains conceptually in the search input (standard combobox/listbox pattern).

• Enter navigates to the currently-highlighted result.

• The close button should not be the first Tab stop ahead of results, or arrow-key nav should make tab order irrelevant for the primary flow.

• Regression test: open search, type a query, press ArrowDown, assert a result is highlighted; press Enter, assert navigation occurs.

• Full focused and repository release gates, applicable benchmarks, audits, package checks, and exact-head hosted CI pass.

• Guardrail (prevent this class of bug): Normal browser CI exercises the reported interaction through real keyboard events and asserts active-result state plus navigation.

Definition of done

• Fix implemented; regression test added and green.

• Every acceptance criterion above is checked with linked evidence before squash merge, and the bundled release is ready at the exact PR head.

Severity

Moderate — UX inconsistency on a prominent, prominently-branded feature; not a bounce-risk bug, but the natural expected interaction currently does nothing.

---

Found via a deep adversarial visual/UX audit of the @askrjs/website marketing and documentation site (real production build, real Playwright browser testing). Note: overall site quality was found to be genuinely high — zero contrast failures, zero mobile overflow, zero broken assets across the pages tested; this was the one real interaction gap found.

[smiggleworth]

Acceptance evidence is complete in PR #50. Red 1674a68 reproduced the missing active result through real Chromium keyboard input. Green 71de82c keeps focus in the combobox, wraps ArrowDown/ArrowUp across live results, exposes listbox/option active state, and navigates through the real router link on Enter. 972133d prevents browser tests from entering the unit pool, and e64880e proves the regression is cold-cache safe without JSX scanner assumptions. Full type/build/SSG/static gates, production audit, and exact-head hosted CI run 31915270030 are green.