Radio buttons are used for selection of only one option from a group of values.
Each radio button group requires a minimum of 2 options to choose from.
Use a Select component if there are more than 6 options to choose from.
Only one option within a radio button group may be selected at one time, and one must be selected by the user (otherwise don't use radio buttons).
Although one of the options in a radio button group may be selected by default, it's recommended that none of them be selected by default so that users are more aware of the decision. Setting a default value can also discourage users from making conscious decisions, seem pushy, or alienate users who don’t fit into your assumptions.
Some radio button options may begin disabled until selections are made elsewhere on the page, while others may become disabled as the result of selections elsewhere. In such cases, the corresponding selection should be in view at the same time as the radio button group.
Radio buttons that are listed vertically are easier to read than those that are listed horizontally. Horizontal listings can make it difficult to tell which label pertains to which radio button.
Selecting a radio button should not trigger unexpected changes in context, such as causing significant changes to the page content or opening a new window
A form validation checks user input against success criteria before passing the data to the server. If there is a problem with the data then the system generates an error to help the user complete their task. An error notification is displayed at top of page, and any radio button groups that are in error are visually indicated.
Title case, 2-3 words maximum.
Do not combine actions in a label (exception: "Customize & Buy").
If standard labels don't fit the button's purpose, align label with the task the user is attempting.
Please refer to the Dell Technologies branding website, https://brand.delltechnologies.com/faq/#voice, for further information regarding call-to-action labels and usage.
A minimum touch target of 34 pixels in height should be used to assist with touchscreen interaction.
Provide instructions within labels to help users understand how to complete the form and individual form controls. Providing instructions outside of labels allows more flexible positioning and design, but sometimes it can be missed. It is also not supported by some web browsers (typically older versions) and assistive technologies that don’t implement WAI-ARIA.
Validate input (radio button selected) by the user and provide options to undo changes and confirm data entry.
Notify users about successful task completion, any errors, and provide instructions to help them correct mistakes.
Users should be able to select a radio button by clicking on the button directly and by clicking on its label. This is useful to some with motor disabilities.
Use the <label> element, and in specific cases other mechanisms (e.g. WAI-ARIA, title attribute etc.), to identify each form control.
Matching for="name" and id="name" values associate the label with the appropriate form control.
Because id must be unique on each page, only one label can be associated to each unique form element. This means you cannot have one label for multiple form elements. Additionally, screen readers do not support multiple labels that are associated to the same form element.
As a best practice, each radio button group should make use of <fieldset> (a tag that's used to group related elements in a form) and <legend> (a tag that defines a heading for the <fieldset> element). This is especially true for forms submitting data. Nested fieldsets should generally be avoided. In screen readers, the legend text is generally read for each control in the fieldset, so the legend text should be brief and descriptive. (see Inputs for more details)
The aria-required attribute informs assistive technologies about required controls so that they are appropriately announced to the users (as opposed to validating the input). Most current web browsers automatically set its value to true when the HTML5 required attribute is present.
The radiogroup role defines a container for a set of ARIA radio buttons.
The label for the radio group is defined using aria-labelledby attribute.
The labels for the radio buttons are defined by the text nodes of each radio button.
The radio button that is currently selected is identified using aria-checked=“true”.
Only one radio button can be selected at a time, all other radio buttons should define aria-checked as “false".
A div element with role radio has onkeydown event to support keyboard activation of the radio.
A div element with role radio has tabindex="0" to become part of the tab order of the page.
Each radio has tabindex="-1" except one.
CSS Generated Content is used to visually indicate the state of radio (e.g. checked, unchecked). To ensure the visual state will be visible when browsers or operating system use “High Contrast” settings by people with visual impairments; the visuals are created in CSS rather than via the use of a background image. (Note: CSS background image techniques result in visual state disappearing when browsers or operating systems are configured to display high contrast themes.)
The setRadioButton function uses aria-checked attribute to make sure the information communicated to assistive technology is the same as the visual state. (e.g. img element).
The onfocus and onblur event handlers on radio support provide visual focus styling for keyboard only users.
If the submitted data contains errors, it is convenient to set the focus to the first <input> element that contains an error.
See this ARIA radiogroup and radio example for more info.