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 https://github.com/alphagov/govuk-frontend/issues/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 https://github.com/alphagov/govuk-frontend/issues/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 :)

https://github.com/alphagov/govuk-design-system-backlog/issues/37#issuecomment-530323535

[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 https://github.com/alphagov/govuk-frontend/issues/979 for details.

[CharlotteDowns]

We’ve updated the guidance for radios

The updated guidance gives more information about how to use conditionally revealing questions in your service, and what you need to consider.

Problems we wanted to solve

An earlier version of the guidance did not clearly describe what can be conditionally revealed.

Using conditional reveals for text content

Use of conditional reveals to reveal text failed WCAG 4.1.2 Name, Role, Value in an audit of GOV.UK.

When text is conditionally revealed, it is unlikely to be discovered by a screen reader user in 'forms mode' as the text is not focusable.

Text content in a conditional reveal should be avoided.

Using conditional reveals with multiple form fields

In our research, a user did not seem to understand the structure of a page when it conditionally revealed multiple questions.

Alex Newman, Department for Work and Pensions, shared similar findings from their user research as a comment in the backlog discussion for checkboxes

A Lead Auditor at the Digital Accessibility Centre (DAC), who often audits government services, told us that in their experience, 'long' conditional reveals caused navigation issues for users. Conditional reveals increase the length of a page which can be disorientating for users.

A ‘short’ conditional reveal, such as a single input field is usually fine.

What we decided and what has changed

We've updated the guidance to:

• be specific about what can be conditionally revealed, as you should not use them to reveal anything more than a simple question
• make it clearer that if the related question is complicated or has more than one part, you should show it on the next page in the process instead
• make it clear you should not show or hide anything that is not a question
• document our findings in the 'Known issues' section

What’s next

If you’ve done any user research involving conditionally revealed questions, particularly with users of assistive technologies, tell us what you’ve learned by adding a comment to this issue.

We’ll keep looking for opportunities to learn more about how conditionally revealed questions can cause problems for users in our own user research as well.

[CharlotteDowns]

We’ve removed an issue about conditional reveals from our accessibility statement

In September 2020, we added a non-compliance issue to our accessibility statement that said:

users are not always notified when conditionally revealed content associated with a radio button or checkbox is expanded or collapsed - this fails WCAG 2.1 success criterion 4.1.2 Name, Role, Value

As part of our plan to fix this issue, we carried out user research to find out if all use of conditional reveals was an accessibility issue (rather than how they’re used). We also asked service teams to share their own findings with us.

Findings from our research

We found no evidence that not meeting the criterion that ‘users are not always notified’ of conditional reveals caused issues. All users we tested with were able to complete the task without issues. Other service teams also shared similar findings with us.

We took these findings to a Lead Auditor at the Digital Accessibility Centre (DAC), who said that a ‘short’ conditional reveal (such as a single input field) is usually fine and that conditional reveals did not automatically fail WCAG 2.1.

As a way to notify users, we proposed adding an aria-expanded attribute to radio buttons, which we’re exploring with the ARIA group. They told us to think about whether this notification is actually useful to users (rather than excessive noise), which suggested to us that this issue might not be as much of a problem as we’d thought.

Problems with ‘long’ conditional reveals

However, we did observe that conditional reveals can abruptly make a page longer, and that can be disorientating for users.

We’ve fixed this as a separate issue by adding guidance that tells service teams to keep conditional reveals simple.

Removing conditional reveals as a non-compliance issue

Finding solutions to meet accessibility requirements of all users is difficult. That’s why WCAG 2.1 is based on principles, not technology and emphasises the need to think about the different ways that people interact with content.

In our research and investigation to do this, we’ve learned that conditional reveals are very widely used in services (and in other applications), so this is clearly an area for us to continue working on. We’ve also learned that they’re not as severe an issue as we’d thought to be considered non-compliant with WCAG requirements.

What’s next

We’ll continue to look for opportunities to test alternative approaches in user research and encourage new approaches from our community.

We’ll also continue the discussion with ARIA to extend aria-expanded to radios.

If you’ve done any user research involving conditionally revealed questions, particularly with users of assistive technologies, tell us what you’ve learned by adding a comment to this issue.

[terrysimpson99]

DAC reported the following to a service I'm working on:

---

Conditionally revealing radios (A) The radio buttons contain conditionally revealed content, but do not advise their state to screen reader users, and are also contained within nested fieldsets, which make it difficult for screen reader users to correctly determine relationships between grouped content.

Screen reader user comments: “When I selected the ‘Yes’ radio button further content appeared on the page. The additional content was situated inside of a fieldset and legend. This fieldset and legend was contained within an overall fieldset and legend. This was initially confusing as it was not clear where the overall fieldset and legend began and ended. It may also be problematic for some screen reading software to identify a fieldset situated inside a fieldset. Placing the date question on the next page will avoid any potential difficulty. The issue occurs with JAWS, NVDA and when swiping in context with VoiceOver. The issue is not applicable to TalkBack as fieldset and legend functionality is not supported, however placing the date on the next page would make this section of the service easier.”

Solution: It is recommended to not nest fieldsets as this makes it difficult for screen reader users to determine where each set of grouped content starts and ends. Additionally, it recommended to follow the pattern indicated in the GOV.UK Design System which suggests that if conditionally revealed content is complicated or has more than one part that it should be shown on the next page in the process instead. In following this approach, it will also address the issue whereby users are not advised of the expanded state of the radio button. Where buttons expand more content onto the page, users that rely on audio feedback to navigate should be notified of the state of elements to ensure that they do not become disoriented. Please refer to GOV.UK Design System Radios component relating to conditionally revealing radios. Please note: this issue is present wherever conditionally revealing content has been structured in this way and will need to be resolved there too.

---

Personally, I regard conditional reveal as a last resort, but not everybody regards them like that. A slack discussion revealed that several of us (who have some familiarity with the guidance) were unclear about exactly what the guidance meant. I have the following suggestions:

• indicate that conditional reveal should be avoided and only used if other choices do not work
• indicate that conditional reveal should only be used for the following components (list TBD) - I think I've seen it used for more than just radios and checkboxes
• indicate that conditional reveal must not reveal a fieldset (a further question is whether this is tolerable if it's the last radio or checkbox)
• make a specific statement about dates in conditional reveal. Some people may understand the mapping between fieldset and dates but others do not. A reveal of a date input after the first radio button is one of the most common uses of conditional reveal and it would be useful to have guidance referring specifically to dates rather than fieldsets that can be quoted to non-technical people.
• Clarify what 'part' means. The current guidance refers to 'parts' and I interpret a date as having three parts (day, month, year) because to me 'part' = 'field' but others suggested a date is one part. Slack discussion currently at https://ukgovernmentdigital.slack.com/archives/C28AJTE07/p1629389616221400 but will expire soon.

[calvin-lau-sig7]

Improved radios and checkboxes in forced colors mode

As part of the GOV.UK Frontend v3.13.1 ‘fix release’, we’ve made some visual improvements to radio and checkbox controls for users in forced colors mode.

Thanks to Adam Liptrot for reporting this issue.

[CharlotteDowns]

We've been discussing the javascript behaviour for the 'none of these' option on the checkbox backlog

[terrysimpson99]

A discussion in Slack invited comments on conditional reveal. I have the following brainstorm ideas:

• What would happen if conditional reveal were deprecated?
• What would happen if conditional reveal were an option with 'on' and 'off' modes for the designer to choose? Conditional reveal 'off' in javascript would then be similar (or identical) to the non-javascript design. Currently a field can be in a radio list but it must also have conditional reveal. Allowing the designer to switch it off would allow users to see all possible interactions on the page without selecting each radio in turn. This make the page stable rather than dynamic and more like a paper interface where what you see is what you get (on that page at least). Typing in the field would select the radio. Error handling would remain the same as it is now.

[sulthan-ahmed]

Hi sorry, this might seem like a really silly question. Can I assume that if I copy the code exactly from the design system it has everything I need for a component from an accessibility point of view? We are updating our radios in the Home Office Forms framework (HOF) and we currently have aria-required and a role attribute for radios. Should I just delete that now?

<div id="country-of-hearing-group" class="govuk-form-group ">
    <fieldset class="govuk-fieldset" role="radiogroup" aria-required="true">
        <legend class="govuk-fieldset__legend">
            <span class="visuallyhidden">What country was the appeal lodged?</span>
            
            
        </legend>
        <div class="govuk-radios" data-module="govuk-radios">
            <div class="govuk-radios__item">
                <input class="govuk-radios__input" type="radio" name="country-of-hearing" id="country-of-hearing-England &amp; Wales" value="England &amp; Wales">
                <label class="govuk-label govuk-radios__label" for="country-of-hearing-England &amp; Wales">
                    England &amp; Wales
                    
                </label>
            </div>
            <div class="govuk-radios__item">
                <input class="govuk-radios__input" type="radio" name="country-of-hearing" id="country-of-hearing-Scotland" value="Scotland">
                <label class="govuk-label govuk-radios__label" for="country-of-hearing-Scotland">
                    Scotland
                    
                </label>
            </div>
            <div class="govuk-radios__item">
                <input class="govuk-radios__input" type="radio" name="country-of-hearing" id="country-of-hearing-Northern Ireland" value="Northern Ireland">
                <label class="govuk-label govuk-radios__label" for="country-of-hearing-Northern Ireland">
                    Northern Ireland
                    
                </label>
            </div>
        </div>
    </fieldset>
</div>