Summary list action links visually hidden text are read out without spaces in screen readers

[NickColley]

What

This is a report from a screen reader user:

https://design-system.service.gov.uk/components/summary-list/

You use visually hidden text to give your links unique and descriptive
names. Unfortunately, you often omit the space between the words. This
can make the names harder to recognize when speech synthesizers
mispronounce the combined word. For example:

"Open this summary listexample in a new window"
"Changename"
"Changedate of birth"
"Changecontact information"
"Changecontact details"

I believe that I missed this as audibly it sounds correct to me, but I imagine depending on how you have your screen reader configured, for example how fast you have words announced, it could make it hard to understand.

I've managed to reproduce this issue in NVDA + Firefox and used the 'speech viewer' tool to see what the user has found.

The user has also let us know that the following combinations have the same issue, which suggests that it's an issue with most screen readers:

Orca 3.28.0 with Mozilla Firefox 70.0.1 on Ubuntu Mate 18.04
NVDA 2019.2.1 with Mozilla Firefox 70.0.1 on Microsoft Windows 10
NVDA with Google Chrome 78.0.39 on Microsoft Windows 10.
JAWS 2019.1809.28 with Mozilla Firefox 70.0.1 on Microsoft Windows 10
JAWS 2019.1809.28 with Google Chrome 78.0.39 on Microsoft Windows 10.

Recommend that we consider testing with tools like 'speech viewer' in the future to help catch issues like this.

I tried a quick fix by adding   instead of a space character, and that seemed to resolve this issue, but we'd want to test this across screen readers.

I will also raise an issue in the design system website for the related issues there.

Who needs to know about this

Developers

[NickColley]

We might want to also report this as an issue to the assistive technology vendors as it seems that the accessibility tree has the correct content.

[NickColley]

Next steps:

1. Create an example using   instead of the space character
2. Compare the accessibility trees in different browsers before and after
3. Compare assistive technologies before and after

[selfthinker]

Most probably related: #1032 and alphagov/reported-bugs#39.

[36degrees]

Good call @selfthinker – although we fixed this in the wider 'visually-hidden' class by adding white-space: nowrap, the summary list itself uses word-wrap: break-word:

govuk-frontend/src/govuk/components/summary-list/_summary-list.scss

Lines 59 to 64 in 82811f3

	.govuk-summary-list__key,
	.govuk-summary-list__value {
	// Automatic wrapping for unbreakable text (e.g. URLs)
	word-wrap: break-word; // Fallback for older browsers only
	overflow-wrap: break-word;
	}

I wonder if the same approach might fix it (applying white-space: nowrap)

[NickColley]

I've tested this in a few screen reader combinations and recorded the results in a spreadsheet: https://docs.google.com/spreadsheets/d/1Q-jTC8bcBagPHLlhyxH81FSqlNL446kyMU04st9PJxE/edit?usp=sharing

Will update with thoughts later.

[NickColley]

It seems adding an extra spacing does 'work' but in some assistive technologies now there is double spacing which could impact pronunciation too.

One thing that's interesting to me is that the accessibility trees are correct but then the screenreader can read something different to the tree, which means either:

• the screen reader uses additional information to determine the announcement.
• the output of the screen reader is actually correct but the 'speech viewer' is not.

It's hard to know if it's the latter without real user feedback, we could consider messaging the original issue raiser to ask them if they ran into this from being confused or from a testing perspective.

Through doing it I did wonder if there was a way to tweak the CSS itself to see if that's the issue, but this is one of those really gnarly ones that also takes a really long testing.

[NickColley]

Things we could do to go forwards with this issue:

• explore changing the visually-hidden class properties (previous change here: Update visually hidden class to fix ordering issue in VoiceOver OSX #1109)
• adopt the &nbps; approach.
• start promoting the use of aria-label where possible.
• look at the recent user research session with a participant who uses a screenreader to see if they ran into issue.
• go back to the original issue reporter and see if we can learn more if this is a barrier for people or just a oddity from a testing perspective.
• raising bugs with assistive technology vendors.

[NickColley]

Had a chat with Ollie.

We're going to try to make reduced test cases to raise bugs with the assistive technology vendors as the accessibility tree is correct, this process may also help us learn more about the underlying issues and also the vendors themselves may be able to give us advice if they've seen this sort of issue before.

[NickColley]

• NVDA: NVDA omits space between blocks of text nvaccess/nvda#10208
• JAWs: JAWS with Chrome links visually hidden text are read out without spaces reported-bugs#51

Test case: https://output.jsbin.com/jorocat

  <a href="#">Link in page</a>
  <br>
  <button>
    Open all<span class="visually-hidden"> sections</span>
  </button>
  <br>
  <a href="#">
    Delete<span class="visually-hidden"> name</span>
  </a>

.visually-hidden {
  position: absolute !important;
  width: 1px !important;
  height: 1px !important;
  margin: 0 !important;
  padding: 0 !important;
  overflow: hidden !important;
  clip: rect(0 0 0 0) !important;
  -webkit-clip-path: inset(50%) !important;
          clip-path: inset(50%) !important;
  border: 0 !important;
  white-space: nowrap !important;
}

[NickColley]

Closing this out as raised issues, hopefully they get resolved! We can re-open if this becomes a more serious issue for our users.

We should also consider using aria-label where appropriate going forwards.

[adamliptrot-oc]

This could be fixed by providing two seperate blocks of content rather than concatenating them, such as this:

<a href="#">
  <span aria-hidden="true">Delete</span>
  <span class="visually-hidden">Delete name</span>
</a>

The only downside of this is duplication of content if CSS is disabled, but that can be fixed by adding a hidden attribute to the first span which is overridden with CSS when available.
This also fixes any odd grammatical issues which arise from concatenating words when translating to other languages.

[adamliptrot-oc]

There are some other issues with the current implementation

Voiceover iOS

In Voiceover on iOS the span in the middle of the accessible name means that if a user is navigating by links they hear:

“link: Change your name” (swipe)
“link: Change” (swipe)
“link: Your name”

Android TalkBack

With Android TalkBack when a user is navigating normally by swiping the effect is the same as with VO navigating by links as in there are multiple navigations needed to move through a link

[edwardhorsford]

We've had this issue reported in an accessibility audit, though I don't know for what AT combinations.

[ladine-cook]

Digital Accessibility Centre (DAC) raised this issue in a recent audit for a New Style Employment and Support Allowance. I can share the full report if useful.

[lfdebrux]

Hi @ladine-cook, thank you for letting us know this issue has been raised by DAC. If you are able to share the full report with is that would be amazing, we would especially like to know which browser/assistive tech combination this issue was found in (including versions).

[lfdebrux]

Thanks for sending that over @ladine-cook, that was very useful.

It looks like again they were seeing this issue with JAWS (versions 18 and 19), although I'm not sure whether it was with Firefox or IE11.

I can reproduce the issue using the check your answers pattern example in AssistivLabs with JAWS 2021.2103.174 and Firefox or Chrome, but not with JAWS and IE11.

It's a bit of a shame that nothing has moved on the issue we raised with JAWS FreedomScientific/standards-support#372, I've leave a message on the issue to see if we can't get this fixed upstream.