The field and its submit must be visible together

What it is

The search field sits above the keyboard; the button that actually sends the query is still on the old tab bar, now covered. People finish typing and cannot see the next step. They gamble on Return, or dismiss the keyboard and hunt. Field and submit co-visible asks that, on the keyboard-up map, the field being typed and the control that ships that text are both on screen and both hittable.

Password and Log in, a chat composer and Send, the last cell of a form and Save — the same pair. Missing either end, typing stops halfway.

Why it happens

The input loop is write → glance → send. The keyboard already owns the lower half. If the two ends of the loop then sit on opposite sides of the keyboard, at least one of glance or send needs the keyboard dismissed first. Dismissing drops IME state, candidates, and the mental anchor of the caret; reopening is expensive, so people try Return as luck, or leave the text half-submitted. Mobile browsers do not even agree what Return does (newline / search / next field). Betting the loop on Return is betting it on platform drift.

Pinning submit to the strip above the keyboard — an input accessory, Search to the right of the field, Send on a chat bar — rebuilds the loop inside the compressed viewport, instead of hoping the old footer is still showing.

Where it stops holding

A long form cannot keep every field co-visible with the final submit — intermediate fields can move focus to the next; the final submit only has to share the screen with the last group. A hardware keyboard or desktop Return-to-submit is a stable convention, and the co-visibility constraint can loosen. Autofill of a one-time code that writes the field and advances can survive a moment of a covered submit, because the system took the loop. Voice input has no “write” phase; the co-visible pair is the mic bar and Send, not the original field.

Applying it

• Single-field search, chat, one-time codes: make submit part of the input strip, still above the keyboard when it is up.
• On a long form with the keyboard up, keep at least the current field and the next action (Next / Submit) on screen. Do not leave submit only at a footer you have to scroll to.
• Do not make Return the only submit. Return may accelerate; the button must remain.
• How to check: raise the keyboard, do not dismiss it, and ask whether the current input can be sent. If the keyboard has to come down before submit can be seen or tapped, the pair fails.

Related

• Same group: F1.10.1 The keyboard occupies the lower half and rewrites every spatial relation · F1.10.3 A naive push-up ejects key information at the top
• Nearby: E2.01 Single-line text fields · F1.03 Proximity and saccades
• Search terms: field and submit co-visible · keyboard accessory · search and go