Open 36degrees opened 3 years ago
carmacleod
commented
3 years ago From the minutes of the call where this was discussed, it seems that the only relevant disagreement for not allowing expanded on radios was:
sina: I've seen this pattern a lot, too. It can add noise. ... the reveal example is understandable. But if you're arrowing it will be always expanded and you will never hear collapse. [could use] virtual cursor but is not enough
mcking: makes sense!
carmacleod
commented
3 years ago @sinabahram @mcking65 Agreed that if all radios in a group have extra content, then hearing "expanded" on every radio just increases verbosity for very little semantic gain. (The slight gain being a hint that "you have to fill in the extra stuff before your selected radio counts").
However, do you think aria-expanded on radio could potentially be useful if there was only 1 radio with expanded content, particularly if it was the last one? And by extension, if only some - but not all - of the radios had expandable content, would hearing "expanded" on the radios that had extra content be useful?
@MelSumner Reminder to please add a comment describing the UI that you usually recommend for this type of thing. Thanks!
@stes-acc You mentioned that this is used all the time in business applications. Do they use aria-expanded on radios, and if so, can you please link to an example? You also said something about Ctrl+Space (or Ctrl+Arrow?) toggling a radio, but I tried it in Windows Chrome/FF and it doesn't work, so I'm wondering if you have an example of that also?
@36degrees
You have definitely shown that "conditional reveals" (aka "progressive disclosures") are used all over the place! 😄
I didn't see any (non gov.uk) radio examples that were using aria-expanded, though.
The confusion resulting from P1's experience with the radios makes me wonder if "No" should have come before "Yes" so that the expanded content was only on the last radio in the group... but even then it's still not clear whether aria-expanded would be helpful or not.
P5 found the announcement of the expanded state helpful, but they were referring to aria-expanded on a checkbox, and checkbox supports aria-expanded.
So, since we're trying to determine whether or not radio should support aria-expanded, would you be able to do another user study that focuses only on radios? Maybe with several different use cases:
In each case:
aria-expanded="true" ("false" when collapsed, but that's only perceivable with virtual cursors).It might even be interesting to have duplicate use cases that don't use aria-expanded, so that we can compare whether or not it is helpful.
36degrees
commented
3 years ago From the minutes of the call where this was discussed, it seems that the only relevant disagreement for not allowing expanded on radios was:
sina: I've seen this pattern a lot, too. It can add noise. ... the reveal example is understandable. But if you're arrowing it will be always expanded and you will never hear collapse. [could use] virtual cursor but is not enough mcking: makes sense!
@carmacleod this is all really helpful context – thanks.
I guess I would assume that a screen reader user would be able to infer that a previously expanded section would collapse when the radio selection changed, based on their mental model of how radios work? In the same way that e.g. a screen reader will not announce the ‘unchecked’ state of a previous radio when the selection is changed.
I think this also focuses on the usefulness of the state change (the user knowing that the controlled element is now revealed) rather than the relationship (the user knowing that when they check the radio, it will reveal something else). The relationship feels like it’s the more important aspect in terms of understanding how the page is structured and it being predictable.
@36degrees You have definitely shown that "conditional reveals" (aka "progressive disclosures") are used all over the place! 😄 I didn't see any (non gov.uk) radio examples that were using
aria-expanded, though.
I think we may have been approaching this from a slightly different angle. There are, I think, 3 statements that need to be considered true for this proposal to be successful:
aria-expanded is the most appropriate way to do thisI think we’ve focused mostly on points 1 and 3. We have been taking point 2 as a ‘given’, as without it we think the pattern fails WCAG 2.1, specifically 4.1.2 Name, Role, Value:
For all user interface components, the name and role can be programmatically determined; states, properties, and values that can be set by the user can be programmatically set; and notification of changes to these items is available to user agents, including assistive technologies.
We think it fails because:
We’ve also been looking at it through the lens of 3.2.2: Predictable On Input:
Changing the setting of any user interface component does not automatically cause a change of context unless the user has been advised of the behavior before using the component.
We don’t think it fails 3.2.2, because we don’t think that revealing additional content counts as a change in context. However, our hypothesis is that the use of aria-expanded makes the interface more predictable, and therefore more understandable.
The confusion resulting from P1's experience with the radios makes me wonder if "No" should have come before "Yes" so that the expanded content was only on the last radio in the group... but even then it's still not clear whether
aria-expandedwould be helpful or not.
Yep, this is one of the things we’re considering. We intentionally included a more complex example in the prototype as we wanted to see where the problems occurred.
P5 found the announcement of the expanded state helpful, but they were referring to
aria-expandedon a checkbox, and checkbox supportsaria-expanded.
P5 encountered the conditional reveal on radios earlier in the prototype journey. They were using Chrome (with NVDA), and so the expanded state was not announced. However, they completed that part of the journey without any issues.
I guess there is an assumption here that because P5 found the expanded state helpful on checkboxes they would also have found them useful on radios, if their browser had supported it.
The interactions seem so similar that I imagine the inconsistency of exposing the expanded state on one but not the other could cause confusion.
For example, if P5 had encountered the example with checkboxes first, when they reached the radios it seems reasonable they’d assume that the radio did not reveal additional content, because they’ve now learned that controls that reveal additional content have that expanded state.
Aside from the issue raised by @sinabahram, are there other differences between radios and checkboxes that explain why aria-expanded would be appropriate on one but not the other?
So, since we're trying to determine whether or not radio should support
aria-expanded, would you be able to do another user study that focuses only on radios? Maybe with several different use cases:
- only the last radio in the group has expandable content
- all radios in the group have expandable content
- some (but not all) of the radios in the group have expandable content
In each case:
- the expanded content immediately follows its "controlling radio" in the DOM order
- radios with expanded content have
aria-expanded="true"("false" when collapsed, but that's only perceivable with virtual cursors).It might even be interesting to have duplicate use cases that don't use
aria-expanded, so that we can compare whether or not it is helpful.
We don’t have the resources to do research specifically for this, but it’s definitely something we can look out for in our next round of research.
It might be tricky to get anything conclusive out of it – it feels like we got lucky with P5 calling out the expanded state in the way that they did. We can definitely look at asking more questions to check the users’ understanding of what’s going on on the page.
carmacleod
commented
3 years ago Aside from the issue raised by @sinabahram, are there other differences between radios and checkboxes that explain why aria-expanded would be appropriate on one but not the other?
Yes, the main difference is that radios cannot separate focus from selection. (Not including a possible, but not recommended, default state where no radios are selected, which only lasts until a selection is made).
With checkboxes, the user can focus and then decide whether or not to select.
guyhickling
commented
3 years ago I would like to second the original proposal in this thread - that aria-expanded should be allowed in ARIA 1.2 on radio buttons, not just checkboxes.
Radio buttons revealing further content is quite a commonly used pattern in websites that I audit, though not as frequent as checkboxes doing it. I can mention a few instances.
It is often used, for instance, when the last radio button in a set is labelled "Other". When it is clicked it reveals a label and text input field for the user to type in more details about their "Other" choice. I have just finished auditing a new component library for a Norwegian company that creates online surveys, and they intend to use this pattern frequently. Unfortunately I would have liked to recommend aria-expanded but couldn't due to lack of accessibility support (not to mention not supported by ARIA 1.2!)
In other uses, clicking the radio button may reveal several paragraphs of content, sometimes again with another input field or control to complete as well. I have also seen it where clicking each radio button in a parent set reveals a subsidiary set of radio buttons, but a different set as appropriate to whichever parent radio button was clicked.
A couple of weeks back I came across an even more extreme use of this concept. A UK government agency website I was auditing revealed a popup modal dialog when certain radio buttons in a set were selected. (So not a case for aria-expanded, more one for aria-haspopup="dialog", if any screen reader actually supported that, which they don't of course). A little bit over the top, you might think, but the case was that for those radio button choices the user then had to complete a declaration form to confirm they understood certain legal points. My client obviously felt putting the user in a modal dialog would force them to consider the confirmation more effectively than just revealing it as drop-down content. But an interesting further extension of this concept of radio button revealing more content!
In short, radio buttons revealing content is a common pattern, and I think blind screen reader users would find aria-expanded for that use case just as useful as using it on checkboxes or anywhere else.
pkra
commented
2 years ago From https://github.com/w3c/aria/issues/1714#issuecomment-1151443356
@spectranaut wrote:
We discussed this issue again in ARIA 1.3 triage, you can see the discussion at the very end of the minutes here: https://www.w3.org/2022/06/09-aria-minutes.html
Though there was some debate, @mcking65 still feels "aria-expanded" is unnecessary and in most cases provides to much information. Providing too much information to screen reader users decreases the usability of a page. Would need to see more user research with screen reader users before we make this change.
For now we are moving the milestone to 1.4 in case more information comes up!
MarcoZehe
commented
2 years ago As a long-time screen reader user, I have encountered the pattern that checking a radio button causes more fields to be revealed, probably hundreds of times. I always found that, in the context of the application I was in, the fact that a particular radio button was checked, along with its label, was enough information for me to expect more fields to be available, ideally in the vicinity of the radio button itself, or at least, following the tab order from the group of radio buttons onwards. Also hearing the screen reader announce some expanded state would, for me, always be superfluous information. Like "Yes, dear application, I checked that I want to be contacted via email, and you haven't asked me my email address yet, so I expect you to do it now that I have checked that radio button".
Personally, I would normally feel similarly about checkboxes, too, with the "checked" state usually being enough for me, and derived from the context, to expect more fields to be revealed depending on whether the checkbox is checked or not. In fact I remember that, the first time I actually encountered such a checkbox that also conveyed some expanded state, I was confused why I was getting double information. But I guess for checkboxes, that ship has sailed, and that's, for reasons others have already stated, more okay for me than the radio button case.
alanfluff
commented
2 years ago I would like to second the original proposal in this thread - that aria-expanded should be allowed in ARIA 1.2 on radio buttons, not just checkboxes.
Ditto. I have just used this pattern and it seems too useful to not progress.
dav-idc
commented
1 year ago Hi @cookiecrook, @stevefaulkner or anyone else actively contributing to this repo!
If this issue has been bumped to the ARIA 1.4 milestone, does that mean this likely won't be addressed for another couple of years? It appears that ARIA 1.3 is still in its early stages.
Thanks!
spectranaut
commented
1 year ago Hi @davidc-gds, 1.3 is mostly "complete", we only have some editorial tasks remaining. The implementation in browsers follows consensus from the working group, so the publication date is the not the same as the browser support date for new features.
But also, in this thread, two different screen reader users have said this information would be redundant for them!
We would need to see user research that includes screen reader users feedback to move forward with this proposal.
rostero1
commented
1 year ago The motivation for this ticket is revealing additional form fields. If this is applied to radio elements, then wouldn't it also be logical to apply this to select components (which would be confusing in itself and for custom components of the combobox role that needs to update aria-expanded when its listbox is open)? Personally, when I'm revealing more content, it's because of a custom select component and not a radio group (which isn't to say this isn't useful).
stephenjmcneill1971
commented
11 months ago 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.
scottaohara
commented
11 months ago It’s unclear what your issue is because you didn’t provide any code or an example to reference.
if your issue is directly related to the topic of this issue then you may be experiencing a gap due to using the attribute in a way that isn’t officially spec’d
if your issue is indirectly related to this issue, and what you’re experiencing is a browser bug, then this unfortunately isn’t the forum for such questions
This issue follows on from a previous discussion in #1277.
The current working draft of ARIA 1.2 extends support for
aria-expandedto the checkbox role, but not the radio role. We'd like to propose that it should be extended to the radio role as well.Overview
The radio and checkbox components in the GOV.UK Design System both support conditionally revealing additional controls, for example a text input, based on the checked state of a radio or checkbox.
For example, take the question "How do you want to be contacted?" If a user selects Email, you can ask for their email address.
As noted in the ARIA documentation for
aria-expanded, 'simplifying the user interface by collapsing sections may improve usability for all, including those with cognitive or developmental disabilities.'We use
aria-expandedas part of the implementation for both radio buttons and checkboxes. This is because, despite being invalid according to ARIA 1.0, it still has good support in current assistive technologies (as documented below). We also believe that it improves the experience for screen reader users because it:Current support for
aria-expandedon radios and checkboxesTo find out what support currently exists for
aria-expanded, we tested different combinations of assistive technologies and browsers.Almost all of the combinations either partly or fully supported
aria-expandedon checkboxes. The only exception was Voiceover / Safari on macOS.Currently, there is less overall support for
aria-expandedon radios. However, all of the combinations that do not support it involve Chrome. As far as we can tell, this is because Chrome strictly exposes the expanded state only when it's valid for the role, based on ARIA 1.2.So, if ARIA was updated to allow
aria-expandedon radios, and Chrome was then updated accordingly, we'd expect to see support foraria-expandedon radios to be as good as, or better than, on checkboxes.Note: None of us are day-to-day screen reader users. On desktop, testing involved navigating to the radio / checkbox control using the tab key. On mobile, testing involved swiping through the elements on the screen to reach the control. Please let me know if there are other methods of navigation we need to consider.
Overview
Show full testing output
### Checkboxes | Behaviour | Announces collapsed state on focus | Announces expanded state on focus | Announces expanded state when checked | |-------------------------------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|---------------------------------------------------------------------------------------------------------------------| | Voiceover / Safari (macOS Catalina) | ❌"Email, unticked, tickbox, How would you like to be contacted? How would you like to be contacted? Group. Select all options that are relevant to you. You are currently on a tickbox. To select or deselect the tickbox, press Control-Option-Space" | ❌
"Email, unticked, tickbox, How would you like to be contacted? Select all options that are relevant to you. You are currently on a tickbox. To select or deselect the tickbox, press Control-Option-Space" | ❌
"Email, ticked, tickbox" | | NVDA 2020.3 / Firefox 81 | ✅
Email check box not checked collapsed | ✅
Email check box checked expanded | ✅
"checked expanded" | | JAWS 2020 / IE 11 | ❌
"Email checkbox not checked. To check press spacebar." | ❌
"Email checkbox checked. To clear checkmark press spacebar." | ⚠️
"Space, checked collapsed, checked expanded, Email checkbox checked. To clear checkmark press spacebar." | | JAWS 2020 / Chrome | ❌
"Email checkbox not checked. To check press spacebar." | ❌
"Email checkbox checked. To clear checkmark press spacebar." | ✅
Space, checked expanded | | NVDA 2020.3 / Chrome 86 | ✅
Clickable Email check box not checked collapsed | ✅
Email check box checked expanded | ✅
"checked expanded" | | Talkback / Chrome 71 (Android 7.0) | ❌
Not ticked, email, tickbox. Double tap to toggle. | ❌
Ticked, email, tickbox. Double tap to toggle. | ❌
Ticked | | Talkback / Chrome 86 (Android 10) | ✅
Collapsed, not checked, email, tickbox. | ✅
Expanded, checked, email, tickbox. | ❌
Checked | | Voiceover / Safari (iOS 14) | ✅
Email, tickbox, unticked, collapsed. Select all options that are relevant to you. Double tap to toggle setting. | ✅
Email, tickbox, ticked, expanded. Select all options that are relevant to you. Double tap to toggle setting. | ✅
Expanded, ticked | ### Radios | Behaviour | Announces collapsed state on focus | Announces expanded state on focus | Announces expanded state when checked | Announces expanded state when changed | |-------------------------------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|------------------------------------------------------------------------------------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | Voiceover / Safari (macOS Catalina) | ✅
"Email, collapsed, radio button, 1 of 3, How would you prefer to be contacted? How would you prefer to be contacted?, group. Select one option. You are currently on a radio button, 1 of 3. To select this option, press Control-Option-Space" | ✅
"Email, selected expanded, radio button, 1 of 3, How would you prefer to be contacted? How would you prefer to be contacted?, group. Select one option. You are currently on a radio button, 1 of 3. To select this option, press Control-Option-Space" | ✅
"Email, selected expanded, radio button, 1 of 3" | ✅
Moving focus moves selection:
"Phone, selected expanded, radio button, 2 of 3. Select one option. You are currently on a radio button, 2 of 3. To select this option, press Control-Option-Space" | | NVDA 2020.3 / Firefox 81 | ✅
Email radio button not checked collapsed 1 of 3 | ✅
Email radio button checked expanded 1 of 3 | ✅
space checked expanded | ✅❓
"collapsed phone radio button checked expanded 2 of 3" | | JAWS 2020 / IE 11 | ✅
Email radio button not checked collapsed | ✅
Email radio button checked expanded | ✅
Space, email radio button checked expanded, email radio button checked expanded | ❌
"Phone, radio button checked, to change the selection press up or down arrow" | | JAWS 2020 / Chrome | ❌
Email radio button not checked 1 of 3 | ❌
Email radio button checked 1 of 3 | ❌
Space, email radio button checked, 1 of 3 | ❌
"Phone, radio button checked, 2 of 3" | | NVDA 2020.3 / Chrome 86 | ❌
Email radio button not checked 1 of 3 | ❌
Email radio button checked 1 of 3 | ❌
space checked | ❌
Phone radio button checked 2 of 3 | | Talkback / Chrome 71 (Android 7.0) | ❌
Not ticked, email, radio button. Double tap to toggle. | ❌
Ticked, phone, radio button. Double tap to toggle. | ❌
Ticked. | ❌
Not ticked, phone, radio button. Double tap to toggle. | | Talkback / Chrome 86 (Android 10) | ❌
Not selected, email, radio button | ❌
Selected, email, radio button | ❌
Selected. | ❌
Not selected, phone, radio button. | | Voiceover / Safari (iOS 14) | ✅
Email, radio button, unticked, 1 of 3, collapsed. Select one option. Double tap to expand. | ⚠️
Email, radio button, ticked, 1 of 3, expanded. Select one option. Double tap to collapse. | ✅
Expanded, ticked | ✅
On focus:
Phone, radio button, unticked, 2 of 3, collapsed. Select one option. Double tap to expand.
On selection:
Expanded, ticked |
Key
✅ Supports
aria-expanded– the expanded state is announced when focusing the radio / checkbox control, and is also announced when the control is checked or unchecked and the expanded state changes.❎ Partial support for
aria-expanded– the expanded state is announced when focusing the radio / checkbox control, or announced when the control is checked or unchecked and the expanded state changes, but not both.❌ No support for
aria-expanded– the expanded state is never announced.Notes
[1] Possibly confusing announcement when you change which radio button is selected:
[2] Announces expanded state on selection, but not on focus. Makes a contradictory announcement when doing so:
[3] Announces expanded state on selection, but not on focus.
[4] Announces expanded state on focus, but not on selection.
[5] Makes a confusing announcement when announcing the expanded state on a radio:
You cannot de-select a radio button, so double tapping does not collapse the reveal.
Understanding of the expanded attribute on a radio or checkbox
When users encounter the 'expanded' or 'collapsed' state on a radio or checkbox, we need to be confident that they will understand what it means.
GOV.UK has used conditional reveals, including the use of
aria-expanded, since at least November 2014. At that time, we added them to our previous frontend framework, GOV.UK Elements.GOV.UK service teams are required to make sure everyone can use the service. This should include carrying out research with participants who represent the service's potential audience, including people with access needs.
We are only aware of a handful of issues relating to conditional reveals since November 2014. The issues that have come up are usually about the revealed fields' position in the tab order, rather than the use of
aria-expanded.However, we know that service teams will be focusing on the broader service-interactions and may not spot issues with conditional reveals. So, in December 2020, we carried out a round of user research with a focus on conditional reveals.
Findings from user research around conditional reveals
We tested a prototype of a GOV.UK service with 8 participants, 3 of whom used screen readers:
We included 2 different examples of conditional reveals as part of the journey that all participants completed.
Conditional reveal #1 used radios and included multiple revealed fields, as we know that designers are using conditional reveals to reveal increasingly complex additional content.
Conditional reveal #2 used checkboxes, with each checkbox revealing a single field.
P1 was disorientated by the position of the revealed fields between the two radio buttons. However, they were still able to complete the task. We are looking at the position of the revealed fields as a separate but related issue.
P5 called out the announcement of the expanded state and found it helpful:
Further context on conditional reveals
Previous related discussions:
Examples of similar interactions outside of GOV.UK
GitHub
When committing changes to a file, selecting the ‘Create a new branch for this commit…’ radio button reveals a text input for the branch name
WordPress
For ‘Your homepage displays’, choosing ‘A static page’ reveals additional select menus to choose which page should be used.
For ‘Primary color’, selecting ‘Primary color’ reveals a color picker control
Barclays Bank
Checking the radios for ‘Current/savings account’ and ‘Mortgage account’ toggles the visibility of associated form fields. (Register for Online Banking > Start > scroll to Account details)
Royal Bank of Scotland
‘Customer number’ and ‘Card number’ toggle the visibility of single form fields. (Log in)
Each radio toggles the visibility of a large number of associated form fields. (Set up digital banking)
Chrome
In Chrome preferences, for ‘On start-up’ selecting ‘Open a specific page or set of pages’ reveals additional controls to specify which pages should open on start up.
macOS display preferences pane
Selecting a ‘Scaled’ resolution reveals additional controls to allow the user to choose how the display should be scaled – to optimise for larger text or for more space.
In other design systems
Thanks to the rest of the GOV.UK Design System team, especially @EoinShaughnessy, for all of their work on this and for their help writing this issue up.