Announce whitespace in screen reader announcements of visually hidden text #3836
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Absolute positioning has the unintended consequence of removing any whitespace before or after visually hidden text from the accessibility tree. This can lead to unintelligible screen reader announcements, such as the GOV.UK search results heading being announced as "Searchall content", instead of "Search all content".
Insert a space character before and after visually hidden text using pseudo elements to ensure correct screen reader announcements of visually hidden text with surrounding whitespace. This 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 spare characters when navigating by headings - but this is unlikely to block any users and the user numbers for Mac VoiceOver are small compared to other assistive technologies.
I also looked into using `opacity: 0`, without `position: absolute` - this tested well in all screen readers and browsers, with the text visually hidden but accessible to assistive technologies. However, as it doesn't remove the element from the page flow, long visually hidden text would end up wrapping and pushing other elements down the page. Another alternative, also explored on the original ticket would be to use a non-breaking space . This also tested well, but would require always to be inserted in the markup along the visually hidden text, making it more of a manual fix which might also get accidentlaly removed by the next person working in the file. Another alternative would have been to use aria-label with "Search all content" but this doesn't get announced at all by JAWS and Mac VoiceOver (even though it fixes the iOS VoiceOver issue and seems to be allowable content on headings).
colinrotherham
force-pushed
the
include-space-in-visually-hidden-text
branch
from
d50d507
to
722e6b9
Compare
|
Thanks @hannalaakso this is great I've changed the branch to Would you mind double checking the HTML indentation? One of the checks has caught it |
hannalaakso
force-pushed
the
include-space-in-visually-hidden-text
branch
from
722e6b9
to
4590118
Compare
|
Thanks @colinrotherham 👍 I've just fixed the indentation issue. |
domoscargin
added
accessibility
submitted by user
and removed
awaiting triage
owenatgov
approved these changes
Jun 27, 2023
There was a problem hiding this comment.
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
force-pushed
the
include-space-in-visually-hidden-text
branch
from
4590118
to
8d7d0eb
Compare
colinrotherham
approved these changes
Jun 27, 2023
There was a problem hiding this comment.
Just pushed a few more tiny indent things but I'm happy when @owenatgov is happy 🙌
Thanks @hannalaakso
tombye
added a commit
to alphagov/notifications-admin
that referenced
this pull request
Nov 15, 2023
Borrowed from v5 of govuk-frontend which includes the changes from this pull request to fix an issue with how certain screen readers announce spaces in visually hidden text: alphagov/govuk-frontend#3836
frankieroberto
added a commit
to nhsuk/nhsuk-frontend
that referenced
this pull request
Jun 8, 2024
… text This fixes a bug in the nhsuk-u-visually-hidden helper class where any whitespace surrounding visually hidden text isn't announced by screen readers. This fix was added to `govuk-frontend` in [pull request #3868](alphagov/govuk-frontend#3836) and has been re-applied here. Thanks to @hannalaakso for the work upstream. Co-Authored-By: hannalaakso <[email protected]>
frankieroberto
added a commit
to nhsuk/nhsuk-frontend
that referenced
this pull request
Oct 15, 2024
… text This fixes a bug in the nhsuk-u-visually-hidden helper class where any whitespace surrounding visually hidden text isn't announced by screen readers. This fix was added to `govuk-frontend` in [pull request #3868](alphagov/govuk-frontend#3836) and has been re-applied here. Thanks to @hannalaakso for the work upstream. Co-Authored-By: hannalaakso <[email protected]>
frankieroberto
added a commit
to nhsuk/nhsuk-frontend
that referenced
this pull request
Oct 17, 2024
… text (#960) This fixes a bug in the nhsuk-u-visually-hidden helper class where any whitespace surrounding visually hidden text isn't announced by screen readers. This fix was added to `govuk-frontend` in [pull request #3868](alphagov/govuk-frontend#3836) and has been re-applied here. Thanks to @hannalaakso for the work upstream. --------- Co-authored-by: hannalaakso <[email protected]> Co-authored-by: anandamaryon1 <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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) withposition: absoluteincluded 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-labelsolution 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-hiddenwhen CSS fails to loadOther fixes that were explored
I also looked into using
opacity: 0as a possible replacement forposition: 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.xbranch, let me know if that's not right.Fixes alphagov/reported-bugs#51