Step-by-step navigation does not convey all of the information for screen reader users when viewing them as forms

[CharlotteDowns]

This issue is from May 2023 external accessibility audit report.

Usability issue

Issue ID: DAC_Usability_Step_By_Step_01

URLs: https://www.gov.uk/visit-uk-business-trip

Screen shots

The step by step navigation page consists of headings containing buttons as the components used to expand the content. However, the step number content is not included within the button elements. This means that the step information is only conveyed when viewing them as headings and not as forms.

Current code ref(s)

#apply-for-a-family-permit

Screen reader comments

“I found that there were multiple steps in the process with both the step number and accordion buttons marked-up as headings.

JAWS and NVDA: With the desktop screen reader software, I found that when using headings shortcut commands such as the ‘h’ key both the step and the accordion appeared within the same heading announcing as a single item. In context, however, these items appeared to be separated on different lines, although the content was clear when using the headings. When using form element shortcuts, however, the step did not announce within the label of the accordion announcing only the category. While situated out of context I was not able to easily understand the order of the steps and could only view the category. I would have found it easier if the content located within the heading text could also be found within the label of the accordion as this would enable me to immediately understand what is occurring both in and out of context.

VoiceOver: When I moved in context, I found that the ‘Step’ heading appeared over two separate lines. I needed to swipe three times past each category to move to the next category with two swipes needed to move past the heading and then the third to move past the category. This content made the structure more difficult to understand although I was not prevented from understanding the content as a highly experienced screen reader user. When using the forms rotor like desktop screen reader software I was not able to locate the step number with only the category announcing therefore making the order more problematic to understand.

TalkBack: With TalkBack I found that the step and category announced over multiple lines. When using the ‘Controls’ menu I was only able to locate the name of the category meaning the order was not clear. I also found that the headings relating to the step and accordion were not detected when swiping in context. Instead, I needed to use the headings rotor to locate the headings meaning that in a non-testing environment some screen reader users may not locate the headings and could become confused.”

Solution

Consider incorporating all of the content and information into the element, allowing for users of screen reading assistive technologies to have that information announced and conveyed with the label of the form, and not just the heading.

[querkmachine]

It would be pretty difficult to move the existing number to the same inner element as the heading without dramatically changing the appearance of the component. It would seem that it would instead need to be duplicated, with the duplicate made visible to screenreaders only and the visible number being [aria-hidden]. That way, the visible number will be ignored and the duplicate announced.

Doing this will end up showing two numbers in cases where CSS doesn't load, so applying [hidden] to one of the above may also need doing.

I'm also not sure how much this sits within our remit given this isn't a component currently shipped with Frontend, instead being part of GOV.UK Publishing Components.

[dav-idc]

@querkmachine is there any way we could use aria-labelledby to stitch together a few pieces, like the number, label, etc? I would suggest an aria-describedby so that we don't end up overriding the existing label, but it seems weird to have a describedby of a single number character, when describedby is usually meant for a longer snippet of description content.

[querkmachine]

@davidc-gds In experimenting quickly, it seems like that is certainly possible. Each 'step' and 'title' will need ids that they don't currently have, but in my brief local mockup and VO testing, it seems like aria-labelledby mostly does the trick.

The markup potentially is making this messier than it needs to be. Currently each heading is constructed of a <h2>, within which some of the content (the heading text and show/hide label) is contained within a <button>.

In VoiceOver, if you're navigating one element at a time or using the 'Headings' section of the rotor, upon landing on the header you get this overly-verbose readout of the contents. Interesting how our visually-hidden text in 'Show this section' is getting crunched up into one word, whereas the visually hidden text in 'Step 2:' is being split apart.

heading level 2, 3 items, Step, clickable, 2, clickable, Check if you need a visa, ShowThis Section, collapsed, button, group, 2 of 7

When navigating in VoiceOver by tabbing through interactive elements or using the 'Form Controls' section of the rotor, you receive a readback that omits the step number:

Check if you need a visa, ShowThis section, collapsed, button, group

I had to apply aria-labelledby to both elements, and whilst I still didn't get complete consistency between them, the output generally seemed to be improved. Navigating manually or Headings rotor now resulted in the below, where all mentions of the heading being interactable have seemingly been purged. (Good?)

heading level 2, 3 items, Step 2: Check if you need a visa, Show this section

Whereas navigating by tabbing or with the Form Controls rotor resulted in this, crunching the output a little and omitting the "show this section" instruction. (Arguably it isn't needed as the state of aria-expanded is being reported instead?)

Step2 Check if you need a visa, collapsed, button, group

[dav-idc]

Thanks for the quick experiment @querkmachine! So it sounds like it's certainly doable with aria-labelledby it would just be a matter of tweaking the actual implementation until the readouts with various screen readers are adequate.

Perhaps a rough protoype would be the next step, and we can run it through JAWS or NVDA to make sure there's no major egregious blockers?

[querkmachine]

I've made a branch that adds the step by step to the review app with the changes I mentioned implemented: https://github.com/alphagov/govuk-frontend/pull/3901

https://govuk-frontend-pr-3901.herokuapp.com/components/step-by-step-navigation/preview

[dav-idc]

It seems to work with VoiceOver pretty well. I won't have time to check with NVDA or JAWS until after Wednesday though, if you or someone else wants to.

https://github.com/alphagov/govuk-frontend/assets/98318778/a6d8844d-c201-4c8f-bba2-e79fd7077ed0

Video description

A screen recording of an example step-by-step navigation pattern, with the following pieces of text.

Focusable area 1:

• Show all steps

Focusable area 2:

• 1
• Do a thing
• Show

Focusable area 3:

• and
• Do another thing
• Show

Focusable area 4:

• 2
• Do something else
• Show

When tabbing between the different elements during the video, portions of the visible text is highlighted with a yellow focus indicator.

When tabbing between each focusable area, the following audio can be heard, in this sequence and at these tab locations:

(The video starts with focus on focusable area 1)

Tab to focusable area 2: "Step 1 do a thing. List 3 items."

Tab to focusable area 3: "And do another thing. You are currently on a button. Group."

Tab to focusable area 4: "Step 2 do something else. You are currently on a button. Group. Inside a heading level 2. To click this button, click control, option, space."

Tab back to focusable area 3: "And do another thing."

Tab back to focusable area 2: "Step 1 do a thing. You are currently on a button. Group. Inside a heading level 2."

(And then the video ends, with focus on focusable area 2)

[querkmachine]

Comment from @davidc-gds on Slack, copied here for posterity:

Maybe we cen just add guidance saying that ideally the number gets read out with the label. Then like you said, it’s up to the teams actually making the code to determine how that works :shrug: Seems like a cop-out, but it would also help us remember to add in the number for the label if we ever code an example step-by-step nav for the design system.

[dav-idc]

@querkmachine should I transfer this ticket to the govuk-design-system repo, now that it's a content intervention?

[querkmachine]

@davidc-gds Go for it!