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

[NickColley]

We need your help gathering more research around the conditionally revealing content pattern for this component, this is a shared issue with the Checkboxes component.

We'd appreciate it if you could take a look! Thanks :)

#37 (comment)

[blowfishsoup]

Just thought you should know that the highlighted state for the new Radios control has failed an accessibility audit in our service because the contrast between the yellow highlight and the white page background was deemed as having insufficient contrast.

[edwardhorsford]

Just thought you should know that the highlighted state for the new Radios control has failed an accessibility audit in our service because the contrast between the yellow highlight and the white page background was deemed as having insufficient contrast.

Could you share a screenshot of your implementation with the a radio focused? In addition to the yellow colour, the focussed item also has a thicker black border - which definitely has enough contrast.

[blowfishsoup]

Here's the page from the DAC report - I believe they tested the latest version of the control from the pattern library (I'm just confirming this with the development team)

[dashouse]

@blowfishsoup Hey Neil, this is the pre-v3 release of GOVUK Frontend, this met WCAG 2.0 but has since been updated to meet WCAG 2.1 in v3 and above. You can read about the changes in this release here https://github.com/alphagov/govuk-frontend/blob/master/CHANGELOG.md#300-breaking-release

[billwessel-dfe]

Hi, I'm getting an issue with radios where NVDA is reading out the first radio button twice effectively. In the example shown below, what I hear is "clickable radio button checked, clickable radio button GCSE not checked".

It looks like it only does this when NVDA is reading through the entire page. If I go and interact with the radios then the extra read out doesn't occur. This behaviour is occuring consistently across our sets of radios. Running latest version of NVDA (2019.2.1) and Firefox (70.0.1)

[roseacre]

I'm getting an accessibility violation (Elements must only use allowed ARIA attributes.) when conditionally revealing a textarea element on selection of a particular radio button.

distanceHtml is a textarea.

We do use our own components that wrap around the GovUK components so we can add customised error handling.

Is there a known issue or is it likely to be a problem with the implementation?

[36degrees]

@roseacre it's a known issue – see alphagov/govuk-frontend#979 for details.

[terrysimpson99]

The guidance on conditional radios and checkboxes states: "If the related question is complicated or has more than one part, show it on the next page in the process instead."

Many services conditionally revealed a date. I was made aware of this when a DAC assessment said it was a problem. I commented on this at: #59 (comment)

This issue keeps cropping up. When I quote the guidance, it doesn't always help. Some people assert a date is not complicated. Some people assert a date is one part. This means time is wasted in debate about the history or intent of the guidance. I need to be able to quote something more explicit.

Please can the guidance be modified to require conditional reveal

• should be avoided
• must not contain a date
• must not contain a fieldset

[exonian]

We received the following usability feedback on this component during our recent accessibility assessment from DAC. Obvious disclaimer that this is effectively one user's feedback.

When viewing this page in high contrast I noticed that the radio buttons do not have a
highlighted element when I hovered the pointer over them. This is an issue for me because
of my eye condition it causes me to rely on highlighted elements to visibly indicate which
radio button I am hovering over to help me determine that I am selecting the correct radio
button. It would benefit me that each radio button has an underline to appear/disappear on
the text when I hover over them to help me determine which radio button, I am hovering
over to help me select the correct one.

Low vision users using high contrast mode found there was no additional highlighting when
passing the mouse over elements when using high contrast mode. The standard cursor to a
hand change is present but this can be missed by users using this more and would benefit
from the element providing an additional cue such as an underline on focus.

[Kornelia-d]

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?

Has anyone had thoughts about the 'Select yes if...' question from 2018? We're rewriting some of our validation error messages, but would be good to know this is backed up by research.

[MazOneTwoOne]

Hello, hope this is the place to post this:

I’ve come across an issue with the radio buttons, and the 'dot' displaying slightly off-centre when using a second screen.

When a user is on one of our GOV.UK sites, clicks on the radio button and for what ever reason moves the browser window to their second screen and zooms out (75% or lower), the radio button ‘dot’ will display off-centre.

These are the steps to replicate it:

• Operating System: Mac OS
• Browser: Chrome or Safari
• Sites: Any GOV.UK site which uses radio button
• Action: Move browser to second screen and ‘zoom out’ the browser to 75% or less. Radio button 'dot' is displayed off-centre.

[querkmachine]

Hey @MazOneTwoOne,

This is unfortunately not something we have much control over, as it's a factor of how browsers and operating systems handle zooming and pixel rasterisation.

Normally, the radio button is 40×40 pixels and the dot is 20×20 pixels offset by 10 pixels from each edge.

At 75% zoom, this becomes a 30×30 pixel radio button and a 15×15 pixel dot, which is all good. The 10 pixel offset, however, has now become 7.5 pixels. As a display cannot physically render anything smaller than a pixel, this is a problem. In all likeliness, the offset on the top and left is being rounded down to 7 pixels and the bottom and right offsets are being rounded up to 8 pixels, causing the misalignment.

This issue may be manifesting more easily on one screen than the other due to differences in display PPI (pixels per inch). A Mac with a 227 PPI retina display will not suffer the issue as readily as a standard 72 PPI monitor, for example, as the retina display's physical pixels are smaller.

We could theoretically resolve this for some zoom levels by tweaking the size of the radios, but there'll always be some zoom levels that are forced to round unevenly. There is no 'one size fits all' solution.

[MazOneTwoOne]

Hey @MazOneTwoOne,

This is unfortunately not something we have much control over, as it's a factor of how browsers and operating systems handle zooming and pixel rasterisation.

Normally, the radio button is 40×40 pixels and the dot is 20×20 pixels offset by 10 pixels from each edge.

At 75% zoom, this becomes a 30×30 pixel radio button and a 15×15 pixel dot, which is all good. The 10 pixel offset, however, has now become 7.5 pixels. As a display cannot physically render anything smaller than a pixel, this is a problem. In all likeliness, the offset on the top and left is being rounded down to 7 pixels and the bottom and right offsets are being rounded up to 8 pixels, causing the misalignment.

This issue may be manifesting more easily on one screen than the other due to differences in display PPI (pixels per inch). A Mac with a 227 PPI retina display will not suffer the issue as readily as a standard 72 PPI monitor, for example, as the retina display's physical pixels are smaller.

We could theoretically resolve this for some zoom levels by tweaking the size of the radios, but there'll always be some zoom levels that are forced to round unevenly. There is no 'one size fits all' solution.

Thanks @querkmachine,

Makes complete sense. Thanks for having a look.

[CharlotteDowns]

We ran an external accessibility audit for some of the components and patterns in GOV.UK Frontend in May 2023. In that audit, we included examples of the Radio and Checkboxes components. We’re adding results from that audit here so that we can:

• document, discuss and address the findings
• inform future contributors of the findings

One usability issue raised

No visible hover for checkboxes and radios in high contrast mode. Can't tell what's being hovered.

The checkboxes and radio buttons do not display a visible change when receiving mouse hover in high contrast mode. This means that some users may not be able to distinguish when they are able to activate the component and form.

More detail in this issue:

• #3695

[quis]

Our team has noticed that when radio buttons have the disabled attribute set¹, the text does not meet WCAG standards² for colour contrast. This is true for the label³, and worse for the hint text⁴:

This is caused by some CSS in GOV.UK Frontend⁵.

I would suggest something like this to differentiate the disabled option from the others:

Colour alone isn’t used here to differentiate – there is still the semantics of the disabled attribute itself, the different cursor behaviour, and the content of the hint text.

This is what we will be implementing in our interface⁶ until a suitable fix is in place upstream.

---

1. Using disabled is not often the best way to do things (and is not documented in the Design System) but sometimes it’s appropriate
2. WCAG 2.0 AA requires a contrast ratio of 4.5:1 for ‘normal text’
3. $govuk-text-colour with opacity: .5 applied computes to a value of #858585, which gives a contrast ratio of 3.69:1 against a white background
4. $govuk-secondary-text-colour with opacity: .5 applied computes to a value of #a8acae, which gives a contrast ratio of 2.28:1 against a white background
5. https://github.com/alphagov/govuk-frontend/blob/fbed2b59889aff35fd1c65f1cd5ad368a5e4ddfe/packages/govuk-frontend/src/govuk/components/radios/_index.scss#L137
6. Fix colour contrast of disabled radio button text notifications-admin#4744

[querkmachine]

@quis Thanks for raising this.

I believe we consider this styling to be acceptable as WCAG criterion 1.4.3 includes an exception for text in disabled controls. Although the example given is in relation to button text, I believe this also applies to the radio button label in this instance, as it operates the form control and does not count as 'normal text'.

Styling the radio alone runs the risk of it the user clicking the label and being confused that the radio button doesn't respond, though admittedly most users aren't aware that they can click the label.

[quis]

@querkmachine thanks, I didn’t know about that criterion.

I’d still argue that it’s less confusing if the user can read the text which explains why the button doesn’t respond (‘Not available because…’) than to have a control whose presence they may be able to see but whose text they can’t read.

Second – and very specific to the example in the screenshot — but the link text inside the hint definitely needs to meet contrast since users can still interact with it.

Finally it feels weird to have some text styled in colours which are outside the normal Design System palette, but that’s not a WCAG thing.

[joelanman]

There are so many problems with disabled elements that I would try to find another solution if at all possible. What about having the message in plain text, not a radio?

Live keys are not available because your service is in trial mode

Edit: In particular that they get skipped in tab order:

When applied to a form field, the disabled attribute means that the field:
Should not receive focus.
Should be skipped in the tab order.

[haggishunt56]

When tabbing through screen elements on a form containing radio inputs, only the first radio button is highlighted. When shift+tabbing, only the last radio button is highlighted. To access elements in the middle of the list the user must change from the tab key to the arrow keys.
With that in mind, does this element still pass WCAG 2.1 SC 2.4.3? https://www.w3.org/WAI/WCAG21/Understanding/focus-order.html

[joelanman]

@haggishunt56 that is the standard approach to tabbing/keyboard controls for radios, so yes it passes:

https://www.accessibility-developer-guide.com/knowledge/keyboard-only/browsing-websites/

[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.