The expanded/collapsed state of conditional reveals is not available to all assistive technologies

What

As part of an internal accessibility audit of GOV.UK, conditional reveals† was flagged as failing WCAG 4.1.2:

4.1.2 Name, Role, Value: For all user interface components (including but not limited to: form elements, links and components generated by scripts), 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. (Level A)

It was flagged as failing because:

• the additional ‘role’ of the checkbox or radio button is not clear
• changes to the expanded ‘state’ of the radio buttons is not available to assistive tech, and so users may be unaware that something else has changed on the page as a result of selecting a radio.

We use aria-expanded on these controls, but that is technically invalid according to the spec, which only allows aria-expanded on certain roles. Some screen readers still announce the expanded state, but those that don’t have no reason to implement it because it’s against the spec. ARIA 1.2 (which is currently in draft) extends support of aria-expanded to checkboxes but not radios.

The fact that aria-expanded is not valid is recorded as a separate but related issue (https://github.com/alphagov/govuk-frontend/issues/979).

As of September 2019, this is known to affect:

• Voiceover (https://github.com/alphagov/govuk-frontend/issues/989)
• JAWS (https://github.com/alphagov/govuk-frontend/issues/935)

Update

As of June 2021, we removed conditional reveals from our accessibility statement.

---

† The page being audited uses the conditional reveals in an unusual way, as what’s being revealed is effectively contextual help (like a hint) that would help the user to make the right choice. Whereas the way we intend the component to be used is to reveal additional form controls that ‘follow on’ from the initial question. We think that revealing text in this way is ‘worse’ in terms of accessibility, so we have a separate issue to discourage users from using conditional reveals to reveal text (https://github.com/alphagov/govuk-design-system/issues/1362)

[36degrees]

Thanks @paulwaitehomeoffice – that’s really helpful. Out of interest, did you try a variation with an explicit role of radiogroup on the fieldset? I believe the default role for fieldset is just group.

Either way, it’s interesting to note that the current draft of ARIA 1.2 removes support for aria-expanded on a radiogroup. It looks like this was done in https://github.com/w3c/aria/pull/972, which ‘[revises] aria-expanded definition to state it aria-expanded belongs on interactive, focusable, controlling element’ – which again suggests to me the attribute should be added to the control rather than the group (ignoring the fact that this is still technically invalid).

I think there’s a possibility that we’re going to end up raising an issue against the ARIA spec making the case for extending aria-expanded support to radios as they have in checkboxes. Would you be happy for us to include your research as part of that issue, with a credit?

[CharlotteDowns]

We’ve removed ‘(WCAG 2.1 4.1.2 Name, Role, Value)’ from this issue as part of removing conditional reveals from our accessibility statement.