Select boxes shouldn’t submit on change

Some forms that let users sort a list sometimes consist of single select box without a submit button.

Instead the form is submitted when the user selects an option (onchange) using JavaScript.

Top: a select box without a button (bad). Bottom: a select box with a button (good).

The reason for this is usually to declutter the interface and save users a click.

But not only are these poor reasons to omit the submit button but doing this can cause issues for keyboard users and screen reader users.

How it affects keyboard users

A form without a button uses JavaScript to submit the form when the onchange is triggered by selecting a new option.

But some browsers wrongly fire the onchange event when the user presses the Down key.

So as a user moves from the first option to the second, the form will be submitted before the user has a chance to move to the third option and beyond.

This happens in a number of Windows browsers like Chrome, Opera and Internet Explorer 9 and under.

How it affects screen reader users

Screen reader users can struggle too because the act of reading an option selects the option too.

This again causes the form to be submitted before users intend it to.


Submitting a form automatically can be confusing and unfamiliar.

Users may not expect it to happen and it takes control away from the user and fails Web Content Accessibility Guidelines Success Criteria 3.2.2.

Minimal interfaces aren’t necessarily simple interfaces. And it’s not a great idea to design interfaces by counting clicks.

Accessibility is about making things work for everyone no matter what.

Reducing clicks and decluttering an interface may be the result of a well-designed experience, but they’re not objectives in and of themselves.

Start by giving users a button. It puts users in control no matter what.