The Autocomplete That Announces Everything

The widget mixes two models and signals the wrong things.

• Role placement: role="combobox" belongs on the input, not on a wrapper. The wrapper role creates a composite widget whose name and value are not the input's, which is why AT behavior diverges.
• Focus: focus must stay in the input; the popup is not a focus destination. Moving DOM focus into the listbox means typing stops, Escape and arrow behavior break, and VoiceOver's announcement path differs from NVDA's. Set aria-expanded on the input, aria-controls referencing the listbox, and use aria-activedescendant pointing at the highlighted option's id while focus remains in the textbox.
• Listbox semantics: the popup should be role="listbox" with role="option" children, each with a stable id. Use aria-selected only for an actual selection, not for the temporary highlight, which aria-activedescendant conveys.
• Keys: Up and Down move the active option without leaving the input; Enter selects; Escape closes the popup and clears the active descendant; Tab leaves the field and closes the popup.
• Announcements: remove the assertive live region. An assertive message per keystroke and per arrow press interrupts the user's own reading. Provide the count once, after results settle and through a polite status element (role="status"), or let the option text speak for itself.

This also explains the duplicate JAWS reading: the highlight and the live region both announce.

The failure is a Label in Name problem (2.5.3): the accessible name must contain the visible text. A voice-control user speaks what they see. They see "Find a flight" but the accessible name is "Search", so the command "click Find" matches nothing. Fix the accessible name to start with the visible label, for example "Find a flight" or "Find a flight, city or airport," using a proper <label> element or aria-label/aria-labelledby that includes the visible words. Do not solve it by changing only the visible text unless the design is also being changed.

The same rule applies to the options: if a suggestion displays "London Heathrow" but the accessible name is an airport code, voice users cannot select it. Make the option's accessible name begin with the visible text; extra context can follow.

Also check that the input has a programmatic label at all, that autocomplete is set appropriately, and that any error message is associated with the field. Voice control depends on visible text matching accessible names and on targets being unambiguous; a list of eight options with identical leading words will be hard to select by voice even when names match.

Test the pattern, not only the page. A plan for this component:

1. Keyboard-only: reach the input, type, arrow through options, select with Enter, close with Escape, tab away. Confirm focus never moves into the popup and that the page does not scroll unexpectedly.
2. Screen readers: NVDA with Chrome and Firefox, JAWS with Chrome, VoiceOver with Safari on macOS and iOS, TalkBack on Android. For each, record the expected announcement at four moments: field focus (name, role, state), typing (count or silence), arrow navigation (option text and position), and selection (value committed).
3. Voice control and speech input: commands using the visible label and visible option text.
4. Zoom and touch: 200% and 400% zoom, and touch targets in the popup.

To separate defects from AT quirks, apply three tests: does the failure reproduce in a second browser with the same AT; does it follow from a documented pattern violation; and does a reference implementation of the same ARIA pattern behave correctly? A genuine defect reproduces across at least two combinations or traces to a spec violation. A single AT's odd phrasing on one browser is a quirk to note, not necessarily a code change. Record the matrix and results, and rerun after any change to the component.