When not to use SELECT

Introduction

Web interfaces abound with instances of the SELECT element, a drop-down list element, which makes it easy to offer the user a single choice between multiple options.

However, there are no shortage of reasons you may want to think twice about applying a SELECT element to your user interface.

This article presents a few cases for avoiding SELECT, in terms of accessibility, usability and inclusiveness.

A common example: Gender

Let's start with an example of a common use-case: capturing a "gender" value from the user. Here is the markup and visual look and feel.

<label for="gender">Gender</label>
<select id="gender">
 <option>Male</option>
 <option>Female</option>
 <option>Other</option>
</select>

This affords grouping (list of genders under a heading of "gender") and information hiding (the list itself is hidden until the user chooses to reveal it, reducing clutter on the screen).

Accessibility: for the non-sighted

Suppose you're a totally blind person who happens to be using the JAWS screen-reader. You press a keystroke to tell JAWS to give you a list of inputs on the screen. JAWS dutifully reads out every field except for the gender dropdown, which is a select element, not an input element. Thus, you don't even know that the element exists until you try to submit the form and get a validation error, a preventable mistake.

(Note: the above was discovered in a usability testing session with a blind person. Yay, usability testing!)

Accessibility: for the partially-sighted

What if you're a partially sighted person? By default the select element should show up with black text on a white background – a high-contrast combination – so it should, in theory, be OK for colour-blind users.

That said some users require specific color combinations, to be able to see properly. The WCAG20 criteria for AAA include: "Foreground and background colors can be selected by the user" (1.4.8 Visual Presentation). Admittedly this criterion applies to "blocks of text", not controls per-se, but perhaps it should be extended to controls, especially given that users need to be able to see the options in order to use the control, as in the case of <select>.

What if, rather than colour-blindness, you have blurry or distorted vision? You might want to modify the styling of the input, increasing the font size or changing the text or background colour. Unfortunately, the select element doesn't currently allow this kind of customisation. (Though it may allow customisation in the future via the appearance property).

Usability: visibility vs concealement

The select element hides its children until the user opens it. Depending on the context in which your interface will be used, this hiding may be beneficial or costly. As Norman points out,

Long advises that concealed inputs create difficulties for people in West Africa and other non-Western countries. People in these countries may be "leap-frogging" over desktop computers and the mouse, instead using newer touch-enabled devices such as tablets. Touch interfaces rarely use concealed inputs, and prefer to display options up-front.

Certain prominent websites prefer up-front controls on touch-enabled devices, where they would use a dropdown for the web experience. A notable example is

Summary

We can avoid the issues of screen-reader inaccessibility, non-customisability and concealed inputs by avoiding the SELECT element.

You could instead opt for, say, labelled radio buttons, which are standard input elements that can be re-styled as needed. For an example of the above, I recommend Russ Weakley's excellent slides on custom radio buttons and checkboxes.