The logical order of conditionally revealed content as it appears within a set of radios or checkboxes can be confusing

[36degrees]

The conditionally revealed content appears immediately after the control that reveals it. This means that it’s 'mixed up' within the logical order of the set of checkboxes or radios.

This can cause confusion for screen reader users, as illustrated by this research finding from the checkboxes backlog issue:

[We've just taken] our agent facing service to usability testing with someone who uses JAWS. Our biggest issue that we kept encountering was the use of conditional reveal, we think that with familiarity this issue would go away but it's definitely something we want to just work straight away without explanation.

User was presented with radio buttons as seen below:

The user selected yes and then tabbed as they thought they had completed the section.
It read out the label for the conditionally revealed input (although this was inconsistent, we want to get a JAWS device over the coming weeks and try and replicate the different behaviours, as sometimes the label was getting skipped)

The user then used the cursor down option in JAWS to see what else was on the page, and the next thing was "no"; this caused a lot of confusion because they thought it had jumped into the next radio button group, so this caused a lot of tabbing back and forth to try and find out where that "no" was coming from, at this point we then explained where that conditional content was in relation to the page.

We have multiple other questions like this with similar content being revealed and this was a consistent theme, unsure which radio group they were in after entering the conditionally revealed content. This was also an issue when we had a legend explaining the question which was then being read out before the "no", because then it was as if tab had put them backwards in the form.

To summarise, user pressed tab after selecting radio button, which put them into the conditionally revealed content, they thought that was the next question so when they looked at the next part of the page and it was the remaining radio options they were completely unsure of where they were.

Originally posted by @alexnewmannn in https://github.com/alphagov/govuk-design-system-backlog/issue_comments/533134507

[36degrees]

In research carried out by the Design System team in December 2020, participant 1 (a severely sight impaired user using VoiceOver on macOS) became disorientated when navigating through a page that included a conditional reveal that revealed another fieldset containing multiple inputs.

We included a conditional reveal with multiple revealed fields as we know that conditional reveals are being used to reveal increasingly complex additional content and, already aware of this as a potential issue, wanted to see how it performed.

The form was made up of a fieldset containing 2 radio buttons with the legend 'Do you know the details of your healthcare professional?'. When 'Yes' was selected, a nested fieldset with the legend 'What's the address of your healthcare professional?' with 6 text inputs for name, building and street, town, county and postcode was revealed immediately after the 'Yes' radio button.

The user selected 'yes' and filled in the details for their healthcare professional. However, after they filled 'London' in the 'Town/city' input they were taken directly to the 'No' radio button. (Current hypothesis: they ended up pressing Command-VO with 'n' still being pressed as the last letter in 'London' which is the shortcut for 'Next auto web spot', which in our testing matches the observed behaviour and takes the user straight to the 'No' radio button, skipping the county and postcode fields)

They were then disorientated by the placement of the 'No' radio button as they expected it to be with the 'Yes' radio button before the address fields.

Despite this, the participant was able to complete the task and move on to the next page.

Transcript

Some VoiceOver output is omitted when the user is navigating through multiple form fields

VoiceOver: Town or city, Town or city L o n d o n What's the address of your no no no end of what's the address of your healthcare professional group no give the address details of your

Participant 1: Why have I got a no there? It's reading me 'no'.

VoiceOver: No no.

Participant 1: Sighs [Navigates backwards]

VoiceOver: What's the address of your healthcare professional? Postcode

VoiceOver: What's the address of your healthcare professional? Give the address details of the healthcare professional involved in the treatment of your condition. For example, your surgeon, physiotherapist or GP.

Participant 1: It jumped to that, I did London then it missed out the postcode, it did a jump to that next question, I don't know why.

[Navigates backwards]

VoiceOver: County

Participant 1: "Oh it missed out county as well. I'm going to leave county clear. It might want Greater London but…"

VoiceOver: "Postcode"

[Enters postcode]

[Navigates forwards]

VoiceOver: "No. Give the address details of the healthcare professional involved in the treatment of your condition. For example, your surgeon, physiotherapist or GP. No. Do you know the details of your healthcare professional? Group. Give the address details of the healthcare professional involved in the treatment of your condition. For example, your surgeon, physiotherapist or GP."

Participant 1: I don't like how this… this is just a mess. It’s reading no’s all over the place. That should finish after that. That no was above, unless the no was for the question below

User researcher: So you put the address in and then...

Participant 1: I put the address in, but I'm sure it asked me above for the 'no's so why have I got 'no's [navigates backwards through the page to 'Yes'] oh it didn't, why isn't the no up there? would be my question, and why is it whizzling me from London to the 'no' without me looking at the others, [navigating forwards through the form] so there's a bit of coding that needs correcting there. I'm obviously losing the focus for some reason."

VoiceOver: "Submit"

Participant 1: OK, I'm going to Submit that.

---

There's a few odd things going on here that may have compounded the issue:

• the user somehow navigating directly from the town/city to the 'No' radio button
• repetition of some of the announcements – however, we don't know what keyboard shortcuts the user was using when, so it's likely that many of the repeated announcements were triggered by the user as they explored the form
• the aria description for the parent 'Do you know the details of your healthcare professional?' fieldset being read when focusing the fields within the nested 'What's the address of your healthcare professional?' fieldset

[hannalaakso]

As discussed in alphagov/govuk-design-system#1508 (comment), we identified some examples of conditional reveals where the revealed content is below the radios. However with these examples users could miss that some content has been revealed below on mobile resolutions or if the page is zoomed in at a high resolution. It's possible that these issues could be negated by the fact that users have to pass by the revealed content before they reach the submit button. On the other hand we should consider how 4.1.2 and 4.1.3 impact the interaction.

@terrysimpson99 additionally raised some useful points in alphagov/govuk-design-system#1508 (comment) and alphagov/govuk-design-system#1508 (comment).

[36degrees]

In March 2021, we spoke to a Lead Auditor at the Digital Accessibility Centre (DAC) 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 said that they'd found conditional reveals can be difficult for people with vision impairment to navigate, but they hadn't noticed issues with any other user groups that they test with.

The main issue they talked about was information overload. Long conditional reveals would be flagged as they increase the length of the page, which can make it disorientating for users. They suggested that the revealed content should be moved to a separate page instead.

Conditionally revealing a single input field (for example) is normally OK. However, there’s always a chance that people navigating “out of context” (e.g: tabbing; or by links, headings, lists etc) can miss the information in a conditional reveal.

Revealing text content

When presented with this example of conditional reveals that revealed warning text, they said that they would flag it as an issue, although it wasn't something they'd seen in audits.

They said that users who navigate out of context are likely to miss text in a conditional reveal. As such, warning text should be in the main page content, for consistency purposes and so it’s not missed.

Revealing multiple fields

When presented with the example from our user research prototype, where a radio button reveals multiple additional fields, they said:

The main issue is that the conditionally revealed content is so long. We would definitely flag this as it is information overload - this content should be on a separate screen.

From an accessibility perspective, I can’t remember if we’ve tested examples as long as this, I imagine users with vision impairments would struggle. If a user is navigating through each element, they will have to navigate through each radio button under the conditional reveal, which may be confusing

Alternative approaches

Finally, when presented with an alternative version where the conditionally revealed inputs appear after the entire radio group, they said:

Yes, this (content below radios) definitely looks like a better way of doing it, I can see why this might be better and easier to use. This looks like a better option. A user navigating through each element would still go through all the radio buttons, but it’s clearer what all the options are and there’s nothing in the middle almost getting in the way or changing the context.