Is implicit submission (submit on enter key) useful to people using readers and keyboard navigation?

Question

I'm looking for insights about how users with disabilities make use of implicit submission (https://www.w3.org/TR/html50/forms.html#implicit-submission) ?

I'm wondering if submitting a form on enter key when focus is in a input text is a must in the accessibility world or not ? I'm sure it could be useful in some scenarios, but I know it could be harmful also in others...

For example, what if some keyboard user presses enter wanting to add a new line, but sends the form instead ? what if he presses enter in a long form before scanning all form inputs, and submits the form missing some important information to fill?

On the other hand, it can be very handy to be able to submit a form without having to tab through all the form to get the focus on the submit button and submit...

I know that JAWS and NVDA offers keyboards shorcuts to go to the next buton, so I wonder if it's really userful for them. What are expectations of users navigating the web with a reader or keyboard navigation on that matter ?

Answer 1

QuentinC's answer is excellent, so I won't answer every point.

I would recommend that you don't attempt to interfere with implicit form submission, unless you have a very good reason for doing so.

For example, what if some keyboard user presses enter wanting to add a new line, but sends the form instead ?

For <textarea>, pressing enter usually produces a new line, and implicit form submission doesn't happen. For <input type="text">, pressing enter causes implicit form submission.

Some applications override this behaviour though (in confusing ways, in my view). A common example is with messaging applications, which have overridden the enter key, so it means "send message". To get a new line, they put some custom behaviour, such as CTRL+ENTER to make a new line. This isn't the default behaviour of a <textarea> though. To make matters worse, different messaging applications do the opposite. A few offer a user preference to configure whether pressing enter sends a message, or adds a new line (Slack offers a preference).

On the other hand, it can be very handy to be able to submit a form without having to tab through all the form to get the focus on the submit button and submit...

This is the main reason to avoid interfering with the browser's default behaviours for implicit form submission. As a keyboard user, I often make use of this. Screen readers offer various navigation shortcuts, but these aren't available to a sighted keyboard user who isn't using assistive technology.

Answer 2

I'm a screen reader user. Implicit submission with enter key is, I think, an absolute must. Except if it causes more annoyance than it solves, but it's extremely rare.

Generally, screen reader and keyboard-only users are much slower than normal users. And I confirm that it's quite annoying to have to navigate manually to the submit button when the enter key doesn't work as expected.

By chance, if you are doing things correctly, it's implicit, you don't have to do anything to support it. The most elementary rules to not break implicit enter submission are:

• Use <input type="submit"/>, <button type="submit"/> or <input type="image"/> to indicate the submit button automatically triggered upon pressing enter.
• Use onsubmit event on the form, rather than onclick on the button
• Make sure that the form has only a single submit button

The submit button must be present, not disabled, and not display:none in order for implicit submission via enter to work. The button may not be visible on the screen though, if it's your wish.

The second rule reminds you that onclick on the button is bad, because it isn't triggered when pressing enter while being in another field. Thus breaking implicit submit. This is the most common reason for implicit submit to not work as expected.

The third rule ensure that the right button is pressed when doing implicit submit. If there are multiple buttons, normally the first one in DOM order should be taken, but browser have sometimes different behaviors, especially IE. So the best is to always avoid it.

Now for your little fears:

For example, what if some keyboard user presses enter wanting to add a new line, but sends the form instead ?

In principle it won't happen unexpectedly. When entering a text field, it is announced to screen readers, whether it is single line (<input type="text"/>) or multiline (<textarea>)

In case of doubt, remember to attach an appropriate label that makes sense. If the label is "comment", "message" or "address", I can reasonably expect that the field is multiline; if it is "First name" or "city", I implicitly know that it isn't.

what if he presses enter in a long form before scanning all form inputs, and submits the form missing some important information to fill?

It's very common, but you shouldn't be afraid of it.

It's your job to provide clear and efficient error messages to the user, allongside with as simple as possible navigation inside the form. The more it is difficult to go back, understand and fix errors, the less chance the form is going to be finally submitted; it drops very quickly, and even more with screen reader users. How to do it well is another question.

Answer 3

Most forms on the web has the behavior of implicit submission built-in, so users of assistive technology would not be surprised by it, and I've not experienced it as an issue when using screen-readers.

However, you should ensure that you always provide a proper button for submitting the form as well. See WCAG 3.2.2

You should also ensure to make it as easy as possible to go back and change the data afterwards/at a later time.