The “Enter” key should submit the form currently in focus

Posted on December 6, 2023

This article is part of a series on user interface micro interactions and how they affect the user experience.

Since the early days of computing, the Enter key has been used to submit a form.

When graphical user interfaces (GUIs) were introduced, buttons would be added so that users could submit forms, but largely, the Enter still allowed users to trigger a form submission, even if those users did not activate the form’s submit button.

This feature allows super users — people who are proficient with their tool — to submit forms quickly. This is also an important keyboard navigation accessibility feature which allows users of assistive devices to trigger forms in the same manner.

The behaviour of triggering a form this way is integrated in the HTML specifications, and is thus a default browser behaviour:

“If the user agent supports letting the user submit a form implicitly (for example, on some platforms hitting the “enter” key while a text control is focused implicitly submits the form), then doing so for a form, whose default button has activation behavior and is not disabled, must cause the user agent to fire a click event at that default button.”

— HTML Spec, “4.10.21.2 Implicit submission”

With regards to accessibility, the WCAG spec says that forms must be given a submit button:

This technique is Sufficient to meet 3.2.2: On Input when used with G80: Providing a submit button to initiate a change of context.

— W3C – WCAG 2.1 Techniques, “Technique H32: Providing submit buttons”

Since the HTML spec says that a form should be submitted with Enter when the browser (user agent) allows it, and the WCAG expectations say that a submit button should be offered for forms, we can conclude that the button requested by WCAG must also behave as the browser requires by default.

Thus, the Enter key should submit a form which is currently in focus.

Ensure to not break the default behaviour

Be careful to not over-engineer your design by expecting the Enter key to work when the focus is on any element inside a form. There are some components, such as text areas, that natively make use of the Enter key.

In a response asked on the subject of how to implement keyboard navigation in a form, user JohnGB summarized it best:

“It depends on what type of field it is in the form.

If ‘enter’ has a meaning within that form element, then you should have it behave according to that meaning. For example, if it’s a textbox, ‘enter’ should take them to the next line. If it is a table, then ‘enter’ should move down to the cell below the current one.

If ‘enter’ has no meaning within that form element, it should submit the form.

The standard which you should us, it to ‘tab’ between fields, unless tab has a meaning within the form field. For example, if it’s a table, ‘tab’ should move to the next cell.”

— JohnGB, “Behavior of the Enter button in a form”

Be careful to only aim for the default behaviour of the browser, do not take over how some elements actually use the Enter key themselves, such as a text area.

Quick technical note

Most often, the best strategy for the design pattern described in this article to work as expected is to ensure to use the <form> HTML element in which a submit button is used.

With that combination in place, there should be no additional code to add to handle the default Enter key behaviour.

Note that I gave a broad definition of forms in another article: forms are basically just an interface to gather user information and send it to the back-end.

References and Additional Readings

Prototype

ENTER Key Should Submit Form – Prototype | Mat Janson Blanchet

Articles

Technique H32: Providing submit buttons | WCAG 2.1 Techniques – W3C

Behavior of the Enter button in a form | UX Stack Exchange

Technical Articles

4.10.21.2 Implicit submission | HTML Spec

<form>: The Form element | MDN Web Docs

<input type="submit"> | MDN Web Docs

Last updated on February 13, 2024