Making the select element more accessible

Allright, I have to admit that the native select element (opens in a new tab) is already pretty accessible by default. This post doesn't intend to dunk on the element or the MDN docs, but there are a few tricky accessibility guidelines (opens in a new tab) concerning the select element that are pretty hard to adhere to, or simply not known.

Most of these don't come into play when you're just using HTML and native form actions, but when you're starting to use a framework like React or Vue, like a lot of people do, you might run into some issues.

If you're familiar with basic form accessibility, including associating error messages with form elements, you can skip the first part of this post and go straight to the tricky parts.

Using the native select element

Even though there are a bunch of great accessible (and styleable) select alternatives like the Select component from Radix (opens in a new tab) or the useSelect hook from React Aria (opens in a new tab), it does sometimes make sense to just use the native element. You might not use React or another framework, or limit the amount of Javascript you're shipping to the client.

Building an accessible alternative yourself is also an option, but it's not as easy as it seems. The MDN docs (opens in a new tab) do a great job explaining how to build a styleable select by adding a bunch of Javascript and various ARIA roles, but they also note that it's just a proof of concept. For example, try using your keyboard to select a value.

Knowing the basic form accessibility guidelines

Making the select element more accessible starts with basic form accessibility. To make sure your screen reader users can associate your select with the right label you have to make sure they're actually associated with each other. You can do this by combining for attribute with the id or by wrapping the select in a label element.

<label for="fruit">Favorite fruit</label>
 
<select id="fruit">
  [...]
</select>

I expect most readers know this, but it's good to mention it anyway. Some lesser known guidelines have to do with invalid form values. Whenever the value of a select is invalid you want to communicate this to the user. Visual cues like red colored text work for some, but screen reader users are left in the dark.

In this case the element can be associated with the error in another way. There's an ARIA attribute dedicated to do this called aria-errormessage, but don't start using it just yet. While most browsers do support this attribute, not all screen readers do.

At the moment of writing, the best way to associate the error with the select element is by using the aria-describedby attribute. When the select is focussed, the screen reader will read the label, followed by the validity and then the contents of the element associated with the describedby attribute.

<label for="fruit">Favorite fruit</label>
 
<select id="fruit" aria-invalid="true" aria-describedby="error">
  [...]
</select>
 
<div id="error">Proper error description.</div>

Make sure you know what you're doing when using ARIA attributes like aria-invalid. Read more about it on the MDN docs (opens in a new tab) or check out the Smashing guide to accessible form validation (opens in a new tab) for more information.

The select placeholder

We all know the placeholder attribute on input elements. It doesn't exist on the select element. However, in a lot of cases a placeholder is used to indicate that the user has to select an option and to make sure the value has been changed before submitting the form.

<select [...]>
  <option value="" disabled selected>Select a fruit</option>
  <option value="banana">Banana</option>
  <option value="tomato">Tomato</option>
</select>

As you can see in the HTML above, the placeholder is just a regular option. I will cover some possibly unknown HTML specification guidelines (opens in a new tab) concerning the placeholder that are related to the accessibility of the element below.

If a select element contains a placeholder label option, the user agent is expected to render that option in a manner that conveys that it is a label, rather than a valid option of the control.

This means that if the option serves as a placeholder, you should make sure everyone will understand that it is. Most of the time the text will suffice, but you can also help out by disabling the option. Just make sure to add the selected attribute to the option so it shows up in the select.

This can include preventing the placeholder label option from being explicitly selected by the user.

Like I said above, disabling the option is a good way to make sure the user doesn't select it and selects a valid option instead. Disabled options will also be conveyed to screen reader users to communicate invalidness.

Invalid value with selected placeholder

When the placeholder label option's selectedness is true, the control is expected to be displayed in a fashion that indicates that no valid option is currently selected.

When the select field is required, submitting a selected option with an empty value will result in an error. The required attribute will usually take care of this. Pristine selects will then convey this properly when validated on submit. When you're validating on change, other cues might be necessary.

<select [...] required>
  <option value="" disabled selected>Select a fruit</option>
  <option value="banana">Banana</option>
  <option value="tomato">Tomato</option>
</select>

You can read more on disabled placeholders in this stackexchange answer (opens in a new tab).

The placeholder is sometimes required

If a select element has a required attribute specified, does not have a multiple attribute specified, and has a display size of 1, then the select element must have a placeholder label option.

I bet this is the most surprising fact. Most select elements I've encountered in the wild have at least two thing in common:

1. They don't have a multiple attribute specified.
2. They have a display size of 1.

The multiple attribute is used to allow users to select multiple options. MDN does a great job explaining the multiple attribute (opens in a new tab):

This Boolean attribute indicates that multiple options can be selected in the list. If it is not specified, then only one option can be selected at a time. [...]

The display size is determined by the size attribute. If this attribute is used it usually accompanies the multiple attribute. The size determines how many options are shown without having to scroll the dropdown.

The extra third thing selects usually have in common is:

3. They are required.

And this means that most select elements should have a placeholder. When I was working on a design system, we used TypeScript to make sure this wasn't forgotten by making the placeholder a required property when the select was required too.

type SelectRequiredProps =
  | {
      isRequired: true;
      placeholder: string;
    }
  | {
      isRequired?: undefined | false;
      placeholder?: string;
    };

In conclusion

The fact that placeholders are sometimes required was the most surprising to me. Together with the other guidelines I've covered, I hope you'll be able to implement select elements that completely adhere to the HTML spec and accessibility guidelines.

There are also a few subjects I didn't cover in this post, mainly the optgroup and option elements. One important thing to remember concerning the optgroup is that you should not nest them, and that the label attribute is required. If you're interested in more about this, please let me know.

Using the native select element in React also knows a few gotchas. While building a component for a design system I found that there's more to it than you might think. I think React does a good job explaining what is going on in their select docs (opens in a new tab), but let me know if you're interested in my views and experiences.