H1.11.2explicit Enter-to-submit behaviordesignresearch

What Enter does on submit must be explicit

Aliases: implicit submission · Enter submits · form Enter

What it is

In many desktop browsers, Enter in a single-line input fires the form’s implicit submission. People may think Enter means “go to the next blank” and send an unfinished form; or think Enter will submit and nothing happens. Behavior must be explicit means the product first decides whether Enter in this context submits, inserts a newline, or moves to the next field, and makes that decision predictable—button copy, where the primary button sits, newline inside a multiline box, and the consequence of Enter in a single-line box all agree. Whether Tab order is scrambled, and whether a phone keyboard has “Next,” are separate issues.

Why it happens

Enter on a keyboard is “finish current.” Finish-current is send in chat, newline in a word processor, and historically submit in a multi-field form because browsers mapped it that way. People arrive carrying whichever mapping they used last. A second layer: the target of implicit submit is unstable. The browser picks the first type=submit. If “Delete” or “Send code” is written first in the DOM, Enter fires that secondary action. In a textarea Enter should newline; if the parent form is still listening for Enter-to-submit, a long note is sent at the end of the first paragraph. Being explicit is not banning Enter-to-submit. It is giving “finish current” one meaning on this screen, and making sure that action’s button is the button Enter will hit.

Studying it

On a one-field sign-in, a multi-field profile, and a form with a multiline note, record what Enter does. Compare Enter submits the primary action, Enter moves to the next field, Enter does nothing.

Independent variables: field count, whether a textarea is present, whether the first submit in the DOM is the primary action, whether Enter is intercepted. Dependent variables: submits of an unfinished form, Enter hitting a secondary button, accidental submit inside multiline, whether predicted meaning of Enter matches.

Lab participants will ask “what will Enter do,” polluting prediction. Have them press first, then ask what they thought would happen. A mobile keyboard’s Go / Search / Return is not the same key as desktop Enter; measure separately.

Where it stops holding

On a true one-field search or sign-in, Enter-to-submit is platform convention; allowing only a button click feels broken. Enter during IME composition confirms the candidate, not submit; intercepts must let composition through. When a game or terminal is embedded in a form, Enter belongs to the embed. On touch-first devices with no physical Enter, this entry mainly constrains attached keyboards. Assistive-technology users who rely on Enter to activate the primary button still need that button keyboard-activatable if implicit submit is removed.

Applying it

  • On multi-field forms: either let Enter hit only the visual primary button (and make that the first submit in the DOM), or intercept Enter to move to the next field and show on the primary button that Enter would also work.
  • When a multiline field is present, Enter inside it only newlines. Submit goes through the primary button or a chord, not at the end of the first paragraph.
  • Do not put “Delete” or “Get code” as an earlier type=submit.
  • Verify: Enter in the name box must not submit the whole form or hit “Delete.” Enter in notes must add one line. On a sign-in with only a password box, Enter should submit sign-in. Enter during IME composition must not submit.

Related

  • Within the group: H1.11.1 Focus order must match visual order · H1.11.3 Mobile forms need a jump to the next field
  • Adjacent: E1.10 Button order · H1.07 Preventing duplicate submit · E2.02 Multiline text areas
  • Search terms: implicit submission · Enter key · type=submit

Cards in the same group

Quick Actions

Share

Share this page

ios_share

https://hci.top/en/handbook/H1.11.2