Announce whitespace in screen reader announcements of visually hidden text

[hannalaakso]

This PR fixes a bug in the visually hidden helper class where any whitespace surrounding visually hidden text isn't announced by screen readers.

The issue

The issue came up in user research, with a user saying that it was challenging to understand the JAWS announcement of the <h1> on the GOV.UK search results page. The issue has also previously been reported to JAWS. I can replicate it in in JAWS and Chrome/Edge/IE11, as well as NVDA and Chrome/Edge (but not NVDA and Firefox).

The bug is caused by absolute positioning which removes any whitespace before or after visually hidden text from the accessibility tree. This can lead to unintelligible screen reader announcements, such as the above mentioned GOV.UK search results heading being announced as "Searchall content", instead of "Search all content". The bug also impacts screen reader announcements when the visually hidden text appears before the visible text, for instance on the Foreign travel advice page where screen readers read the partly visually hidden heading as "Countries starting withA".

The actual issue can be seen by inspecting the accessibility tree value of the above <h1> on the search results page. Its value is "Search" (without the correct whitespace) with position: absolute included in .govuk-visually-hidden, but it is "Search " (with the correct whitespace) without absolute positioning.

The fix

To fix this, insert a space character before and after visually hidden text using pseudo elements to separate it from any visible text surrounding it. The fix tests well in all screen readers, regardless of whether the whitespace is before the visually hidden text ("Search all content"), after the visually hidden text ("Countries starting with A") or where the heading text is only made up visually hidden text ("Navigation menu"). The only slight issue I found is that Mac VoiceOver in Safari explicitly announces the inserted space characters when navigating by headings - but this is unlikely to block any users and the user numbers for MacOS VoiceOver are small compared to other assistive technologies. I also tested the fix where the visually hidden text appears as a part of a paragraph or a table cell. Please let me know if there are any other contexts I should test this in.

Before

After

Before

After

Testing results

Screen readers

✅ JAWS 2022 / Chrome
✅ JAWS 2023 / Chrome
✅ JAWS 2023 / IE 11
✅ JAWS 2023 / Edge
✅ NVDA / Firefox
✅ NVDA / Chrome
✅ NVDA / Edge
✅ Voiceover / Mac Safari
❎ Voiceover / iOS Safari
✅ Talkback / Chrome Android

iOS VoiceOver announces the visually hidden text separately but this issue is already present on live and has previously been reported here. Interestingly, the below mentioned aria-label solution fixes the issue in iOS (at least on headings; other contexts might not work so well) but has other significant problems as documented below.

Browsers and devices

I was testing that there is no visual difference in the element with the pseudo element space characters.

✅ Edge
✅ Firefox (Mac and Windows, and when user sets their own custom colours)
✅ Chrome (Mac and Windows)
✅ IE 11
✅ Safari Mac
✅ Safari iOS
✅ Samsung Internet (Android)
✅ Firefox (Android)
✅ Chrome (Android)
Samsung Internet
✅ Firefox (Android)

Other modes tested

✅ Print styles
✅ Hidden and unhidden like govuk-visually-hidden when CSS fails to load

Other fixes that were explored

I also looked into using opacity: 0 as a possible replacement for position: absolute. This tested well in all screen readers and browsers in terms of hiding the element but making it available to screen readers. However, the visually hidden text would remain part of the page flow, potentially causing issues by pushing visible page elements out of flow or down the page.

Another alternative, also explored here, would be to use a non-breaking space in the markup. This also tested well, but would always need to be inserted in the markup alongside the visually hidden text, making it more of a manual fix which could be accidentally removed by the next person working in the file (the process of inserting and enforcing the character could be be part of a build pipeline but this would introduce an unworkable overhead in many contexts).

I also explored using aria-label (for instance, "Search all content" for the search results heading), but the label does not get announced at all by JAWS and Mac VoiceOver on headings (even though it seems to be allowable content on headings); using it for paragraphs or table cells would be at least as unlikely to be announced consistently.

Notes to reviewers

I ended up including some examples of visually hidden text in the review app. They were helpful when testing but let me know if you'd rather I removed them. The table example specifically is a duplicate of the content on the bank holidays full page example so should probably be removed unless it's useful to have it in same place as the other visually hidden examples.

I'm comparing the PR with the support/4.6.x branch, let me know if that's not right.

Fixes alphagov/reported-bugs#51

[colinrotherham]

Thanks @hannalaakso this is great

I've changed the branch to support/4.x but only because we already have a v4.7.0 release planned

Would you mind double checking the HTML indentation? One of the checks has caught it

[hannalaakso]

Thanks @colinrotherham 👍 I've just fixed the indentation issue.

[owenatgov]

This looks good to me.

As it's an external contribution thus needing 2 approvals, and to maintain review hierarchy, I'll re-request review from @colinrotherham.

[colinrotherham]

Just pushed a few more tiny indent things but I'm happy when @owenatgov is happy 🙌

Thanks @hannalaakso