Mobile forms need a jump to the next field

What it is

On a phone the system keyboard takes the lower half of the screen, Tab usually does not exist, and people cannot “key out of this item and into the next” as on desktop. Jump to next is an explicit action on the keyboard toolbar or the Return key: finish the current input and focus the next field; on the last field it becomes “Done / Submit.” Without it, people dismiss the keyboard, tap the next item, and raise the keyboard again—a mode switch per field. Desktop Tab order, and whether Enter submits on desktop, cannot replace this phone-only channel.

Why it happens

The bottleneck in touch filling is the keyboard going up and down, not the keystrokes. Each tap on the next box on screen waits for the keyboard animation, waits for the viewport to compress, then hunts for the field the keyboard is covering. “Next” on the toolbar keeps field-switching inside keyboard mode; the viewport can follow focus; the keyboard need not fall. A second layer is keycap semantics that follow position. Middle items show “Next”; the last shows “Done” or the submit verb. “Search” or “Go” on every field makes people think the form is finished at item three and fire submit. inputmode and enterkeyhint are how that meaning is handed to the system keyboard. An app-drawn toolbar that fights the system keycap leaves people unsure which to press. The jump target must be the visually next field, not whatever happens to be the next focusable node in the DOM—or the phone will send people to the header search box.

Studying it

Fill a form of at least five fields on a real device with the keyboard up. Compare no jump (tap the screen only), system “Next,” and an app-made toolbar.

Independent variables: whether Next exists, last-field keycap copy, whether the jump scrolls a field hidden by the keyboard. Dependent variables: share of field switches that dismissed the keyboard, mis-taps after occlusion, submit fired on a non-last field, completion time.

Simulators often lack real keyboard height. Use a device. Landscape, split view, and third-party keyboards have different toolbar heights; sample them. Desktop Tab completion time is not evidence a phone does not need Next.

Where it stops holding

A one-field OTP or a one-field search does not need “Next”; the keycap should be “Done / Search” directly. Dates and dropdowns that are not text should close their panel then land on the next text field, not insert Next inside a spinner. When a hardware keyboard is attached to a phone, physical Tab should still work; Next can degrade. If a web page cannot control the system keycap, at least keep Return from submitting on non-last fields, and offer a visible “Next” in the remaining viewport.

Applying it

• Give every text field an action that moves to the next one. Change the last field’s keycap to Done or submit; do not use “Search / Go” on middle fields.
• After the jump, scroll the target into the visible area above the keyboard; do not land behind the keys.
• An app toolbar must not contradict the system keycap. If enterkeyhint can be handed to the system, hand it over.
• Verify on a real device with five fields: the middle four switches do not dismiss the keyboard. The fourth keycap is not submit. Return on the last field submits. Place the third field where the keyboard would hide it, press Next, and confirm the input is fully visible.

Related

• Within the group: H1.11.1 Focus order must match visual order · H1.11.2 What Enter does on submit must be explicit
• Adjacent: F1.10 Viewport compression when the keyboard opens · E2.22 Autofocus and focus stealing · H1.04 Timing of live validation
• Search terms: enterkeyhint · input accessory · next field