Radio Button

This component is often used for questions with binary or opposite answers, such as yes or no, or true or false. This is the only time that radio buttons may be aligned horizontally. Read Alignment guidance. The exception to this rule is settings with an on or off option in which toggle switches would be a better choice.

Although one option in a radio button group may be selected by default, consider the experience from a user’s perspective. Selecting an option on a user’s behalf may come off as presumptive and risks alienating users by making assumptions about their preferences or motivations. Furthermore, users may not notice that a selection has already been made for them.


Consider adding a ‘none of the above’ option to avoid forcing a selection. If it’s important that users are able to easily clear their selection, use checkboxes.

Radio buttons require a minimum of two options. When listing more than five options, consider whether the select component provides a better experience for the user. Group labels—which are called ‘fieldset legend’ in code—are optional. However, if the individual option labels do not provide sufficient context, including a group label can clarify intent and help the user choose the appropriate option. This is particularly important when considering how people using assistive technology navigate through a site.

Radio buttons are left-aligned and typically vertically stacked when there are three or more options. Stacking radio buttons vertically makes them easier to scan and read, especially when the label text wraps to two lines.


Radio buttons can align horizontally if there are two options with short labels, for example, yes or no. If aligning radio buttons horizontally, make sure there’s enough space between the options so it’s clear which label belongs to which radio button.

The radio button or the label text can be selected.

All radio buttons and radio button groups must have clear, concise, and unique labels
Labels must also be programmatically associated with assistive technology users.
WCAG 2.1: 1.3.1 Info and Relationships
WCAG 2.1: 2.4.6 Headings and Labels


Avoid default selections
Preselected choices are considered a deceptive practice for all users. Implement a default unselected state with radio button groups.


All keyboard interactions and ARIA labels must meet accessibility criteria
WAI-ARIA Authoring Practices

Because radio buttons require users to select only one choice, make sure that the options are clear and distinct. Like checkboxes, the biggest usability problems for radio buttons come from labels that are vague, misleading, or describe options that are difficult for users to understand. All labels should be consistent in length, tense, and meaning.

Capitalization
Use title case for group (legend) labels and sentence case for all other labels.


Character length
Radio button labels should be scannable, consistent, and concise.


Describing options
Make sure radio button options are organized in a logical and meaningful way. Keep in mind that when listing items alphabetically, the order will change when text is localized.


Labels
Always use clear and concise labels for radio buttons so options are easily scannable by users. Make sure choices don’t overlap. For group labels, a best practice is to state the category of the grouping.
Do:

• Ages 1 to 10
• Ages 11 to 15
• Ages 16 to 20

Don’t:

• Ages 1 to 10
• Ages 10 to 16
• Ages 16 to 20
  
  

Punctuation
Avoid punctuating radio button labels.

Specificity
Be explicit about the results of a user’s selection or what they are enabling or disabling.

Tone
Use a positive tone, signaling affirmation, instead of negation to avoid confusing users. Use imperative verbs when writing labels.
Do: Opt in for email promotions
Don’t: Opt out of email promotions