Radio buttons

All right, let’s talk about radio buttons and what you actually need to know about radio buttons right now. This information is adapted from atomica11y, atomicay11y.com, and from TheBookOnAccessibility.com. Now, you notice this lesson isn’t titled accessible radio buttons, because if you made a radio button that isn’t accessible, no matter how pretty or cool you think it is, all you really made is crappy decoration. If at its core, it’s not accessible, you just made something pretty to look at, and that’s not what we’re here to do.

Now, we can’t cover every possible accessibility rule and nuance about radio buttons and accessibility in this, but we can cover the practical basics. You can always look at atomica11y.com for demos and examples and complete acceptance criteria on what a radio button looks like, how it should be put together, how to code it, how to design it, and all the rules that you might need.

Let’s start with a history lesson. Why are they called radio buttons? The concept of radio buttons comes from old radios that had buttons that might have looked like this. This was the way that you pre-programmed in the radio stations you wanted to listen to.

It was a mechanical system that allowed you to choose one button and it would cause the other button to pop out. So if I pushed in the first button and then I pushed in the third button, the first button would pop out.

To be sure that we’re talking about the same thing, a radio button is a group of inputs that allow the selection of one input from a set of input fields. You can only select one, and that is different from checkboxes that allow you to select multiple items from the group. When we’re talking about accessible radio buttons, these are the disabilities that we want to make sure we don’t create barriers for. When we’re talking about people with low vision, we’re talking about people who are using their smartphones, they’re using their desktop devices, increasing the font size in their browser. Now, that’s different from hitting Command or Control + and zooming in that way. They are literally changing the size of the default fonts in their machines. They might be using magnification tools to zoom way in on the screen, or on a mobile device, they might be pinching and zooming in to see things that are difficult for them to see.

Not everyone sees color the same way. There are a variety of differences in the way people see color that we have to accommodate.

When we’re talking about people with motor disabilities, we’re generally talking about people who can’t a mouse or tap on their screen. They may be using a keyboard or a Switch device that is something akin to a game controller. They may also be using voice control to actually control their machine by simply speaking to it.

When we’re talking about blindness, we’re generally talking about people who are using a smartphone, they’re using their desktop machine, but they’re not able to use the screen. They will use applications called screen readers in combination with a keyboard to read what’s happening on screen to them. Or if they’re using their smartphone, they’ll be using a screen reader and swiping and tapping in a specific sequence to use their device.

Now, it’s important that we begin our design accommodating people with low vision. When we’re talking about low vision, we may just be talking about people who would say they don’t have a disability. They’ve simply bumped up the text size on their phone so they can read it easier.

Text must be able to resize up to 200% with no loss of information. This is important not just for low vision. If your application is planning to be internationalized, it’s very important that text be able to grow and expand. For example, if you’re going from English to French, French words are often much longer than English. You must accommodate that extra space. If you’re designing for low vision, you are also designing for internationalization.

To further accommodate people with low vision, the text label must have a 4.5:1 minimum contrast ratio, and the radio indicator must have a 3:1 minimum contrast ratio. Also, the radio indicator must be in visual proximity to the label. So don’t flip the radio direction and don’t separate the label text from the radio indicator.

This matters so much because people with low vision use magnification tools, so they may experience your application like this, zoomed way, way in. If you separate the indicator from the label, it’s very difficult for someone to understand what this is. Are these radio buttons? Are they checkboxes? It’s impossible to tell unless someone scrolls back and forth across the screen.

And don’t mix radio button conventions with checkboxes. Don’t make radio buttons that look like checkboxes or checkboxes that work like radio buttons.

When we’re talking about color perception, color cannot be used as the only means of conveying meaning. For example, these radio buttons on the left use red or green to indicate what is selected and what’s not. However, people with red-green color blindness won’t be able to understand which of these is selected. To accommodate people with motor disabilities, we must make sure that the Click or Tap target area includes the label and is no smaller than 24 by 24 pixels. Notice how I can click on the label or the indicator to select the radio input. Now, to go above and beyond that, the Click and Tap target area can include the label and be no smaller than 44 by 44 pixel to meet AAA requirements.

When we’re talking about assistive technology and how people interact with radio buttons, there is a prescribed set of keyboard and screen reader interactions and mobile screen reader gestures that we must follow. People who are using the keyboard or the screen reader in combination with the keyboard will use the tab key to move focus to the radio button group. If none of the radio buttons are selected, it will move to the first radio button in the group. But if a radio button is selected, focus will move to the selected radio button. That’s so crucial to understand, and we’ll see an example of that later. If the radio button is not checked, the space bar will select that radio button. If the radio button is already selected, the space bar will do nothing. You cannot unselect a radio button without selecting another radio button. And it is the arrow keys that move focus to and select the previous or next radio button in the group. You do not move from radio button to radio button with the tab key. It is the arrow keys that change the selection and move focus between radio buttons. For people using a mobile screen reader, they will swipe left or right to move focus to the next radio button and double tap to select it. And again, like the space bar, if I double tap on a selected radio button, nothing will happen.

When the screen reader encounters a radio button, it must read its name, role, group, and state. So it will identify its label. It will let the person using the screen reader know that it is a radio button, the group name of the radio button, and it will declare its state, whether it’s selected or checked, depending on the screen reader and the browser combination. Here, the user has pressed the tab key to move to the first input and is using the arrow keys to change the selection between the radio buttons. You can see the outline around it as the focus indication. The focus indication must be visible in some way to meet AA requirements, but often it’s easier to simply create a blanket, AAA requirement of a three to one minimum contrast ratio against the default state and adjacent elements. For people using a screen reader, when they encounter radio buttons, they will hear its name, role, state, and group. So they will hear the label of the radio input, they’ll hear that it is a radio button, and they will hear that it is expressing its state of checked or unchecked or selected. They will also hear any hints or errors that are read after the label, and all radio input groups require a group name. Let’s see an example.

Choose your favorite NATO letter. Alpha. Selected. Radio button. One of three. Choose your favorite NATO letter. Bravo. Selected. Radio button. Two of three. Choose your favorite NATO letter. Charlie. This is the best letter. Selected. Radio button. Three of three. Choose your favorite NATO letter.

Without exception, radio inputs must have a group name. This is a little more complicated than simply a heading above the radio inputs. The radio inputs must be composed of a field set with a legend that gives the radio inputs a group name. If you don’t have a group name for the radio inputs, radio inputs can be very, very confusing.

Specialty radio buttons like these cards can be clickable anywhere on the card, but only the radio button itself should receive keyboard focus. In this scenario, The screen reader would read the name, role, state, and group name of the card, and then it would also read the text after the card. You cannot wrap the entire card inside the label of the radio input. Different screen readers will read that content in different If there is an enormous amount of text in the card, it will be difficult for someone using a screen reader to learn that it is a radio button and what its state is if it’s reading all of that text first.

Don’t misuse other inputs in place of radio buttons. For instance, don’t use toggle switches in a case where radio buttons would be more suitable. Radio inputs have very different semantics from toggle switches. Toggle switches describe their state to someone using a screen reader as on or off instead of checked or unchecked. Don’t use a single radio selection in place of a checkbox. It’s impossible to uncheck a radio button. Just use a checkbox where a checkbox is appropriate.

Lastly, don’t auto-submit on selection. While with a mouse, you can select any radio button at any time, that is impossible with a keyboard. Someone using a keyboard will have to go through each and every single radio input in order to select the one that they want. If the form auto-submits on selection of a radio button, they won’t be able to select the radio button they want.

Let’s look at some common reasons to break the rules. Are there times when it’s okay to deviate from accessible patterns? Maybe you saw Apple or Google do some weird thing with radio buttons, but just because Apple and Google are big, successful companies, doesn’t mean everything they do was created with people with disabilities in mind. Maybe your manager thinks that something inaccessible looks way cooler. It is your responsibility to advocate for people with disabilities. Do the right thing. Maybe the project is on a deadline and people are saying, We don’t have time for accessibility. That’s nonsense. It doesn’t take any longer to create an accessible radio button than it does an inaccessible radio button. Or maybe your developers are making up a story about how it’s not possible to make the radio buttons accessible for your application. I can assure you they are wrong. There are plenty of examples on AtomicA11y.com where they can learn about how to make an accessible radio button.

And that’s the end. Go forth and come back to atomica11y.com when you need help. And if you’re building an enterprise-level accessibility program, TheBookOnAccessibility.com is written just for you. Thank you.