Radios that conditionally reveal content use aria-expanded which is not a valid aria-attribute for those roles

[NickColley]

Originally raised by @injms on alphagov/govuk-design-system

The aXe accessiblity tool flags two issues when using the conditional reveal radio component. Running aXe on the example page shows the following issues:

---

Elements must only use allowed ARIA attributes

<input class="govuk-radios__input" id="how-contacted-conditional-1" name="how-contacted" type="radio" value="email" aria-controls="conditional-how-contacted-conditional-1" aria-expanded="false">

To solve this violation, you need to:

Fix the following:

• ARIA attribute is not allowed: aria-expanded="false"

---

I think the expected behaviour would be to have no critical issues flagged by aXe - unless this is a false alarm or is found not to have any impact after testing in the empathy lab.

@36degrees:

(For context, this is something that's come up before in alphagov/govuk_elements#455, but we don't currently have it recorded on the Frontend repo)

edit: Split #1591 into a separate issue

[hannalaakso]

Results of my partial investigation:

Error: "Elements must only use allowed ARIA attributes"

Underlying issue

aria-expanded is not allowed on <input> elements, hence the error (although Siteimprove and W3C validator don't flag this).

Alternative approach

Tested W3C's guidance about alternative way of revealing content: "Optionally, each element that serves as a container for panel content has role region and aria-labelledby with a value that refers to the button that controls display of the panel" This made the experience worse for NVDA users as the "collapsed/expanded" was no longer announced on the radio

Code

Notes:

• note that the Voiceover behaviour can be reproduced with VO + Arrow Right (twice)

NVDA / Firefox (worse experience)

Current example reads out:
Email radio button collapsed not checked

My code
Email radio button checked one of three

Jaws 16 / IE11 (no change)

Current example reads out:
how do you want to be contacted email radio button check
To change the selection press up down arrow

My code
tab How do you want to be contacted email radio button check
To change the selection press up down arrow

[NickColley]

I have reviewed this issue, and some related alongside Hanna's findings and done some more investigation and chatted with the accessibility community and the team.

Our current implementation is invalid of the ARIA specification

The definition for aria-expanded states that the attribute can be used on elements with the following roles:

• button
• combobox
• document
• link
• section
• sectionhead
• window

This is why aXe is throwing an error.

Incorrect ARIA attribute usage is not always a Web Content Accessibility Guidelines (WCAG) failure.

While investigating if this usage is against WCAG (4.1.1 parsing: https://www.w3.org/TR/WCAG21/#parsing), I spoke to the accessibility community and Richard (an accessibility specialist at GDS) gave the following response: 'I use the definition literally when checking this “elements have complete start and end tags, elements are nested according to their specifications, elements do not contain duplicate attributes, and any IDs are unique, except where the specifications allow these features.”'

This means that using ARIA in places not allowed in the specification is not a failure.

Only some assistive technologies announce something useful

	JAWS 2018 + IE11	NVDA 2019 + Firefox 60	VoiceOver + Safari 10.13.6	iOS 12.3.1 VoiceOver
Checkboxes	👇tab to first item "How do you want to be contacted, Email, checkbox, unchecked" 👇 press space "Space, checked, collapsed, checked, expanded, How do you want to be contact, use JAWS key + alt + m to move to controlled element"	👇tab to first item "how do you want to be contacted, grouping.email, checkbox, not checked, collapsed" 👇 press space "checked, expanded"	👇tab to first input "Email Email, unchecked, checkbox, How do you want to be contacted?, How do you want to be contacted?, group" 👇 press space "Email, Email, checked, checkbox"	👉swipe to first input "Email, tickbox, unticked, collapsed double tap to toggle setting" 👇double tap "expanded, ticked"
Radios	👇tab to first item "How do you want to be contacted, Email, radio button, not checked" 👇 press space "Email, radio button, use JAWS key + alt + m to move to controlled element"	👇tab to first item "how do you want to be contacted, grouping.email, radio button, not checked, collapsed, 1 of 3" 👇 press space "checked, expanded"	👇tab to first input "Email, collapsed, radio button, 1 of 3, How do you want to be contacted?, How do you want to be contacted?, group" 👇 press space "Email, selected expanded, radio button, 1 of 3"	👉swipe to first input "Email, radio button, unticked, 1 of 3, collapsed double tap to expand" 👇double tap "expanded, ticked"

Google Sheets original testing

Which supports other issues we have raised that show there are issues with VoiceOver and JAWs.

• VoiceOver: Conditionally revealing content with checkboxes not announcing collapsed/expanded state on macOS with VoiceOver #989
• JAWs: Conditional reveals with an input not being announced on JAWS #935

So a large chunk of the assistive technologies we test in support this incorrect aria usage.

Assistive technologies have no incentive to support this pattern

We could consider asking the vendors for JAWs and VoiceOver to fix their behaviour to be consistent with NVDA.

I think that because the aria specification does not allow for this usage these vendors will not prioritise any features.

We could also argue that the fact that there is support in the first place is a coincidence.

The teams maintaining this code will not be checking this use case, this means in the future it could be dropped or mistakenly broken for our users.

Updating the ARIA specification to include radios and checkboxes

We could consider contacting the ARIA working group and proposing to update the specification so it'll allow for our use case.

I think for this to be considered we'd need strong evidence that this pattern is used across the industry, not just government.

I don't think this would be resolved in a short time period.

Next steps to consider

I think based on what we know so far we should explore options that avoid invalid use of ARIA

Remove invalid ARIA attributes

Some in the wider accessibility community have suggested that this pattern may not be inaccessible even without the invalid ARIA attributes.

"The resulting code isn’t necessarily inaccessible, especially given that the input requesting more information (be it e-mail or phone number) is the next one up in the tab order.

I think the invalid ARIA doesn’t add anything in this case and can be removed"

Zoe Bijl

However, we have one piece of feedback that suggests that extra affordance is important.

"There is no immediate audio to let the end user no that an edit field has visually appeared on the screen. I decided to ignore selecting a radio button and activated the continue button"

Conditional reveals with an input not being announced on JAWS

This also is reinforced by the details and accordion component, which have similar user needs, using aria-expanded.

Reconsider the design pattern entirely

We could consider moving away from this pattern and trying something different that avoids the technical issues.

However it's a well used pattern and has been through lots of user research sessions by various teams.

Manage focus when conditional reveals open

One common way of indicating that new content is available to interact with is to manage the users focus.

For example with a sidebar menu, you may move the user's focus over to the menu.

This will not work for a conditional reveal pattern using radios as it will disrupt being able to cycle through the radio group using up and down.

Using aria-live to announce state changes

We could consider using an aria-live announcer pattern, to announce expanded states based. Similar to what we do on the accessible-autocomplete.

You can the result of trying this in further comments in this thread.

Using visually hidden text to indicate state changes

We could consider adding visually hidden text that serves a similar purpose to the aria-expanded announcements, for example appending 'collapsed' to the main label, then changing it to 'expanded' when it's open.

You can the result of trying this in further comments in this thread.

[NickColley]

I have created two spikes to test:

• Using aria-live to announce state changes
  
• Using visually hidden text to indicate state changes

I've recorded the conclusions here: https://docs.google.com/spreadsheets/d/1i1yFXuv-mvvDpi36gd9ZFjRiaUM7m-1WppIZYnYbUts/edit?usp=sharing

The summary is that:

• aria-live cannot give the initial state of components, so is ruled out
• visually hidden text can give consistent initial state, but does not always work to announce the change of state. This is because some assistive technologies just say something like 'ticked' and do not reannounce the label.

Perhaps a more descriptive message could be given to elements instead of 'Expanded', for example 'Interacting with this input opens a new section', we could consider aria-describedby for this. I have worries this would be very noisey and annoying.

I'll discuss this all with the team.

[NickColley]

The Design System team met and discussed these findings.

This pattern has been through a lot of user research by different service teams and we have not had any feedback to suggest that this is not working for real users of assistive technologies.

We will ask the community for more research with real users of assistive technologies to understand if there are any barriers.

We know that users of the screen reader JAWs and VoiceOver on Mac (Checkboxes only) are not helped by aria-expanded, so based on the feedback we get from the community we can try to understand if removing these attributes entirely will cause barriers.

This means we will:

• not remove these aria attributes, pending more feedback from user research
• document this as a known issue
• consider approaching the ARIA working group to suggest broadening the scope of aria-expanded.

[abbott567]

@stesh-nhsbsa March 2021 is the estimate I'm working to based on the Design System's own accessibility statement: https://design-system.service.gov.uk/accessibility/

[guyhickling]

Aria-expanded on checkboxes is already in the draft for ARIA 1.2. And @36degrees has started a conversation at W3C to do likewise for radio buttons - and I have just added my support for that proposal as well to hopefully help move it along a bit. If all goes well we'll see it added in before release.

However, it will take a year or two for all mainstream assistive devices to catch up, even though some of them already do it. So, for the time being, I would suggest using a very brief text for screen readers of "Reveals content", added either using aria-describedby on the radio button, or as screen reader text appended, with a comma, in the radio button's element. Just two words like that should be enough - you don't want to make it too verbose or, as mentioned above, it will annoy the users!

[36degrees]

In March 2021, we spoke to a Lead Auditor at the Digital Accessibility Centre who works alongside screen reader testers and users with disabilities. They audit a lot of government services, especially HMRC services. As such, they're pretty familiar with the current approach to conditional reveals.

They mentioned that they’d known about the invalid use of aria-expanded for a while, but not really flagged it as it’s normally read by screen readers (at least the versions of JAWS and NVDA they test with, would have to check Voiceover).

[CharlotteDowns]

We’re leaving this issue open whilst we wait for the proposal to ARIA to be resolved. It’s part of a future ARIA 1.3 milestone so it may take some time before being looked at.

For now, we’ll keep using the aria-expanded attribute for radios as we still think it’s useful to users.

If ARIA reject our proposal, we’ll stop using aria-expanded for radios and decide whether we need to stop using it for checkboxes for consistency.

[domoscargin]

Update: the ARIA proposal milestone has been moved to ARIA 1.4: w3c/aria#1404 (comment)

[querkmachine]

To confirm: Using aria-expanded on checkboxes has been allowed since ARIA 1.2, however the Axe auditing tool has not yet been updated for this change and will still flag it as a failure, which I've tried chasing up on.

As this issue is now only relevant to radio buttons, I'm going to rename it to reflect that change.