Menu
Components
Radios
Radio button groups allow users to make a single selection from a short list of options. They’re widely used across our question sets.
UX Owner: Jo Welling
UI Owner: Steven Roberts
Note: This component doesn't yet exist in Storybook, preliminary image(s) shown.
On this page
Example
When to use
Radio buttons can be used where:
- You’re asking the user to select only a single option from a pre-defined list
- You have 2-6 options
When not to use
Radio buttons shouldn’t be used where:
- Users are able to provide multiple answers to the same question (try a checkbox group instead)
- You need to reference a database for a lookup e.g. Address lookup or Job title
Variants
Trailing icon
If an additional visual aid can increase the recognition of selection options, an icon can be displayed within the radio button.
Note: Icon types/formats shouldn't be mixed within the same radio button group.
Hint text
Used when an option requires extra information that does not fit in main line or if the main line itself needs to be explained.
Note: See guidance on how to write hint text in writing radio button text section below
Hint text and trailing icon
The two feature toggles above operate independently, so can also be combined if it makes sense to do so.
Anatomy
Radio button layout
Radio buttons should always be stacked
A note on side-by-side layout
Where:
- there are only two selection options; and
- the labels are short enough that the two radio buttons are able to fit side-by-side even at the smallest device size
then consider using the [dual radio button](../dual-radio-button/) component.
Ordering radio buttons
There’s no exact science to this – ordering will often be subjective depending on the selection options.
However, as a general rule of thumb:
- Where there’s a clear logical ordering or grouping to the selection options (like a numerical scale), this order should be used
- Where there’s no clear logical ordering to the selection options, consider ordering the selection options by popularity (based on existing data)
- Where there’s an “Other” option (or similar such as “More”), this should always come last in the list
Example
Writing radio button text
Radio button text should:
- be concise
Where there’s a clear logical ordering or grouping to the selection options (like a numerical scale), this order should be used - clearly differentiate one selection option from another
Avoid any ambiguous terminology
Radio button hint text should:
- be kept to a maximum of 2 lines where possible
Ideally try to keep to a single line but if needed we can stretch to 2 lines with the goal of keeping it short and simple for users - be written using sentence case
Pronouns such people’s names and brand names should still be capitalised. Unless there’s good reason to use one, hint text generally doesn’t need a full stop at the end either
How to deal with 6+ options
When there are more than 6 options, you may still be able to use radio buttons to show the more popular answers, while hiding less popular options behind the last radio button.
In this case, the last radio button should be labelled appropriately to make it clear it will reveal further options (e.g. “Other”, or “More”).
Example
The additional options should only be revealed following the selection of the appropriate radio button.
Note: this isn’t a child question. In the example above, the revealed input is part of the same set of answers. No additional question or visual indentation is required.
Components for selecting additional options
In the illustration above, a dropdown is revealed when the “Somewhere else” radio button is selected. However, dropdowns aren’t the only components that can be combined with radio sets in this way.
Dropdowns, steppers, date inputs, autocompletes, and numeric inputs are some of the more common components that can be used to allow the user to select an additional option.
Extensions of this pattern
You don’t have to show 5 selection options in addition to the “Other” radio button. Depending on the popularity of the selection options, you can use this same pattern but choose to show only the most commonly selected options.
Example
In this illustration, let’s imagine we’re asking users for the date they’d like their insurance to start. Let’s also imagine we know from historical data that 90% of users want their policy to start either the same day or the following day.
On that basis, only 2 dates (today and tomorrow) are selectable initially, with all other dates being hidden behind the third radio button. While this increases an extra tap for some, for the majority of users, this makes the process far easier.
Selection states
Unselected
Field has not been clicked yet by a user
Selected
Field has been clicked yet by a user
Interaction states
For general information and guidance about these states, see interaction states.
Hover
When a user’s cursor moves over a radio button there are subtle changes to both the border of the enclosed radio indicator and the background colour of the entire radio button.
Note: Selected radio buttons don’t have a hover state as you can’t interact with an already selected radio button
Focus
When focus is applied to a radio button an offset border is applied.
Note: The focus state is also applied where the component is both in focus and on hover at the same time.
Disabled
Field is deactivated and can’t be interacted with. Both selected and unselected radio buttons can be disabled. When disabled, there are no hover or focus interactions.
Error validation states
Radio buttons do not have an error validation state. Any associated error is indicated through validation messaging and error styling on the question itself. See error validation for further information.
Similar components
There are a range of components that resemble the radio button, either visually or in their functionality.
Where to find this component
Documentation version history
Last updated Monday, 29th March 2021 21:39 by Gemma D.