Reported by zersiax on 2015-10-30 11:57
While testing a website for accessibility, an issue was uncovered where it appears that text hidden by screenreaders via the 'set width and height to 1px' method is stripped of spaces when it is rendered. This often happens when people hide small bits of instructional text for example in a span element.
The height property does not seem to trigger this problem, its only when the width of an element is reduced to 1 pixel that the spaces disappear.
I'm not sure if this is a Firefox or NVDA issue.
Comment 2 by zersiax on 2015-10-30 12:11
Just tested the same scenario with Internet Explorer version 11. The issue does not appear there.
Comment 3 by MarcoZehe on 2015-10-30 12:38
A small test case that demonstrates the problem would be good.
Comment 4 by zersiax on 2015-10-30 15:36
While trying to create a test case I have found this issue is more complex than first assumed. On a test page toggling the width CSS rule shows or doesn't show the issue, depending on if it's toggled on or off. However, testing with just that CSS class in a different HTML file seems to not trigger the behavior. I am still trying to figure out what the exact set of conditions is to get this to show up. A similar problem is visible in the WordPress admin area in the list of pages. The first column in the table, the one with the checkbox in it, also has it's spaces missing and I think the cause might be similar or the same.
For anyone looking for a workaround, add this to your offscreen/screenreader-only CSS class:
white-space: nowrap;
overflow: hidden;
This causes it to be a single overflowing line, which seems to get rid of the issue for us while still keeping it hidden off screen.
I was able to track down what causes it, and have created a proof-of-concept here: https://github.com/JasonTarka/proof-of-concepts/tree/master/screen-readers
It's caused by word-wrap: break-word being applied. Spaces are likely not included since when something is split across lines, the browser strips out superfluous spaces.
@JasonTarka thank you for this proof of concept. With it, I can still reproduce this issue in NVDA 2018.4.1 and with Alpha 16691,10590C87 on Firefox 65. cc: @jcsteh I wonder if something can be done from NVDA's side or if this is a firefox bug? In Crhome and IE the issue is not occuring.
I acknowledge that this only occurs in Firefox. That said, it's hard to know what to do here. Normally, for text, we want to rely on layout information from the browser so that screen reader users get the same formatting, etc. as sighted users would see. The problem with off-screen text is that it breaks this convention. It's not explicitly marked as "accessibility only" (like ARIA attributes indicate), yet that's the intention. There's no straightforward/reliable way for a browser to know whether it's truly "accessibility only" forever or whether it might at some point be scrolled on screen so it can be seen visually (as is often done with skip links for keyboard users). This is one of several reasons I think off-screen text is a bad idea that really needs to disappear.
Note that while this doesn't strip white space in Chrome, it does break line calculation. Each character reports as being on its own line. NVDA browse mode currently ignores the browser's idea of lines (except in Edge), so this doesn't affect NVDA right now in Chrome, but this will probably change eventually.
I'm trying to think of ways we could mitigate this in Firefox without breaking other things. So far, I'm not succeeding. We could possibly detect this with some minimum threshold of width for off-screen text, but the question is what to do then. Simply taking the text from the DOM instead would break line calculation, etc. There's only so much we can do to mitigate things like this and I think this may end up being a case of authoring error we just can't work around.
There is definitely no way to work around this in NVDA.
CC @MarcoZehe.
This is not reproducible in NVDA alpha-17134,363af94b and Firefox 66.0.3 anymore. Closing as works for me.