Keyboard up/down and confirm must work
Aliases: ARIA combobox · typeahead keys · mouse-only suggestions
What it is
Once suggestions are open, the hands should not have to leave the keyboard to hit a row. Combobox keyboard selection moves highlight with the arrow keys and writes the highlighted item into the slot on Enter (or Tab, by convention). If only a mouse can click a suggestion, keyboard users treat the list as decoration or submit the incomplete prefix in the slot. The issue is whether a choice can be finished without a pointer, not whether the list covers the slot, and not whether an async refresh swaps a row.
Why it happens
Autocomplete happens mid-typing; the hands are already on the keys. Forcing a grab for the pointer is a mode switch: find the mouse, aim, return to keys. Arrows make the list an extension of the slot; the highlighted row is the object about to be accepted. Enter accepts; Esc closes and leaves the typed prefix; Tab as “accept and move to the next field” versus “just leave the slot” must be consistent across the product. Screen readers need combobox / listbox roles and aria-activedescendant (or equivalent) to follow highlight; no keyboard model means no accessible model. Without keys, people submit unfinished prefixes and the backend receives half a place name or half an email.
Studying it
Ban the pointer and complete “pick a specified item from suggestions” with keys only. Record whether the list opens, whether highlight is visible, whether Enter writes the right item, whether Esc backs out. Factors: focus in the slot versus in the list DOM, who owns arrows during IME composition. Outcomes: completion rate, Enter mistaken for “submit search.” Walk the ARIA combobox pattern, but do not turn a specification clause into the study—the measure is whether a person can select, not whether every attribute is present. During Chinese composition, up/down often pick a syllable; that clash with list navigation needs its own condition.
Where it stops holding
A touch-first path has no arrows; keyboard support must still remain for attached keyboards and screen readers, and must not be deleted because “we are an app.” Some search fields use Enter to “search the raw string,” which collides with “accept highlight.” A stable fork is: arrows enter the list, then Enter accepts; without entering, Enter submits the raw string. Read-only suggestion chips are not a combobox and should not take arrows. A custom canvas list that does not expose highlight to assistive tech can look keyboardable while the screen reader stays blind.
Applying it
- Implement up/down to move highlight, Enter to write the highlighted item, Esc to close; highlight must be visible.
- Build a real combobox role so a screen reader follows the current item.
- Define how Tab and Enter split “accept suggestion” versus “submit raw text,” and give arrows to the IME during composition.
- Verify with the mouse unplugged: type a prefix, key to the third item, confirm. The slot should hold that item in full. Esc should restore the prefix. During Chinese composition, up/down should not pick a city by mistake.