Everything you ever wanted to know about accessible checkboxes in one opinionated single take video.
Checkbox
Transcript
All right, let’s talk about checkboxes.
This information is adapted from AtomicA11y.Com and TheBookOnAccessibility.Com.
Notice this isn’t titled accessible checkboxes, because if you create a checkbox that isn’t accessible, you didn’t actually make a checkbox. You just made decoration, and that’s not what we’re here to do. What you’re going to learn in this course is not everything about checkboxes and WCAG and all the principles and criteria that surround checkboxes. What you’re going to learn about checkboxes is the basic requirements of what you need to know about checkboxes today. This will build pathways in your brain so that next time you have questions about a checkbox, you’ll recognize that there are requirements, there are things you don’t know, and you will go and seek out the correct answer rather than trying to be clever and come up with something weird that doesn’t work for anybody. All of this information is available in greater detail on AtomicA11y.com, both in design checklists and also functional success criteria with videos and code examples.
Let’s make sure we’re talking about the same thing. A checkbox allows selection of one or multiple inputs. So you might have a single checkbox that allows you to agree to terms and conditions by checking or unchecking the box.
When you have a group of checkboxes, it’s possible to select multiple inputs from the group.
You have to design your checkbox for everyone. So that means that we firstly start by accommodating people with low vision. Now, I know everyone wants to start with screen reader accessibility, but we’re going to start with low vision. The reason for that is because so many issues in accessibility start with the design and not accommodating people who just have a hard time seeing. So the first thing is that your text must have a contrast of 4.5 to one minimum to the adjacent colors around it. Your label for the checkbox must be present, and it must be in close proximity to the checkbox itself. Text must be able to resize up to 200 % with no loss of information. Now, this is different from hitting Command or Control plus on your browser and zooming in in that way. This means actually changing the font size settings in your browser to up to 200 %. This is not just important for people with disabilities. This is also important for people who would say they don’t have a disability, but they’ve simply increased the font size on their phone.
Or if your app or website is ever going to be internationalized, this will make it so much easier because going from English to say French means that many, many words are much larger.
When we’re talking about color perception, it’s important to understand that for the rest of your days as a designer or developer, you will be designing and creating code for people who perceive color differently. So you cannot use color as the only means of conveying information like state of checked or unchecked.
When we’re talking about people with motor disabilities, we’re thinking about the tap target size. So we want to make sure that the tap or clickable target area of the checkbox includes the label and is no smaller 24 by 24 pixels with a four pixel margin all the way around it. Now, that’s the minimum requirement to meet WCAG AA requirements. If you want to be a good designer, design the click or tap target area to have at least 44 by 44 pixels of area.
Now, technically, to meet WCAG AA requirements, the focus indication for keyboard is simply required to be visible in some way. But that’s actually a lot more work than meeting AA requirements of saying that the focus indication has a three to one minimum contrast ratio against adjacent elements.
Why? Because when you try to do something subtle that only meets WCAG AA requirements, that means you have to think about how each individual component looks when it’s in focus versus just making a blanket statement that this is our three to one contrast ratio across all elements. It’s actually much easier, technically, to meet WCAG AA requirements.
When we’re talking about blindness or low vision, we’re generally talking about people who are using a screen reader. So that means that your checkbox must have a name and a role and a state that is available to the screen reader, and it has to meet all of these criteria across platforms, devices, and viewports that are all different. So does this work on an Apple 5S with a 320 pixel wide screen? Just as well as it works on my 27 inch 5K monitor. Assistive technology requirements for checkboxes are fairly straightforward. When I’m using a keyboard or a screen reader and keyboard in combination, when I press the tab key, focus visibly moves to the checkbox. When I press the space bar with the checkbox in focus, that toggles the checkbox between states. With the screen reader, what I will hear is the name of the checkbox, and that’s going to be its label, and that label should make its purpose clear.
It must identify its role, so it will identify as a checkbox, and it must read out the state, so checked, unchecked, possibly disabled. If the checkbox is part of a group, I will at some point hear the group name when I focus on the checkbox. Mobile screen reader gestures are a little bit different in that I use swiping left or right to move focus to the checkbox, and I double-tap to toggle between checked and unchecked states.
If you have group of checkboxes, it must have a name. It’s exceedingly rare that you won’t need a name for a group of checkboxes. Here you can see that the name is wrapped in a legend element inside of a field set. The field set creates a group of checkboxes, the legend names the group of checkboxes. This is important because it gives additional context to the group of checkboxes for those who cannot see the label up above.
Now, you might have some specialty checkbox like this, where where you have a big card that is also a checkbox. Now, here’s the thing. The checkbox can be clickable anywhere on the box. That’s totally fine. But the screen reader must only focus the checkbox itself.
The reason for this is you want the screen reader to only read out the checkbox name, role, and state, and then read out the additional information in the card. The entire card cannot be wrapped inside of the label. The reason for this is because some screen readers will read all of that text before telling the user whether or not it’s a checkbox, it’s checked or unchecked, and that is not a great user experience. For developers, you can use aria-describedby to connect the input in the card text so that it’s read automatically after all of the information about the checkbox has been read.
Designers don’t break the mental model for checkboxes. Checkboxes are for affirming yes decisions. Don’t use checkboxes boxes to make detractive or negative no choices. If I have a pizza to customize, do not use no answers for the checkboxes. So not no pepperoni, no pineapple, no black olives. This becomes especially weird when someone is using a screen reader. Does no black olives checked means there are no black olives, or does no black olives unchecked means there’s no black olives? You can see how it gets weird and confusing very quickly.
Instead, let people uncheck what they don’t want. So if I hear that pepperoni is checked, I understand that in this current state, pepperoni will be included on this pizza. If I uncheck it, I easily understand that pepperoni will not be part of these pizza toppings.
And don’t do weird stuff with checkboxes, okay? It’s called a checkbox, not a check circle. I get it. There’s a little tiny checkbox inside of that circle, so maybe I can sort out that it’s a checkbox. But upon coming to these check circles, immediately they look like radio buttons instead of a checkbox. Don’t do that. And don’t separate the label text from the checkbox. The biggest reason for not separating the text label from the checkbox is for people with low vision who are using a magnifying application on their device. For them, the checkbox list might look like this, and it’s going to be difficult for them to find the text label of that checkbox. They’re going to have to scroll left and right, make sure they’re all lined up before they can really understand how these checkboxes work what their label is.
And don’t misuse other inputs. Don’t use toggle switches in place of checkboxes just because they look cool.
The semantics of a switch are different from that of a checkbox. When a screen reader comes across a switch, it doesn’t say checked or unchecked, it says on or off. I can’t on agree to the terms and conditions or off agree to the terms and conditions. And don’t use a single radio button in place of a checkbox. This is problematic because I cannot uncheck this radio button.
Now let’s discuss reasons to break the rules. When is it okay to do something different with checkboxes? Maybe you saw Google or Apple do something cool. That’s not a good reason. Just because Apple or Google or Netflix or one of these big tech companies does something doesn’t mean it was a good plan or that they had accessibility in mind when they did it. Maybe your manager thinks it looks cooler this way. That is also not a good reason to do it. As a designer, it’s your responsibility as a professional to stand up and advocate for the user. If you’re not doing this, you’re not being a good designer. We’re on a tight deadline, not an excuse to create inaccessible software. It doesn’t take any longer to do it right from the beginning. Maybe the devs said it’s not possible. The devs are wrong. I can guarantee you that 100 %. It is not impossible. Lastly, trying to get information up above the fold is such an old idea. This was important when people didn’t know how to scroll on the web, but I can guarantee you people know how to scroll now. Give your users some credit. They can scroll past the fold. Let your design breathe and be accessible for the good of everybody.
You can find all of this information and working examples on AtomicA11y.com. And if you’re looking for help implementing an accessibility program, TheBookOnAccessibility.com was written just for you. The end. Go forth.