A focused element should not jump when the dialog’s size changes

What it is

A dialog may still change size after it is open: a validation line appears, a keyboard rises, the language switches, a card becomes fullscreen. The field being typed or watched must not jump elsewhere or scroll out of the viewport because of that. Stable focus across resize keeps the step in progress under finger and gaze, rather than making someone hunt the caret after the box reflows.

Why it happens

Input is aimed at a place in space. If a height change recomputes the box’s outer edge as “stay centred,” every row of the content region moves relative to the viewport; the caret leaps from above the keyboard to under it, the next keystroke lands in the wrong field, or on something that is no longer a field. If inner scroll resets its offset on reflow, the field being filled moves back out of the top. The stable approach anchors on the currently focused node: after the size change, that node stays at the same relative place in the visible area, adjusting scroll offset if needed, rather than letting the whole content follow the box’s centre. Keyboard appearance is the most common size event: the focused field must rise above the keyboard, without the whole box — title and all — being pushed out of the viewport. Motion can soften a shift; it cannot replace an anchor. Without an anchor, motion only slows the jump.

Studying it

While focus is in a field, trigger a size change: inject error copy, show the keyboard, switch language, rotate the device. Record displacement of the focused node’s centre relative to the viewport, whether it stays visible, whether input lands in a neighbour. Independent variables: whether reflow keeps a focus anchor, whether inner scroll resets. Dependent variables: displacement in pixels, lost focus, neighbour mistypes. Unanchored centre-reflow should displace most when the keyboard appears.

Where it stops holding

A user dragging the box to resize expects some movement, but the focused field should still remain inside the box. When focus is on Close, how the content region scrolls barely affects input, and the constraint is weaker. The initial size computation on first open has no “field already being watched,” so there is no jump to prevent; this rule is for after open. Screen readers do not use pixel place, but if the focused object is destroyed and rebuilt in the reflow, speech cuts; the anchor must also keep node identity.

Applying it

• Any update that changes box height should anchor on the currently focused node and keep it in the visible area.
• Do not snap inner scroll back to the top when content updates.
• When the keyboard appears, bring the focused field above it. The title may compress; the whole box must not leave the screen.
• How to check: halfway through typing, let an error appear or the keyboard rise. The caret should still be in the same field, and the field still visible. Having to tap again to continue typing means it jumped.

Related

• Within the group: E4.19.1 A dialog’s size should follow how much content it holds, not a single hardcoded box · E4.19.2 On a narrow screen a dialog often has to become fullscreen · E4.19.3 When content exceeds the visible height, scroll inside the dialog rather than bursting the overlay
• Adjacent: E2.22 Autofocus and focus stealing · E4.10 Modal dialogs
• Search terms: layout shift · focus stability · keyboard avoidance