Forms - Radio buttons

A repository of styled and “styled” form control patterns, and how they are announced by screen readers.

Why?

Form controls are necessary in many interfaces, but are often considered annoying, if not downright difficult, to style. Many of the markup patterns presented here can serve as a baseline for building more attractive form controls without having to exclude users who may rely on assistive technology to get things done.

How you design and implement your toggle buttons is quite up to you, but I hope you’ll remember this post when it comes to adding this particular component to your pattern library. There’s no reason why toggle buttons — or any interface component for that matter — should marginalize the number of people they often do.

You can take the basics explored here and add all sorts of design nuances, including animation. It’s just important to lay a solid foundation first.

Checklist

• Use form elements such as checkboxes for on/off toggles if you are certain the user won’t believe they are for submitting data.
• Use <button> elements, not links, with aria-pressed or role="switch" plus aria-checked.
• Don’t change label and state together.
• When using visual “on” and “off” text labels (or similar) you can override these with a unique label via aria-labelledby.
• Be careful to make sure the contrast level between the button’s text and background color meets WCAG 2.0 requirements.

See the source link for very detailed descriptions of all of these points.

Setting the tabindex of the focused element to “0” ensures that if the user tabs away from the widget and then returns, the selected item within the group retains focus. Note that updating the tabindex to “0” requires also updating the previously selected item to tabindex="-1". This technique involves programmatically moving focus in response to key events and updating the tabindex to reflect the currently focused item. To do this:

Bind a key down handler to each element in the group, and when an arrow key is used to move to another element:

1. programmatically apply focus to the new element,
2. update the tabindex of the focused element to “0”, and
3. update the tabindex of the previously focused element to “-1”.

Here’s an example of a WAI-ARIA tree view using this technique.

For a more visual explanation, see the following video by Rob Dodson:

Early in the development of GOV.UK we observed in research how a majority of users would click on radio button or checkbox controls rather than on their labels, despite the fact that the labels are much bigger and therefore easier to click (see Fitt’s Law).

[…]

We reasoned that this was because users didn’t know whether or not they could click on the labels. Many websites don’t let you click on labels, so choosing to always click on the control is perfectly rational user behaviour.

[…]

First we thought we’d try to make it really obvious that you could click our labels, so we coloured them grey and made them respond to the mouse hovering over them.

We thought this would work, so we rolled out the design across services on GOV.UK. We saw again and again though in lab research that most users still clicked on the controls.

[…]

In our latest iteration we’ve replaced the native browser controls with custom ones, which all our supported browsers will get.

We’ve also removed the grey background, as it did not have the effect on user behaviour that it was intended to.