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

[36degrees]

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 (#979).

As of September 2019, this is known to affect:

• 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)

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 (alphagov/govuk-design-system#1362)

[36degrees]

Next steps:

• Test conditional reveals with the updated combinations of assistive technologies and browsers in the service manual, to get up to date data.
• Explore whether the ARIA spec could allow aria-expanded on radios

[36degrees]

The CMS Design System (for healthcare.gov) uses aria-live="polite" aria-relevant="additions text" aria-atomic="false" on a wrapper around the radio/checkbox and its revealed content:

<div aria-live="polite" aria-relevant="additions text" aria-atomic="false">
	<input class="ds-c-choice" id="checkbox_checkbox_choice_2" name="checkbox_choice" type="checkbox" value="b" checked="">
	<label class="ds-c-label" for="checkbox_checkbox_choice_2">
		<span class="">Checkbox B with checked children</span>
	</label>
	<div class="ds-c-choice__checkedChild">
		<div class="ds-u-clearfix">
			<label class="ds-c-label ds-u-margin-top--0" for="textfield_3" id="textfield_label_4">
				<span class="">Child field</span>
			</label>
			<input class="ds-c-field" id="textfield_3" type="text" name="textfield_child">
		</div>
	</div>
</div>

https://design.cms.gov/components/choice/

[36degrees]

GitHub's Primer uses aria-live on the label for the radio button, and nests the conditionally revealed control within the radio's label:

<form>
  <div class="form-checkbox">
    <label>
      <input type="radio" name="hireme" />
      Not available for hire
    </label>
  </div>
  <div class="form-checkbox">
    <label aria-live="polite">
      <input type="radio" class="form-checkbox-details-trigger" name="hireme" />
      Available for hire
      <span class="form-checkbox-details text-normal">
        <span class="d-block mb-1">Available hours per week</span>
        <input type="text" name="" class="form-control input-contrast" size="3" />
        <span class="text-small text-gray pl-2">hours per week</span>
      </span>
    </label>
  </div>
</form>

(Not sure how this affects the labelling of the revealed field?)

https://primer.style/css/components/forms#show--hide-content-based-on-a-checkbox-or-radio-button-state

[36degrees]

Note that we previously 'ruled out' using aria-live in #979 (comment).

It might be worth trying to think about making the role of the radio button clear and notifying when the visibility of the reveal changes as two separate problems?

[paulwaitehomeoffice]

I've been doing some investigation into this issue, specifically on radio buttons.

The ARIA Spec

The ARIA spec currently allows aria-expanded and aria-controls attributes on elements with the role radiogroup (i.e. fieldsets), but not on individual radio buttons (as noted above). I think you can see the thinking behind this: individual radio buttons are treated like <option> elements inside a <select>; they're not individual controls themselves, they're values for their parent radio group.

As such, if the conditional reveal (for radio buttons) were changed to match the ARIA spec, the aria-expanded and aria-controls attributes would be on the parent fieldset, and not on individual radio buttons that cause the content to be revealed.

In theory, screen readers would still have all the information they need to announce expanding and collapsing content whenever they think they should, and so I think it's arguable that this would meet the requirements of WCAG 2.1.

What screen readers do

However, obviously we're also interested in what screen readers actually announce, and possibly whether we can do stuff in code to help them behave in ways that we think are more useful.

I've created some variations on the conditional reveal, and tested them in Voiceover on iOS (13.7), macOS (Mojave 10.14.6), and NDVA (2019.3.1, Windows 10). (I don't currently have access to JAWS, but I can install it and test later.)

I've recorded videos for:

• A. the original conditional reveal from the Design System
• B. ARIA attributes only on the fieldset (as per my understanding of the ARIA spec)
• D. ARIA attributes on the fieldset, and all the radio buttons inside it (not just the radio buttons that expand the content)

(Big disclaimer: I don't routinely use screen readers myself, so I could easily be missing obvious interactions to test.)

• https://paulwaitehomeoffice.github.io/conditionally-revealing-radios-aria-experiments/

There are 5 different actions I've found that make some or all screen readers announce information about expanded or collapsed content. I've tried to make sure the videos cover all of these actions (although some might be less useful for actual screen reader users than others):

1. Expand the content
2. Collapse the content
3. Focus a radio button that expands the content
4. Focus a radio button that collapses the content
5. Focus a fieldset

In Voiceover on macOS and NVDA, I've recorded separate videos for navigating the page with the tab key, and with the "web rotor" (i.e. navigating the page using the screen reader's own keyboard commands).

So... what do screen readers do?

I've attempted to summarise the results in tables, but in short, in the screen readers tested:

• Variation A triggers announcements when content is expanded, but not when it is collapsed (except when using the tab key in NVDA), or when radio buttons that collapse the content are focused.
• Variation B never triggers announcements when content expands or collapses, and usually doesn't when radio buttons that expand or collapse the content are focused/
• Variation D always triggers announcements when content expands and collapses, and when radio buttons that expand or collapse the content are focused. However, it also triggers double announcements in some screen readers, and it creates more instances of bug in iOS Voiceover bug where it will give the user incorrect instructions about how to expand or collapse content

I'm sorry for the wall of text, but hopefully this shows some of the possibilites and pitfalls. Please do point out any mistakes or omissions, I'm sure I've made a few.

[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 w3c/aria#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?

[paulwaitehomeoffice]

@36degrees Aha! I did not try radiogroup on the fieldset; I assumed fieldset had a role of radiogroup. (Now that I think about it, I can see how it might not, unless browsers were being really clever about looking at the controls it contained.)

I also did not think to check the current draft of the spec. Looking at how, for example, iOS behaves, it's probably sensible of them to limit aria-expanded to actual UI widgets that the user can do something with, as current ARIA implementations seem to assume that's where it will be used. I think it makes sense for radio buttons to be able to use aria-expanded and aria-controls like other widgets can.

Please do feel free to use anything I've posted, however you like, if it's helpful.

[edwardhorsford]

Note that we previously 'ruled out' using aria-live in #979 (comment).

It might be worth trying to think about making the role of the radio button clear and notifying when the visibility of the reveal changes as two separate problems?

Reading through the reasoning for discounting aria-live, it almost sounds like a workable solution might be possible if it were combined with hidden text.

@tvararu I have a hunch you played about with aria-live for the autocomplete and may have come across some of these issues - did you find any solutions?

[36degrees]

Looking at the behaviour of the two examples from CMS Design System and GitHub primer, both of which use aria-live, the addition of aria-live just means that the label of the revealed field is read out.

For example, checking the 'Email' checkbox in the example from the Design System, Voiceover reads out:

"Email, ticked, tickbox. Email address"

I am not sure that this is really that helpful (and may actually cause more confusion than not doing anything), but it might be worth testing.

We could definitely explore providing screen-reader only content that describes the change. However, we'd need to think carefully about how this as it would need localising and potentially customising depending on what exactly is being conditionally revealed.

[36degrees]

I was looking at splitting this issue into two, as it can sort of be thought of as two problems:

• the user being able to predict that checking a checkbox / radio reveals something else on the page
• the user being notified when they have clicked a checkbox / radio that something else on the page has been revealed

However, the issues ended up having mostly the same content with some minor differences. So I'm keeping this as one issue, but it does seem useful to be able to differentiate between those two 'aspects' of this problem.

[36degrees]

Testing with the list of assistive technology / browser combinations in the service manual (plus NVDA / Chrome and JAWS / IE as the next most popular desktop screen reader combinations according to the most recent WebAIM screen reader survey) the only combination that doesn't do anything with aria-expanded is Talkback (Android 7.0 – TODO: Test with a newer version of Talkback) every combination tested supported some aspect of aria-expanded on radios or checkboxes, but only NVDA / Firefox and Voiceover / Safari (iOS) seem to provide decent support for aria-expanded on both checkboxes and radios.

Assistive technology / browser combination	Checkboxes	Radios
JAWS 2020 / Chrome	⭕️  [1]	❌
NVDA 2020.3 / Firefox 81	✅	✅  [2]
NVDA 2020.3 / Chrome 86	✅	❌
JAWS 2020 / IE 11	⭕️  [3]	✅
Voiceover / Safari (macOS Catalina)	❌	✅
Voiceover / Safari (iOS 14)	✅	✅  [4]
Talkback / Chrome 86 (Android 10) [5]	⭕️  [6]	❌
Valid in ARIA specification
ARIA 1.1	❌	❌
ARIA 1.2 (Working Draft 18 Dec 2019)	✅	❌

✅   Supports aria-expanded
⭕️   Partial support for aria-expanded
❌   No support for aria-expanded

[1] Announces collapsed state on selection, but not on focus.
[2] Possibly confusing announcement when you change which radio button is selected:

"collapsed phone radio button checked expanded 2 of 3"

[3] Announces collapsed state on selection, but not on focus. Makes a contradictory announcement when doing so:

"Space, checked collapsed, checked expanded, Email checkbox checked. To clear checkmark press spacebar."

[4] Makes a confusing announcement when announcing the expanded state on a radio:

"Email, radio button, ticked, 1 of 3, expanded. Select one option. Double tap to collapse."

(You cannot de-select a radio button, so double tapping does not collapse the reveal)

[5] Also tested with Android 7, which had no support. See full testing output.
[6] Announces collapsed/expanded state on focus, but not on selection

---

Show full testing output

Checkboxes

Behaviour	Announces collapsed state on focus	Announces expanded state on focus	Announces expanded state when checked
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 / Firefox 81	✅ Email check box not checked collapsed	✅ Email check box checked expanded	✅ "checked expanded"
NVDA 2020.3 / Chrome 86	✅ Clickable 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."
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"
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
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

Radios

Behaviour	Announces collapsed state on focus	Announces expanded state on focus	Announces expanded state when checked	Announces expanded state when changed
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 / 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"
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
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"
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"
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
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.

[36degrees]

Looking at the results for Chrome 86, you can see in the accessibility properties in Chrome developer tools that Chrome exposes the expanded state for checkboxes but does not for radios:

Based on the results we saw for for NVDA / Firefox and JAWS /IE 11, I'd expect that if Chrome was updated to expose the expanded state for radios then we'd see it working equivalently for radios in JAWS 2020 / Chrome and NVDA / Chrome as well.

EDIT: The checkbox role is explicitly listed as supporting aria-expanded in Chrome's source code but the radio role is not:
https://source.chromium.org/chromium/chromium/src/+/master:third_party/blink/renderer/modules/accessibility/ax_object.cc;l=2739-2769;drc=5848e4951621da8485b73619b363bedd8e4a41c3

It looks like this is a result of the changes in the ARIA 1.2 working draft – see https://chromium-review.googlesource.com/c/chromium/src/+/1686724 which 'brings AXObject::SupportsARIAExpanded() into alignment with ARIA [1.2]'

[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.