[wp-trac] [WordPress Trac] #42006: Safari + VoiceOver sometimes read out the screen-reader-text not respecting the source order

[WordPress Trac]

#42006: Safari + VoiceOver sometimes read out the screen-reader-text not respecting
the source order
----------------------------+-----------------------------
 Reporter:  afercia         |      Owner:
     Type:  defect (bug)    |     Status:  new
 Priority:  normal          |  Milestone:  Awaiting Review
Component:  Administration  |    Version:
 Severity:  normal          |   Keywords:  has-screenshots
  Focuses:  accessibility   |
----------------------------+-----------------------------
 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:

 [[Image(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.

 [[Image(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 cass 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.

--
Ticket URL: <https://core.trac.wordpress.org/ticket/42006>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform