If anyone read the CSS tutorial I wrote last week involving use of the background-image property, they should be aware of an apparent critical flaw in the method as it’s currently described. It’s hard to tell whether the flaw is in the method itself, or simply in the way screen readers verbalize text of a page. A footnote added to the bottom of the tutorial tonight reads as follows:
1 Note: An apparent critical flaw with this method involves screen readers, such as JAWS, which allow the browser to render the page with screen media styles applied. JAWS “reads” the screen as it is seen in the browser. Since we’ve hidden the contained text using
display:none, it also gets hidden from JAWS. This is further complicated by the fact this method includes noalttext to read in its place. Thus, we need to assume text treated with this method will not get read aloud in JAWS, and possibly other screen readers. As is true with any content-altering technique, the advantages and disadvantages of this method should be carefully considered for each unique case before it is implemented. At the time of this update, alternative methods are being investigated and tested.
In my opinion, the fact that JAWS — and other screen readers — falls victim to a display property does not invalidate this method. But it does present a very unfortunate glitch in a method which is supposed to enhance accessibility, rather than subtract from it in this instance. Screen readers should allow the speak property (applied via an aural stylesheet) to offset any display value. But aural stylesheets and properties are not widely supported, especially in JAWS — the most widely used screen reader.
Several readers have pointed out an alternate method documented on pixy.cz, which uses the z-index property of an absolute-positioned element to place the background-image on top of the original text. It seems to work well in the example shown on that page. But the flaw here is that the raw text underneath the image can easily “peek out” from behind the image when text is resized via browser controls, or when heading text happens to be large and/or long enough to extend beyond the image boundaries. See screenshot [.gif, 4.2 KB]
I’m testing several alternative methods based on variations and hybrids of my original approach and the one documented on pixy.cz. Two of the new examples are likely candidates: Example 1.2 uses a simple negative z-index value to push the inner element behind the outer element. (This method fails in Opera 6 and lower.) Example 1.3 uses a slight variation of the pixy.cz approach, but would still fail to keep text completely hidden in certain instances.
If anyone has an installed copy of one of the popular screen readers, I’d very much appreciate a quick test of the two examples above, compared with the original Example 1 from the tutorial. Do any of those three examples allow the original text to be read aloud? Send any reports my way.
Side note: I don’t understand why Freedom Scientific, maker of JAWS, doesn’t provide a free (or at least drastically reduced cost) developer version of their screen reader software. The US$895 for the full un-timed version is way too prohibitive for most of us to acquire a copy to be used only for testing purposes. How else are we, as designers and developers, supposed to test and improve site performance in these screen readers? Theory of how it works — or is supposed to work — can only go so far.