Radios

[govuk-design-system]

Use this issue to discuss this component in the GOV.UK Design System.

[lukechaput]

Interested in the advice to use error messages like 'Select yes if...'.
When combined with the fact that - after an error is generated - the focus is on the 'Yes' radio option, it feels like it could be misinterpreted as a prompt for the user to select yes. Would be good to see any research into this. Or perhaps the advice could be changed so that error messages do not give undue emphasis to one of the radio options?

[amyhupe]

Dropbox Paper audit

On 15 October 2018 the Design System team reviewed a Dropbox Paper document discussing the Radios component.

The aim was to reduce the number of places containing guidance and code by:

• migrating relevant, useful content into the Design System itself
• recording important research findings in the community backlog
• removing the original Dropbox Paper page

Below is a record of the outcomes of that review.

If you need to, you can see the original Dropbox Paper content in the internet archive.

Review outcomes

Updates to the Design System

The Design System team will carry out the following updates to ensure that relevant, useful content from the Dropbox Paper file is added to the Design System.

• Add guidance to radios and checkboxes pages saying not to rely on visual differences between radios and checkboxes to guide users on how many options they can select.
• Update examples of radios and checkboxes pages to make sure it reflects this guidance.
• Add guidance on how to order radios, for example, alphabetically or common scenarios first?
• Add guidance saying to use a ‘none of the above’ option if necessary
• Add guidance saying not to pre-select radios and checkboxes

[amyhupe]

Based on the above, we've updated the Design System guidance for:

• radios
• checkboxes

[edwardhorsford]

The dividers option appears to hardcode the width to 40px - meaning text other than 'or' is likely to break across several lines.

I was trying to use dividers to group some related radios with a heading - though I guess this might be unwanted use case depending on how that text appeared to AT users.

[NickColley]

@edwardhorsford I think that is also discussed in alphagov/govuk-frontend#1079

The divider markup doesn't have the correct semantics to do anything other than 'or' right now...

[terrysimpson99]

The term "inline" buttons is obscure for me and I didn't initially know it referred to an arrangement rather than a function or aesthetic. I worked out people were referring to an arrangement but it wasn't clear if it meant vertical or horizontal. I decided it meant vertically arranged because that's clearly a line of adjacent buttons, unlike horizontally arranged buttons mingled with text. Can the guidance say 'horizontal' instead of 'inline' and 'vertical' instead of stack'?

[amyhupe]

Hi @terrysimpson99 – thank you for your feedback, it's a good point.

I think we'd like to include the word "inline" as that's how it's described in the code, but we could consider also adding horizontal and vertical too, to make it clearer.

I will discuss it with the team today and come back to you.

[ChazUK]

Are there any examples of Conditional Radio buttons with an error on one of the conditional fields?

[dashouse]

Hi @ChazUK, this is the suggested style in that scenario

This is achieved by adding the classes govuk-form-group--error on the top level govuk-form-group container and govuk-input--error on the conditionally revealed input

[rinto-cyriac]

We are working on designing a form for the complaints procedure and wanted to list the different departments in the council into radio buttons list. As of now, we have 13 lists and we are worried whether this long list would affect usability.

What is the optimal number of radio lists for a better user experience?

[edwardhorsford]

@rinto-cyriac I have no direct experience, but have a hunch you can get away with more than you might expect. I'd say it's totally worth trying as one list and seeing how it tests. I've seen anecdotal reports on slack of teams testing with larger numbers than they expected to work, and the tests being positive.

A big factor that will affect how many you can show: will users know when they see the option that it's the right one (or will they have to continually scroll back and forth to compare several)?

If relevant you may be able to group the options too.

[rinto-cyriac]

@edwardhorsford — thanks Ed for the comment, that's an interesting theory to validate it. I was also thinking of having a guidance text underneath some radios/departments that might seem confusing for the user (eg: reporting a dog foul might come under Leisure, parks and attractions as well as Environment)

[edwardhorsford]

@rinto-cyriac have you considered an autocomplete? It sounds like it might be appropriate. You might also take a look at the FCO legalisation service - which did some great work about helping users select from a long list of possible documents - merging search with other selection mechanisms.

[rinto-cyriac]

@edwardhorsford — thank you. That was really valuable. Our scope didn't allow to go that extent initially, but it seems now that this component could be used in other areas in the website as well.

[paulwaitehomeoffice]

The Nunjucks macro option to conditionally reveal content currently accepts an htmloption:

conditional: {
  html: "<p>This is the HTML content</p>"
}

This HTML content is then rendered inside the fields containing the radios, and is revealed/hidden when the radio button is selected/deselected.

Sometimes, it's desirable to have the revealed content appear after the fieldset containing the radio button, rather than within it — for example, when the revealed content is itself a fieldset. (Nested field sets can be a bit confusing to navigate when using screenreaders.)

Is there any interest in allowing macro users to define separate content to be revealed/hidden? Perhaps by taking the ID attribute of the content?

conditional: {
  id: "id_attribute_of_content_to_be_revealed"
}

Or a boolean attribute to render the content after the fieldset, rather than within it?

conditional: {
  html: "<p>This is the HTML content</p>",
  doRenderAfterFieldset: true // TODO: come up with a sane name for this option
}

Or something else entirely?

See also alphagov/govuk-frontend#718

[oddjones]

Has anybody come across a pattern for providing supporting information (in the form of a link) for the options in a radio group?

So we have a use case where we need to present a user with a simple choice which requires (in many cases) some background reading to support the choice.

Our first thought was to just add links to the hint text like this:

but we were concerned that the links would impact on the usability of the radio buttons - with hit-targets getting mixed up for users with mobility issues.

We've come across this pattern in use:

Which suggests a supporting document alongside the option (but doesn't actively link to it) - is this a pattern which has been tested and proven?

If so, we were wondering whether it might be feasible to extand it by introducing a link to the explanatory item (content length permitting) - so...

[joelanman]

@oddjones it's very hard to make this accessible, so I think this is a good candidate for this pattern:
https://design-system.service.gov.uk/patterns/question-pages/#asking-complex-questions-without-using-hint-text
where you explain first, then ask the question

[oddjones]

@joelanman nice - yeah that's a really good shout. I think we're going to go with your suggested pattern with a details component to divulge the additional access to the source documents, then keep the radios clear as suggested in the pattern. Thanks for commenting

[mattia-gobbo]

For 'Send an SR1 medical evidence form', to be compliant with 'WCAG 2.1 success criterion 4.1.2 Name, Role, Value', our service only uses conditionally revealing radios for simple questions.
We had to split a question into 2 separate ones in cases in which: 

• long inputs were required (like the example of a text area as shown below);
• specific patterns had to be followed (like in the case of NINo shown below) where a special validation is required and the question needs to follow a specific structure including label and hint text.
  

[stephenjmcneill1971]

Hi can someone give some background on the following accessibility error raised.

Conditionally revealed radio buttons are not announced to screen readers

On the page (inserted below), there are three radio buttons that users can select from. Two of those radio buttons contain a conditionally revealed input field where users give either their phone number or their email address. In the speech viewer of the screen reader NVDA the radio button is listed as checked however the expanded action is not registered. This was done in Microsoft Edge.

However when using Firefox the screen reader registers the conditional radio button as expanded and the word expanded appears in the speech viewer. Visually, it is clear that when users select this the field expands, but this information is not communicated via all screen readers. This will be frustrating for blind and visually impaired users who are not made aware of the dynamic change that appears on screen.

It is not clear why this is occurring, as it has been coded to specification, meaning that aria-expanded="true" is present. However, at the time of testing, this information was not available when the journey was completed on iOS, Android, Chrome and Edge. It was available and clearly announced on Firefox.

We understand that the use of aria-expanded has posed challenges in situations like this. While its support is improving, we acknowledge that there may still be instances where it isn't fully compatible. Therefore were asking for guidance on the optimal approach to implement conditional revealed forms.

[HughePaul]

Should the reveals for radio buttons still be hidden if javascript is disabled/unavailable. I was fairly hiding them (and then revealing them) relied on javascript being enabled on the page in previous versions of govuk frontend.

[andrewscrivener]

Following an accessibility audit we've had a "Major Impact on Functionality" flag as we're using the unsupported aria-expanded="false" on the conditional radios.

Here's a screengrab of Axe run against the radio component.

I've seen that this was discussed back in 2018 but thought I'd bump it here for current guidance on GDS' stance.

[amyb-hiveit]

Hi, we've had a usability issue raised by DAC regarding the hover state on small radio buttons:

Our low vision analyst has difficulty in distinguishing the mouse hover focus on radio buttons throughout the service as it lacks a sufficient colour contrast between the hover outline of the radio button and the background of the webpage. Low vision users, who may already have difficulty discerning visual elements, might find it challenging to see and select the radio button due to the insufficient colour contrast.

While this isn't a WCAG failure we'd still like to address it to improve the usability of our site.

DAC recommended making the grey darker so there's sufficient contrast, I've tried changing it to dark-grey instead of mid-grey but I think this looks a bit odd:

Instead, I think increasing the border width of the radio would help make the hover action more visible:

Does this seem like an acceptable solution? If so, I'd be happy to raise a PR for it.

[CharlotteDowns]

@andrewscrivener

We use aria-expanded="false" on the conditional radios because although unsupported it gave users of assistive technology that we tested with an awareness of what was happening within that radio item. I'll try and find our research summary but here is a blog post we wrote in 2021, An update on the accessibility of conditionally revealed questions

[beccagorton]

Like others in the thread, our recent accessibility audit of our internal service flagged that conditionally revealed inputs may not be communicated to users using screen readers.

The auditors recommended adding visually hidden text within a. <span> to reiterate that there would be a condition if the user were to answer 'Yes' for example. We tested this, and by adding the span before the label would allow the context to be provided that a reveal is to be expected.

Our development team had a look at implementing this. They found that it can be achieved in plain text HTML more simply, but may require changes to the nunjucks component in order to apply this fix using the nunjucks components.

[lalexander12]

I'm a bit thrown by the error message used in the last example in the guidance:

Email address cannot be blank

Error message guidance steers us to always offer direction in such an instance, for example: Enter an email address.

[aarongrey215]

Similar to some themes of this thread - we accessibility audited a demo of a case management system that uses a conditional radio reveal of a nested radio set

While aware this is not an example option on the component write up (another solution for this is to suggest having the second nested question take place on a sequential screen but we may have push back on this) - would be good to have some technical guidance to see how feasible it would be to address this:

Issue raised:

Description of original issue - Conditionally revealed radio button set skipped using keyboard and does not receive tab focus. When a radio group with conditionally revealed set visually appears - when a user tabs to the next element, then the conditionally revealed set is skipped.

Screen-reader users may expect this to be only a set of three radio buttons as they only hear “Fine radio selected, 1 of 3”. After selecting an option, users tab to the next control, and instead of this being the nested set - it skips the conditional radios entirely so they may be unable to complete this section without creating a form error.

After reviewing the first fix - We found it to be partially resolved. The nested set was now next in the tab order but also connected in ways that would be confusing for AT users:

• If users Tab after selecting an option in the nested set - focus then goes back to the first level radio options. Pressing Tab should take the user forwards to the next interactive control ("continue" button).

• Tab key should only allow the user to jump to the whole radio group and not move between listed individual options.
• up/down arrow keys moves selection through all radio options across both groups - jumping between the two groups.
• Screen reader combines all options in announcement "radio 1 of 6" when a conditional revealed set is opened - changing count from "1 of 3" when opened.

Proposed expected behaviour:

• Tab/Shift-Tab should be the only way to move between the two radio groups.
• Each set should function and be perceived independently.
• arrow keys should be the only control to change selection and tabbing through the list should not be possible.

see below diagram we are using to explain this:

Would be good to know if this kind of conditional radio/radio pattern has been explored and if anyone has ran into similar issues with this kind of structure being proposed by designers - thanks :)

[Flora-Plan]

Maximum number of radio options?

Are there any findings or guidance on the maximum number of options to include in a list of radio items in .gov interfaces?

There is debate around the maximum number of radio options that you can/should include in a radio button list.

No maximum
(https://adamsilver.io/blog/dont-be-afraid-of-a-long-list-of-radio-buttons/)

Max 5-7 options
It is advised in UX to keep the number of radio options below 7 (Microsoft guidelines) or 5 (Google guidelines)

Here is further discussion on the max number of radio options. (https://ux.stackexchange.com/questions/86325/radio-buttons-or-dropdown-for-same-list-of-options)

[Flora-Plan]

Maximum number of radio options?

Are there any findings or guidance on the maximum number of options to include in a list of radio items in .gov interfaces?

There is debate around the maximum number of radio options that you can/should include in a radio button list.

No maximum (https://adamsilver.io/blog/dont-be-afraid-of-a-long-list-of-radio-buttons/)

Max 5-7 options It is advised in UX to keep the number of radio options below 7 (Microsoft guidelines) or 5 (Google guidelines)

Here is further discussion on the max number of radio options. (https://ux.stackexchange.com/questions/86325/radio-buttons-or-dropdown-for-same-list-of-options)

Discussion on this topic in cross gov slack
https://ukgovernmentdigital.slack.com/archives/C6DMEH5R6/p1771325033215149

[JVKE93]

Voiceover - iOS vs MacOS behaviour

Apologies if this is a known issue, but there seems to be an issue with how descriptions work in iOS vs the MacOS behaviour.

When navigating through radio buttons on iOS the description provided via the aria-describedby attribute is provided to the user each time a radio is navigated to. This is not the case when using VoiceOver on Mac.

This seems like frustrating behaviour and has been raised by a screen reader user during user research with DfE.

Can provide recordings.