A candidate window that covers controls below the field blocks what comes next

What it is

In search boxes, login forms, and dialogs, Submit, Cancel, Next, or suggestions often sit directly under the field. A candidate window opening downward covers those controls; composition is not finished, and “Search” cannot be clicked. That blocks the next action. It is not “I cannot see the word I just typed”—what is covered is another operable object. Soft-keyboard occlusion is a separate layout problem; even with the keyboard at the bottom, an IME float can bury a button on its own.

Why it happens

Dialogs set a fixed vertical rhythm between field and primary button as if no IME existed. The candidate window is not in that layout flow; it paints as a top-level window above them, and hit-testing reaches it first. A user who thinks they clicked Submit actually clicks a candidate, commits or mis-picks a word, and Submit never runs. Enter sometimes submits and sometimes commits the first candidate; that conflict is harder to debug while the button is hidden. Short forms (one field, one button) almost always hit this. On mobile, candidates attached to the field's lower edge rather than the keyboard's upper edge likewise cover chips and filters under the field.

Studying it

On real login and search dialogs, try clicking the buried primary button during composition; record whether the hit is a candidate or the button, and whether the task completes. Compare: button above the field, form grows when candidates appear, candidates forced onto the keyboard. Measure extra steps from starting composition to a successful submit. Automated hit-testing can list clickable controls whose rectangles intersect the candidate rectangle.

Where it stops holding

A long page with the primary button far below the fold is out of the window's reach. Candidates always painted on top of the keyboard block keys, not buttons—a different failure. Assistive-tech users who submit with Enter do not need to click the buried button, but still take the Enter-versus-candidate conflict. A game HUD field with no standard button shows the block as covering an ability bar.

Applying it

• On short forms, put the primary button above or beside the field, or move it out of overlap when candidates appear.
• During composition, a click in the primary-button region should not count as a candidate hit unless it lands on a candidate glyph.
• Make Enter commit only while composing, with a second Enter to submit, and say so on the button.
• Verify by opening the target dialog, typing a word that needs candidates without finishing the pick, and clicking the primary button. Activating a candidate or getting no response is a block.

Related

• Same group: C6.27.1 Candidate lists usually float near the caret and easily cover the text being edited · C6.27.2 Candidate windows must flip with the caret's distance to the screen edge · C6.27.4 Dismiss timing must be consistent, or leftover overlays remain
• Adjacent: C6.06 Soft keyboards and screen occupancy · C6.28 Form autofill
• Search: blocked submit · overlay hit-testing · IME dialog