Accessible Forms – Checkboxes and Radio Buttons
Published: | 5 Comments
Reading Time: 4 minutesCheckboxes and radio buttons are similar in that they both allow users to choose from a list of items. The difference between them is that radio buttons only allow a single selection to be made in any one group. But they both can have implications for web form accessibility if they’re not used correctly.
This post outlines the best practices for using checkboxes and radio buttons and highlights some of the potential pitfalls with their use.
Checkboxes
Checkboxes are used in two subtly different ways.
Choosing from a selection
Depending on the information being collected by the form there may be an associated question which provides the context.
For example:
| Choose extra toppings for your pizza |
Confirmation of action
Another typical use of a checkbox is to allow users to confirm something.
For example:
Note that there would not normally be an associated question with this type of use.
Radio buttons
Old style car radio with preset buttons
Radio buttons take their name from station selector switches on some radios – partticularly old-fashioned ones or car radios. These station presets were either fixed at manufacture or could be pre-programmed by the user (more common today) and selecting one deselects any previous selection.
Radio buttons in web forms behave the same way – assuming they are grouped correctly, see below.
Unlike a checkbox group, a radio button group would almost always have an associated ‘question’.
For example:
| How old are you? |
It is not appropriate to have a single radio button in a group as once selected it cannot easily be unselected.
Accessibility considerations
Form labels – are they clear enough?
As discussed in Accessible Forms – Should Every Input Have a Label? all input fields need to have a label and the label is linked to the form field using the id attribute. Note that the name attribute is also important for radio buttons and checkboxes to maintain the groupings.
So using the checkbox pizza topping example from above:
<p>Choose extra toppings for your pizza</p> <input id="pizza1" name="pizzatop" type="checkbox" /> <label for="pizza1">Pepperoni</label> <input id="pizza2" name="pizzatop" type="checkbox" /> <label for="pizza2">Anchovy</label> <input id="pizza3" name="pizzatop" type="checkbox" /> <label for="pizza3">Extra Garlic</label>
Note that the question is not a label. As we’ll see in a later post, plain text such as this within a form can easily be missed by screen reader users. Sometimes this doesn’t matter if the ‘answers’ convey the full meaning. But consider this series of radio button questions you might find on a home insurance site.
| Have you lived at this property for more than 5 years? |
| Is the property within 20 metres of a watercourse? |
| Are there tall trees within 10 metres of the property? |
The labels for the radio buttons are actually the yes/no answers to the questions. Screen reader users who will typically be tabbing from one field to the next will hear something like the following:
Yes radio button not checked one of two (tab)
No radio button not checked one of two (tab)
Yes radio button not checked one of two (tab)
No radio button not checked one of two (tab)
etc
So on their own the radio button input labels do not provide enough context to allow a blind user to easily respond to the questions. It is possible for screen reader users to access the questions but in some screen readers this can be very difficult – as will be explained in a future post on how screen reader users access forms.
Solving the problem part 1
One solution would be to include the question and the answer in each of the labels:
| Have you lived at this property for more than 5 years? |
Whilst this may be a good solution for screen reader users it may not be as popular with all sighted users.
Solving the problem part 2
Using the techniques described in Text for Screen Readers Only it would be possible to hide the extra text from sighted users but still have it read to screen reader users.
This is a robust solution to the problem and is still the best approach where you need to cater for users with older browsers and/or screen readers.
Solving the problem part 3, using a grouping element
A more elegant solution for more modern browsers and screen readers is the <fieldset> element with its associated <legend> element.
The whole question would now become:
<fieldset> <legend>Have you lived here for more than 5 years?</legend> <input id="live1" name="live" type="radio" /> <label for="live1">Yes</label> <input id="live2" name="live" type="radio" /> <label for="live2">No</label> </fieldset>
The <fieldset> and other form field grouping elements for input fields are considered in more details in a future post – Grouping Elements Together With Fieldset.
Got any other suggestions?
If you’ve got any comments on any of these posts I’d be happy to hear them. Likewise if you feel I’ve missed anything out why not 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 – Selects or Dropdowns - May 24th, 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)
5 Responses to “Accessible Forms – Checkboxes and Radio Buttons”
Like to leave a comment?
Please note: All comments are moderated before they will appear on this site.
Previous post: Accessible Forms – Should Every Input Have a Label?
Next post: Accessible Forms – Selects or Dropdowns
Hi, I have Dragon 13, and once I select a radio button or checkbox all the rest become unnumbered. And I’m not able to select multiple buttons or checkbox without saying the command first every time. In all previous versions I was able to do this. Any way to fix this? Very annoying to have to say “checkbox radio button” each time when you have multiple ones you have to check on one page. Thanks a lot for your help!
Thanks for your comment Mark. The short answer is that I don’t know how to do that. I’m running Dragon 14 now and I had noticed that the number indicators disappear more readily than before. I demonstrate how Dragon works occasionally to groups of developers and designers, and the numbers now disappear when you ask Dragon to “go to sleep”. This makes it harder to break off to explain what’s going on.
If I find an answer I will let you know.
I have a checkbox inside of a dialog. When I use “Enter” for check/uncheck the checkbox is not working the first time, you always need to press twice “Enter” to check. However it works fine when using the “space bar” and you can check/uncheck on the first time you click on it.
I was wondering about radio/text combos. For example, the “other” option. Would the radio button have the label and the text box have an sr-only label?
Good question Lawrence. Sighted users may be able to understand the relationship between the ‘Other’ and the text box for them to specify, but can you guarantee that? A label for the text box would certainly be required for screen reader users, but you could argue that it should be there for sighted users too – just for clarity.