Challenge 3: Explain Why Focus Stays on the Combobox Input — Possible Solution ==================================================================== WHY MOVING REAL DOM FOCUS TO EACH OPTION WOULD BE PROBLEMATIC ------------------------------------------------------------------- If real DOM focus moved to each option as the user pressed arrow keys, that focus move would take focus AWAY from the text input itself — but the input is exactly where the user's typing needs to continue working correctly. Typing filters/refines the suggestion list in most combobox implementations, and typing requires the TEXT INPUT specifically to have real focus; if focus had jumped to a
  • element instead, the keyboard would no longer be typing INTO the input at all, breaking the fundamental "type to filter" behavior this component is built around. There's also a more basic browser mechanics issue: moving actual DOM focus away from an mid-interaction would trigger the input's blur event (and the option's own focus event) — many components rely on blur to close/finalize things like validation or dropdown-closing behavior, so real DOM focus repeatedly jumping in and out of the input on every single arrow-key press could trigger unwanted side effects (the dropdown briefly appearing to close, validation firing prematurely) that have nothing to do with the user's actual intent, which is simply "highlight the next option while I keep typing/reading in the input." WHY aria-activedescendant SOLVES THIS ------------------------------------------ aria-activedescendant lets the component communicate "this specific option is currently highlighted" to assistive technology WITHOUT actually moving real DOM focus anywhere. The keeps genuine focus the entire time — the user can keep typing normally, uninterrupted — while a screen reader still correctly announces whichever option aria-activedescendant currently points to, exactly as if focus had moved there, purely through this ARIA relationship rather than an actual focus change. WHY THIS WORKS AS AN ANSWER ------------------------------ This is a specific instance of Chapter 3's broader "ARIA only announces, it doesn't provide behavior" principle, applied in the OPPOSITE direction from most of that chapter's examples: instead of ARIA failing to provide behavior a developer assumed it would, here ARIA is DELIBERATELY used to announce something WITHOUT triggering the browser behavior (a real focus change) that would normally accompany it — giving the combobox exactly the announcement behavior it needs while avoiding the unwanted side effects a real focus move would introduce to the input's typing and validation behavior.