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>

[sulthan-ahmed]

Thanks @natcarey for her answer, posting here so that anyone googling can find the answer

Natalie Carey GDS (https://ukgovernmentdigital.slack.com/archives/C6DMEH5R6/p1646388142705589?thread_ts=1646330431.594429&cid=C6DMEH5R6) Hi Sulthan, You're correct that the full example from the design system should be everything you need. There's a chance that what you've got in your existing code benefits your use-case specifically but unless you know the reason why it's there I'd suggest removing it and going with the standard markup from the design system. If you do find issues with the markup from the design system then please let us know.

[timcooper-DWP]

I have been looking in detail at some accessibility issues. I am using Axe and Voiceover for initial checks. I have a question on radio button conditional reveals. I’ve read up on the aria-expanded / Axe issue https://github.com/alphagov/govuk-frontend/issues/979 so I’m likely to note that and move on (validating with real users). However, in looking at this I noticed a strange behaviour. With 2 radio buttons unselected, Voiceover correctly identifies “1of 2” and “2 of 2”. However, when the conditional reveal is triggered by selecting the second radio button, VoiceOver says: “1 of 1” and “3 of 3” as its choices of radio buttons… I can’t find this mentioned anywhere. To my mind it should still be "2 of 2" shouldn't it? Is this because of the implementation or is it a known behaviour? Is it "acceptable"?

[36degrees]

@timcooper-DWP it sounds like the issue in https://github.com/alphagov/govuk-frontend/issues/2346? Can you have a read and see if it describes what you're seeing?

[timcooper-DWP]

Thanks Oliver. That’s exactly it (and reported so well too).

From testing this, I can see it’s a Chrome + VoiceOver issue so, given the lack of popularity of that combination, it makes sense to move to Safari as suggested.

Many thanks

[JodiB-TPR]

I'm curious to know if the testing that was done on conditional reveals included radios and checkboxes with hint text. The guidance says conditionally revealing stuff is OK as long as it's simple. It reads like the simplicity only refers to the revealed item itself and not the entirety of the radio or checkbox item. By that reasoning, it would seem it's OK to conditionally reveal simple questions in a radio or checkbox item that has hint text. (See screenshot.)

[This was cross-posted to the related Checkboxes feed.]

[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: https://github.com/alphagov/govuk-design-system-backlog/issues/59#issuecomment-905470337

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. https://github.com/alphagov/notifications-admin/pull/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