Over a million developers have joined DZone.

When Not to Use SELECT

DZone's Guide to

When Not to Use SELECT

The drop-down select element is a popular way of offering users options on a web page. But, it's not always the best option. Read on to find out why.

· Web Dev Zone ·
Free Resource

Deploying code to production can be filled with uncertainty. Reduce the risks, and deploy earlier and more often. Download this free guide to learn more. Brought to you in partnership with Rollbar.

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 is 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">


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 Non-Sighted Operation

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.

(The above was discovered in a usability testing session with a blind person.)

Accessibility: For Partially-Sighted Operation

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

But what if, rather than color-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 color. Unfortunately, the select element doesn't currently allow this kind of customization (though it may allow customization in the future via the appearance property).

Inclusive Design: For Humans

In an article on free-form input, Emily Horsman argues that interfaces that don't take into account the full spectrum of gender are likely to collect incorrect data, leading to bad insights.

Horsman advocates replacing non-inclusive approaches, such as SELECT lists that allow only 'Male,' 'Female,' and 'Other,' with more inclusive free-form text fields, which allow the user to provide input "past what we can imagine at first."

Usability: Visibility vs Concealment

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.

You may want to prefer up-front controls on touch-enabled devices, where you would normally use a drop-down for the 'mouse and keyboard' experience.


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, labeled 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).

Or, we can consider replacing pre-defined options altogether with free-form inputs, allowing the user to define the form of the text themselves.

Deploying code to production can be filled with uncertainty. Reduce the risks, and deploy earlier and more often. Download this free guide to learn more. Brought to you in partnership with Rollbar.

web dev ,ui/ux ,web page creation

Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}