h5bp/html5-boilerplate — comment on commit aa0396eae757c9e03dda4e463fb0d4db5a5f82d7
File:  line 0
By necolas:

Thanks to [Jason Kiss](http://twitter.com/jkiss), who tested against this testcase - http://jsfiddle.net/necolas/QZvYa/show/, we've got lots more screenreader results. Note that in the results below, `` refers to the element that was given the IR classes. Here is what Jason said:

--------------------------------------------

Here are some results:

NVDA 2011.3
FF10 all good
IE9 all good

JAWS 13.0.718
FF10 all good
IE9 all good

JAWS 11.0.1476
FF10 positive text indent: text inside `` is displayed when it receives virtual focus
IE9 all good

JAWS 10.0.1178
FF3.6.27 all good
FF7 positive text indent: text inside ` is displayed when it gets read
FF10 positive text indent: text inside `` is displayed when it receives virtual focus
IE8 all good

JAWS 9.0.2191
FF5 positive text indent: text inside `` is displayed when it gets read
IE8 all good

SAToGo 3.3.32
IE9 positive text indent: text inside `` is displayed when it gets read

Window-Eyes 7.5.3
FF10 font crushing method: text in `` is not read
IE9 font crushing method: text in `` is not read

Window-Eyes 7.2
FF10 font crushing method: text in `` is not read
IE9 font crushing method: text in `` is not read

Window-Eyes 7.11
FF10 font crushing method: text in `` is not read
IE8 all good

Orca 3.2.1 (Ubuntu 11.10)
FF10 all good

1. I didn't test VO or JAWS 12 as you said you already did those.
2. I've tested quite a few combinations of SRs and browsers, but not a fully comprehensive and consistent set in each case. Nonetheless, these results identify a few issues:
A. The font crushing method appears to work fine in all cases except where Window-Eyes is concerned. W-E just won't announce or read the text "hidden" using that method.
B. JAWS, in more recent versions of FF, at least since FF5 it would appear, causes the text "hidden" using the positive text indent to get displayed when the screen reader reads it. That is, the text is invisible at first, and then, when navigating to it using keyboard, or when reading through the page, it all of a sudden gets displayed (within the box, so is cut off) on top of the red background. This also happens with SAToGo in IE9.

So, is the font crushing method accessible to screen readers? Yes, as long as those screen readers are not Window-Eyes. W-E is known for some wacky bugs. With some additional work, it may be possible to find some kind of workaround. But, if it is possible to confirm that it is a bug, I would personally be inclined to ignore it and that SR: I'm kinda done catering to bugs, esp. with Window-Eyes, that prevent the use of otherwise legitimate and helpful patterns.