Accessible Forms – Selects or Dropdowns
Published: | 2 Comments
Reading Time: 3 minutesThe Select input field (more commonly known as a dropdown) enables a user of a web form to make a selection from a list of items. They can be used in other situations too. This post looks at the best practices for using selects accessibly and pitfalls to avoid.
Typical uses of select or dropdown
Choose one item from a list
The most common use of a select is to choose a single item from a list. It’s functionality here is effectively the same as a radio button group. Typically selects are used in preference to radio buttons where the list of items is long – for example a list of countries.
Choose multiple items from a list
A less used feature of the select is the ability to allow multiple items to be chosen from a list – equivalent to a check box grouping. For example:
Using multiple option selects cause real problems for accessibility – see below.
As a navigational item
Some sites use selects to allow users to choose which page or section of a site to visit next. For example: (please note this is not a functioning example)
Whilst this is useful functionality and doesn’t take up so much room on a page serious accessibility issues can arise if this technique is not used properly – see below.
Accessibility considerations
Labels
As with other input fields it is imperative that selects have an explicitly linked label to prompt for input. However it is easier to use an appropriate label with a select than the sometimes ambiguous labels found in conjunction with radio buttons. See Accessible Forms – Checkboxes and Radio Buttons for an explanation of this issue and possible solutions.
See also Accessible Forms – Should Every Input Have a Label? for detail on how to link labels and input fields.
Using selects with multiple options
Most input fields can be accessed simply and intuitively using mouse or keyboard. However, using multiple options with a select requires specialist knowledge that not all users will have.
On Windows machines the items are selected using Ctrl + click with a mouse (Cmd + click on a mac). There is a purely keyboard way of selecting and deselecting items but some versions of Internet Explorer and also Chrome do not support it. It’s also very difficult if not impossible to select multiple items on a smartphone – especially a touch screen device.
For these reasons we strongly recommend using checkboxes instead of multiple items selects.
Using selects for navigation
Accessibility problems can arise when using dropdowns or selects for navigation if the website developer has assumed that everyone will be using a mouse. Typically a new page will be loaded whenever the value of the select is changed (using the onchange event trigger).
This brings problems for those who use or rely on a keyboard – eg blind users or those with motor impairments. These users will tab into the select and then use the up or down arrow keys to expose and select from the available options. Each time the focus moves to another item in the list the onchange event is triggered and a new page is loaded.
Obviously this is frustrating for the user and could also mean that it is impossible to reach parts of the website.
Fortunately there is an accessible solution – to use the select in conjunction with a ‘Go’ button which triggers the loading of a new page. It is not necessary to use the onchange event to trigger the page change so this technique becomes keyboard accessible and everyone can use it.
See example near the top of this post.
Grouping of select options
Semantic grouping of items in a select box is possible using the <optgroup> HTML element. In longer lists this can provide useful usability benefits as well as accessibility benefits.
The use of <optgroup> and other grouping elements is covered in more detail in a future post in this series.
Any other suggestions?
If you’ve got comments on any of the points ccovered in this post (or any of the others) I’d be glad to hear them. Likewise if you feel I’ve missed something please let me know. You can leave a comment using the comment form below.
Other posts tagged 'Forms'
- How to Build an Accessible WordPress Theme - Apr 28th, 2019
- Accessibility Checklist - Apr 7th, 2019
- Dragon Naturally Speaking Video 9 – Internet Forms - Mar 13th, 2014
- Video: How Do I Know My WordPress Website is Accessible? - Mar 5th, 2014
- Accessible Forms – Grouping Elements Together With Fieldset - Oct 11th, 2011
- Accessible Forms – Grouping Options With Optgroup - Aug 24th, 2011
- Accessible Forms – Checkboxes and Radio Buttons - Apr 26th, 2011
- Accessible Forms – Should Every Input Have a Label? - Apr 15th, 2011
- Designing and Building Accessible Forms - Apr 12th, 2011
Share this page (Links open new windows/tabs)
2 Responses to “Accessible Forms – Selects or Dropdowns”
Like to leave a comment?
Please note: All comments are moderated before they will appear on this site.
Previous post: Accessible Forms – Checkboxes and Radio Buttons
Next post: Evolving Standards in Accessibility 2011 – Part 1
What about menus that determine what content is displayed on the page or on subsequent select menus?
Our example is a huge list of items, divided up into categories. The first select identifies the category. The second select is then populated with items from that category.
Currently this happens automatically.
Do I need a “Go” button after the first select? Or is this OK without?
Thanks for your query Mike.
The construct you describe is similar to things I’ve come across on car insurance sites – where you first select the make of the car, then the model, and then the individual spec.
The example that I quoted in the post was where choosing an option in the dropdown moves the user to a different page within the site. This is a real problem.
Assuming that your dropdowns are on the same page, then this is less of an issue. As long as using the up and down arrow keys on the first dropdown doesn’t move focus automatically to the next dropdown, then it would be OK.
If populating the second dropdown involves fetching a new set of values from a database, you may wish to trigger the database fetch only at the point at which focus moves away from the first dropdown.
If however, all the value are readily available within the scripting in the page, it would be OK to update the second dropdown as a keyboard user was moving up and down through the options in the first dropdown.
The key point is to not move the user away from the first dropdown until they’ve made a selection they’re happy with.
I hope all that makes sense, but please respond if I’ve not been clear.