Closed joedolson closed 4 years ago
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.
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..
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. */
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.
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.
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.
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.
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.
Fixed in #988
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).