Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Radios #59

Open
govuk-design-system opened this issue Jan 12, 2018 · 23 comments
Open

Radios #59

govuk-design-system opened this issue Jan 12, 2018 · 23 comments

Comments

@govuk-design-system
Copy link
Collaborator

@govuk-design-system govuk-design-system commented Jan 12, 2018

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

@govuk-design-system govuk-design-system created this issue from a note in GOV.UK Design System Community Backlog (In progress) Jan 12, 2018
@govuk-design-system govuk-design-system moved this from In progress to Published in GOV.UK Design System Community Backlog Jan 12, 2018
@lukechaput
Copy link

@lukechaput lukechaput commented Sep 13, 2018

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
Copy link
Contributor

@amyhupe amyhupe commented Oct 15, 2018

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
Copy link
Contributor

@amyhupe amyhupe commented Oct 15, 2018

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

@edwardhorsford
Copy link

@edwardhorsford edwardhorsford commented Jan 23, 2019

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
Copy link
Contributor

@nickcolley nickcolley commented Jan 23, 2019

@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
Copy link

@terrysimpson99 terrysimpson99 commented Apr 9, 2019

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
Copy link
Contributor

@amyhupe amyhupe commented Apr 10, 2019

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
Copy link

@ChazUK ChazUK commented Apr 23, 2019

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

@dashouse
Copy link

@dashouse dashouse commented Apr 23, 2019

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

Screen Shot 2019-04-23 at 13 14 06

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
Copy link

@rinto-cyriac rinto-cyriac commented Aug 2, 2019

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?
List

@edwardhorsford
Copy link

@edwardhorsford edwardhorsford commented Aug 2, 2019

@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
Copy link

@rinto-cyriac rinto-cyriac commented Aug 5, 2019

@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
Copy link

@edwardhorsford edwardhorsford commented Aug 5, 2019

@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
Copy link

@rinto-cyriac rinto-cyriac commented Aug 6, 2019

@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
Copy link

@paulwaitehomeoffice paulwaitehomeoffice commented Sep 6, 2019

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
Copy link
Contributor

@nickcolley nickcolley commented Sep 11, 2019

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
Copy link

@blowfishsoup blowfishsoup commented Oct 3, 2019

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
Copy link

@edwardhorsford edwardhorsford commented Oct 3, 2019

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
Copy link

@blowfishsoup blowfishsoup commented Oct 4, 2019

Screenshot 2019-10-04 at 14 25 34

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
Copy link

@dashouse dashouse commented Oct 4, 2019

@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
Copy link

@billwessel-dfe billwessel-dfe commented Nov 20, 2019

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".
image

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
Copy link

@roseacre roseacre commented Nov 10, 2020

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.

Screen Shot 2020-11-10 at 15 01 16

distanceHtml is a textarea.

image

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
Copy link
Member

@36degrees 36degrees commented Nov 10, 2020

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Linked pull requests

Successfully merging a pull request may close this issue.

None yet