WordPress.org

Make WordPress Core

Opened 2 years ago

Closed 10 months ago

#42006 closed defect (bug) (fixed)

Safari + VoiceOver sometimes read out the screen-reader-text not respecting the source order

Reported by: afercia Owned by: afercia
Milestone: 5.1 Priority: normal
Severity: normal Version:
Component: Administration Keywords: has-screenshots has-patch
Focuses: accessibility Cc:
PR Number:

Description (last modified by afercia)

This appears to be a bug in Safari 10/11 and VoiceOver and it's one more case where CSS has an impact on screen readers behaviors. I've reproduced also in other projects and under different circumstances.

To reproduce in WordPress, just go in an Edit Post screen and using VoiceOver with Safari 10 or 11 navigate to the preview button:

https://cldup.com/FxeZxK3kZP.png

Notice the text (opens in a new window) comes after the visible text in the source but VoiceOver reads out it before... Have done some debugging in different projects with similar results and came to the conclusion Safari and VoiceOver do take into account the absolute position of screen-reader-text.

https://cldup.com/MnNsuP61A6.png

What seems to happen here is that Safari and VoiceOver "see" the visually hidden screen reader text placed a few pixels above the visible text and thus they think it's in a line before the visible text.

Screen readers tend to read "by line" but CSS shouldn't affect the way they announce text so this "feature" seems very questionable to me. It's not the first case where CSS has side effects on screen readers though.

The only way I've found to fix this is moving the screen-reader-text a few pixels down so it's on the same "virtual line" of the visible text, or even a bit below it.

The main issue is that there's no way to predict how many pixels it needs to be moved down. The screen-reader-text class can be used on any element: inline text, buttons (with different heights) and so on. The best solution I've found so far is:

transform: translateY( some value here )

where {some value here} should be equivalent to 1 line height. This should be tested thoroughly with a proper value. Better ideas very welcome! See also #40970.

Attachments (1)

42006.diff (530 bytes) - added by afercia 14 months ago.

Download all attachments as: .zip

Change History (20)

#1 @afercia
2 years ago

Note: A partial fix for this was introduced in [40643] for the news/events dashboard widget, but it doesn't cover all the cases.

This ticket was mentioned in Slack in #accessibility by afercia. View the logs.


2 years ago

This ticket was mentioned in Slack in #accessibility by afercia. View the logs.


2 years ago

#5 @afercia
2 years ago

  • Milestone changed from Awaiting Review to Future Release

Moving to future release for investigation, as per today's accessibility bug scrub.

This ticket was mentioned in Slack in #accessibility by afercia. View the logs.


2 years ago

#7 @afercia
23 months ago

Still an issue on latest macOS High Sierra, Safari 11.0.2, VoiceOver Utility 8 (562.13).

https://cldup.com/jPbs9qeZ6Z.png

#8 @afercia
14 months ago

On the linked html5-boilerplate GitHub issue, a fix was suggested using height: auto. Worth trying that but I'd recommend to start just with screen-reader-text within buttons. I think for normal text there's the need for a different solution.

@afercia
14 months ago

#9 @afercia
14 months ago

  • Keywords has-patch added
  • Milestone changed from Future Release to 4.9.9

42006.diff adds height: auto; to the screen-reader-text CSS class, just when it's used within buttons. Tested on the preview button and fixes the issue.

This ticket was mentioned in Slack in #accessibility by rianrietveld. View the logs.


14 months ago

#11 @pento
14 months ago

  • Milestone changed from 4.9.9 to 5.0.1

#12 @pento
11 months ago

  • Milestone changed from 5.0.1 to 5.0.2

#13 @pento
11 months ago

  • Milestone changed from 5.0.2 to 5.0.3

#14 @audrasjb
11 months ago

  • Keywords commit added

Hi,

The patch works fine on my side.

This ticket is triaged in milestone 5.0.3. Adding commit keyword to the ticket.

#15 @audrasjb
11 months ago

Hi @afercia, are you able to commit this one in 5.0.3? The RC is tomorrow. Thanks :)

#16 @afercia
11 months ago

  • Description modified (diff)

#17 @afercia
11 months ago

This needs to be done also for the new Block Editor, created https://github.com/WordPress/gutenberg/issues/13219

#18 @afercia
11 months ago

  • Keywords commit removed
  • Milestone changed from 5.0.3 to 5.1
  • Owner set to afercia
  • Status changed from new to assigned

Given this should be coordinated with a similar change for Gutenberg, see https://github.com/WordPress/gutenberg/pull/13221, I'd propose to move it to 5.1. Also, not sure it does fit with the 5.0.3 scope.

#19 @afercia
10 months ago

  • Resolution set to fixed
  • Status changed from assigned to closed

In 44543:

Accessibility: Improve the way Safari and VoiceOver read out the screen reader text.

Sometimes, Safari and VoiceOver read out the text hidden with screen-reader-text
in a wrong order. While there's no known, full, solution, it is possible to make
them respect the correct order reliably at least within buttons.

Fixes #42006.

Note: See TracTickets for help on using tickets.