Accordion NVDA browse mode adjustment causes long announcements to be cut off in NVDA browse mode

[hannalaakso]

What

The accordion section button has a CSS adjustment that potentially improves the NVDA browse mode announcements by making NVDA browse mode perceive the button content as one element and announcing it as such, instead of multiple ones that are announced separately. It was implemented after some discussion at the accessibility clinic - see commit message for details.

However, it seems that the CSS adjustment causes long announcements to be cut off in NVDA browse mode, for instance

clickable  heading    level 2  button  collapsed    Providing assisted digital support   , Helping people who don't have the skills or access to use a 

(This is on the second accordion on https://govuk-frontend-pr-2257.herokuapp.com/full-page-examples/campaign-page).

The CSS adjustment incidentally has the favourable effect of limiting the width of the focus state so we'd have to handle the width of the focus state in a different manner if we removed this fix. I've prototyped that in JS and it seems to work although I need to do a bit more testing. Reverting the fix also seems to resolve this (rather minor) bug in Windows High Contrast Mode: #2354

I think we'd just like to find out from the original contributor on whether they agree that we should revert the CSS adjustment or if there is something we're not aware of.

Why

We don't have evidence that the default NVDA reader mode behaviour that the CSS adjustment overrides is an issue as was discussed at the accessibility clinic. If we get evidence that there is an issue with it, we could investigate that. However, for now it might be safer to remove the CSS adjustment to makes sure long NVDA browse mode announcements aren't cut off.

Who needs to know about this

Developers

Done when

• We've considered what impact removing the CSS adjustment might have by speaking to the GOV.UK Accessibility team
• We've agreed next actions

[chris-gds]

Upon investigation of this issue there have been a few discoveries

Context

NVDA has two types of modes, Browse Mode and Focus Mode.

• Browse Mode (using arrow keys) allows "complex read-only documents such as web pages are browsed in NVDA using browse mode"

• Focus mode is used when interacting with an element

this section was added as hidden text next to the new icon and the word Show. This was done to provide a balance between the desired Design while providing additional context for users with visual impairments. The new design was felt to add enough affordance to communicate to users the upcoming interaction. A user would hear Show this section instead of just Show - Show what? - this was also based on an earlier prototype

The original intent of the NVDA investigation was to resolve a disjointed announcement of Show this section while in Browse Mode. This disjointed issue on NVDA was highlighted at the Accessibility clinic yet noted as not a WCAG fail. It was also noted as being unclear if this would be an issue to NVDA users or if they would expect this. After investigation a technique was found that resolved this, and on balance, we decided to proceed. The CSS technique in place alters the display property and allows NVDA to read Show this section without being disjointed.

The issue raised above highlights a particular behaviour when the user is using NVDA Browse Mode and is navigating through the Accordion. As they moves through the button the text that is announced is:

[Insert to go into browse mode, press down key]

clickable  heading    level 2  button  collapsed    Providing assisted digital support , Helping people who don't have the skills or access to use a 

[press down key again]

heading    level 2  button  collapsed    service. , Showthis section

Behaviour highlighted

It was initially unclear why the sentence Helping people who don't have the skills or access to use a service was being cut off, on deeper investigation this is related to the user-defined setting while in Browse Mode.

The number of characters is restricted - in this case to 100. After reading 100 characters the Content being read will stop and user can press the down arrow to read the next section. In this context the total number of characters inside the entire button is being calculated and as a result, it stops - as expected. Should a user increase this number to 200 the behaviour is not present. The word service is not read out by NVDA Browse mode in this context and is missed off even when the down key is pressed.

"Maximum Number of Characters on One Line
This field sets the maximum length of a line in browse mode (in characters)."

In addition, to this should user press the "B" key (or Shift-B) for "button" NVDA will cycle through the buttons on the page much like headings or the H key. Using the "B" will announce the full Content within the button as expected with no cut off to the word service

While in browse mode NVDA + Firefox indicates this mode with a red outline while Focus mode is shown with a blue outline (switching from Focus Mode to Browser mode is show with a dotted blue outline)

Outcome

On balance we've decided to revert this.

Firstly, it's unclear why the word service continues not be announced by NVDA. Additionally, Focus Mode seems more appropriate for this interaction, and based on NVDA documentation, would expect users to interact with the Accordion in this way - removing the need for this adjustment. Browse Mode seems to be more suitable for reading Content. Should there be a longer piece of Content NVDA would appear to intentionally pause for user input rather than read the entire paragraph (based on user settings). However at present this is unclear if users actually interact with NVDA in this way on a day-to-day basis and the impact to user from the original disjointed issue. The adjustment adds complexity and additional long-term considerations (Eg should NVDA be updated there might be a regression)

Another possible solution is to alter the Design to reflect the hidden text, so instead of just Show - Show this section is present removing the need for hidden text and the additional CSS technique. Additionally this solution has the added benefit that what is visually seen matches up what is heard from a screen reader. Another approach is to add aria-label="Show this section" on the span. However at present I would not recommend a further iteration without user testing.

We don't have evidence that the default NVDA reader mode behaviour that the CSS adjustment overrides is an issue as was discussed at the accessibility clinic. If we get evidence that there is an issue with it, we could investigate that.

Echoing the same sentiment - should user testing, feedback or additional information change our understanding of this we can review

[hannalaakso]

Reviewed by @vanitabarrett, moving to done.