We're making a web form. We want to ask the user a question, and show them several options to choose from. To implement this, we've got several options to choose from.
The easiest method may be to use the select element. On desktop browsers, this is usually rendered as a 'dropdown' menu. It looks like this:
But dropdowns have lately been the subject of harsh criticism.
'Dropdowns Should be the UI of Last Resort' according to Luke Wroblewski, digital product designer of renown.
What's wrong with select boxes, or dropdowns? The problems are manifold.
- Accessibility problems, like the inability to zoom in on the list of options (depending on the browser).
- Usability problems. The list of options is usually hidden. A more usable solution would let the user glance back at alternative options when reviewing the form, but there's no way to keep them visible.
- Limited options that don't include any correct answer for some users.
- Long option lists that require scrolling, especially on mobile where there's no way to see the total list length …
In many cases, a field that takes text input is a better solution. Or, a set of radio buttons, if you really have a limited set of predefined possible answers. But, make sure they are really all the ones users need.
Multiplicity of choice
There's another type of select element. The multi-select. It's rarely used, for good reasons. It's been long recognised as a cause of poor usability—Brian Crescimanno wrote in 2005:
If the field allows for multiple selections, try your best to avoid using the so-called “multi-select” box. This form element is at best confusing to users and at worst, it makes the form useless to those who do not immediately understand its functionality.
When you give the select element the 'multiple' attribute, it looks like this:
The multi-select is, on desktop browsers, rendered as a list of options. It might have a scrollbar. It's meant for situations where the user is allowed to select more than one option.
So how do you select from these options? You can click on them individually, to select just one. You can click and drag, to select several options next to each other. But what about selecting non-adjacent options?
It's not obvious. It's done by clicking the options while holding the ctrl/cmd key.
If you aren't using a mouse, and only a keyboard, it's impossible.
This means that using a multi-select box in a web form means you instantly fail to conform with the Web Accessibility Guidelines 2.0:
Guideline 2.1: Make all functionality available from a keyboard.
I think this shows that the scarcity of multi-select boxes is justified. There's good reason to never use them. The exception being, as I've done here, to demonstrate why they should never be used.
Checkbox inputs tend to be used instead, to achieve the functionality that a multi-select box would provide. But in a better, more accessible way. You give the user a list of options, each with a checkbox. Checkboxes can be operated with either the mouse or the keyboard.
(Note: on mobile and tablet browsers, the interface for multi-selects is much improved. They work like checkboxes.)
This sort of implementation takes more effort than using a select element. The end result is an improvement in essentially every way. It's also easier to visually customise.
Let's get back to the single select elements now. Dropdowns.
Are there grounds for an absolute prohibition on these?
Not really. Unlike with the multi-select, they don't break any hard accessibility principle we can cite. So I can't argue that they must be consigned to outer darkness.
Here's a selfish reason I'd like to get rid of them, as a developer. Visually customising them is hard. If the design deviates much from the regular appearance, it becomes impossible. The trick is to show the user a fake select element with the desired appearance, and make the real one invisible.
But you can probably use radio buttons instead.
Written by Jason Sackey, UX developer