Focus must move when new dynamic content appears
Aliases: focus into injected UI · move focus after reveal · new panel takes focus
What it is
After a panel expands, a wizard step injects, or a new region the user must work in appears, focus does not jump there on its own. It stays on the control that triggered the change until implementation moves it into the new working area. Users who cannot see the screen keep typing in the old context; for them the new UI has not appeared.
The move is for dynamic content the user will now work inside, not for every DOM update. A badge count, a silent save, a new ordinary row in a list that is not a new working context — stealing focus there interrupts the current task.
Why it happens
Focus is a pointer at a node. Inserting nodes does not rewrite that pointer. Keyboard and the next screen-reader origin follow the pointer, not the paint. A new panel can be drawn dead-center with a complete motion, and the pointer is still on “Open”: the next Tab leaves toward the button’s old neighbor, and the screen reader continues in the button’s stretch of the tree.
Moving focus into the new region is the assistive-channel signal for “you are here now.” The target is usually the region’s heading, the first instructional block, or the first required field. Without the move, vision already changed scene via motion and position; the assistive channel did not. The two channels desync, and every later keystroke lands in the wrong scene.
Where it stops holding
Updates that are not a new working scene must not take focus: a toolbar count, autosave, a filter refresh that leaves the user on the same object. The move would yank them out of the field they are typing in. A one-shot, non-interactive notice used as a focus target drops keyboard users on text they cannot act on, and they have to walk back. Focus already inside the region that will expand (same control, in place) need not move again. A full navigation is a route reset, not this case. If the new content is not yet interactive (skeleton, loading), moving early lands on an empty hole; wait for an interactive node.
Applying it
- For every action that opens a new working region, specify the focus landing: a focusable heading or the first operable control. Write it on the spec; do not leave it for implementation to guess.
- Name the updates that must not take focus, so badges and toasts are not landings.
- Move after the content is interactive, not on the first animation frame.
- How to check: keyboard-only expand, inject, next step. The focus indicator should be inside the new region, and the next Tab target should be too. Focus still on the trigger, or dumped at the document start, means nodes were inserted and the pointer was not moved.