Skip to content
This repository has been archived by the owner on Dec 1, 2019. It is now read-only.

Screen reader text links being read without spaces #972

Closed
joedolson opened this issue Nov 7, 2019 · 9 comments
Closed

Screen reader text links being read without spaces #972

joedolson opened this issue Nov 7, 2019 · 9 comments
Assignees
Labels

Comments

@joedolson
Copy link

After reading this review on Twenty Twenty (https://www.jcarson.wtf/2019/11/07/525/), I tested the behavior of the skip link and comment reply link text and they do behave as described when read by a screen reader. E.g. "Skip to the content" is read as "skiptothecontent"

This is a major flaw, but it's not immediately obvious to me why it's happening. This problem does not happen in Twenty Nineteen - tested using identical browser (Firefox 70.0.1)/screen reader (NVDA 2019.2.1).

@pattonwebz pattonwebz self-assigned this Nov 7, 2019
@pattonwebz pattonwebz added bug Something isn't working high priority labels Nov 7, 2019
@pattonwebz
Copy link
Member

This is really interesting that behaviour here is different. I am not certain why that may be either but I will do some looking at code differences to see if I can spot anything. I would think this is a high priority item to resolve.

@joedolson
Copy link
Author

Thanks for jumping on this - it's a super strange bug. Take a look at this: https://medium.com/@jessebeach/beware-smushed-off-screen-accessible-text-5952a4c2cbfe

But if this is the issue, I don't see why it would effect Twenty Twenty but not Twenty Nineteen..

@joyously
Copy link

joyously commented Nov 7, 2019

I thought I got this from the definition used by core (used in my theme):

word-wrap: normal !important;
	/* Many screen reader and browser combinations announce broken words as they would appear visually. */

@joedolson
Copy link
Author

Yes, that is from the core definition - and it's what's used in both Twenty Nineteen and in Twenty Twenty. So, while I'm aware that the Jesse Beach post addresses this as an issue, it's something we discussed a couple times previously. At that time, the problem didn't seem to effect anything we were doing - but now that it's cropped up, we may need to try and figure out why. See conversations at https://wordpress.slack.com/archives/C02RP4X03/p1476472584002141 and https://wordpress.slack.com/archives/C02RP4X03/p1478713344000355.

@carolinan
Copy link
Contributor

I did not experience this while testing with NVDA but I am not a screen reader user so obviously I don't always recognize unexpected behavior.

@joedolson
Copy link
Author

It would be hard to notice aurally, since the words in question have very clear word boundaries and will be pronounced correctly, but with shorter spaces than usual. I keep the NVDA text viewer enabled so that I can see what it's trying to pronounce, which helps note these types of things. These kinds of word ellisions can be serious problems when the word boundaries are less well-defined.

@abrightclearweb
Copy link

I've just tested on Twenty Twenty's Hello world post (using NVDA, Windows 10 and Firefox 70) with the solution from the Medium article, which is also referenced in this post: https://cloudfour.com/thinks/see-no-evil-hidden-content-and-accessibility/

i.e. add white-space: nowrap; to the .screen-reader-text class.

It solves the "Skiptothecontent" problem. That is read correctly as "Skip to the content".

It almost works for "1 Comment on Hello world!" which is read as "1 Commenton Hello world!"

I've attached an image of the NVDA Speech Viewer for my test.

NVDA Speech Viewer

@pattonwebz
Copy link
Member

Testing different fixes for this I am able to correct most of them except the one noted by @abrightclearweb . The post meta comments link uses the core comments_popup_link() function which includes a leading space inside of the .screen-reader-text. I am unable to make the screen readers I am testing honour that space.

I opened a PR to correct the main issue and will look at the spacing between the comments statement.

@ianbelanger79
Copy link
Contributor

Fixed in #988

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

No branches or pull requests

6 participants