Re: Possible problem with Fahrner Image Replacement

One of my solutions for this problem (which I now realize is 
impossible), is to use transparently colored text on top of the 
background image.  What I had *hoped* was that the text could sit 
nicely on top of such a background image, not be detectable by the 
eyes, but when a screen reader or text-only browser got ahold of the 
page, it would undoubtably see the text.

However, transparently colored text provides a problem for the user-
agent and the way the operating system would render such text.  If the 
user cannot see the text because its completely transparent, there is 
no such way for them to select the text (if you cannot see it, is it 
even there?).

The same holds true for the Terminal application in Mac OS X.  If you 
make the transparency of the window something close to 100% (fully 
transparent), then the operating system gets confused when you click 
"inside" that window... it thinks that because its totally transparent, 
your mouse clicks should go right through that UI element and hit 
whatever is behind it (whether it be the Finder, or another window, 
etc.).

In my non-exhaustive testing, if you set the color of text to 
transparent, the browser usually renders the color as the "default 
color" for that type of text.

Interesting idea/solution... any thoughts?

-Mike

> 
> At 10:26 PM 7/14/2003 -0400, Joe Clark wrote:
> 
>> Fahrner Image Replacement, named after Todd Fahrner (but apparently 
>> invented by C.Z. Robertson), is a standards-compliant technique that 
>> uses stylesheets to provide a visible image, usually of nicely-
>> typeset words, that is backed up by marked-up plain text. All the 
>> hip kids are using it.
>> 
>> <http://www.stopdesign.com/articles/css/replace-text/>
>> <http://rtnl.org.uk/words/19990709-site_updates.shtml>
>> <http://lists.w3.org/Archives/Public/w3c-wai-ig/2003JanMar/0870.html>
>> 
>> Back in March, I had people try FIR in Window-Eyes and Home Page 
>> Reader, and two of the test pages at 
>> <http://www.stopdesign.com/log/default.asp?date=20030314> read 
>> correctly. I suppose it is a problem that all three did not.
>> 
>> There is, however, the problem that screen readers are yoked to 
>> visual browsers and inherit their stylesheet interpretations. 
>> {display: none} really means {display: none}, and the treatment of 
>> visibility: hidden is unclear.
>> 
>> The result?
>> 
>> One correspondent, using HPR on his machine, says that text marked 
>> up as FIR disappears completely because it isn't an img element with 
>> alt; also, {display: none} takes it out of the reading order 
>> altogether.
>> 
>> You can test this on my new, all-CSS page for Ten Years Ago in 
>> _Spy_, fixed up by Matt Mullenweg:
>> 
>> <http://www.fawny.org/spy/?FIR>
>> <http://photomatt.net/p722>
>> 
>> WHAT I NEED:
>> I need people to throw every screen reader they've got at that 
>> simple page <http://www.fawny.org/spy/?FIR> and see if you can read 
>> the text embedded in graphics. There are two separate blocks, and 
>> I'm not gonna tell you what they say-- the purpose is to see if you 
>> can read them.
>> 
>> Use all screen readers you have, *especially Jaws*, though I doubt 
>> anyone from Freedom Scientific would bother looking into this.
>> 
>> Report back to me and I will summarize to the lists.
>> 
>> If this technique is really not working, then the most advanced 
>> standards-compliant sites designed by the most conscientious people 
>> at work today have a serious problem-- one of the problems they were 
>> going very much out of their way to avoid.
>> 
>> --
>> 
>>     Joe Clark | joeclark@joeclark.org
>>     Accessibility <http://joeclark.org/access/>
>>     Author, _Building Accessible Websites_
>>     <http://joeclark.org/book/>
>

Received on Tuesday, 15 July 2003 12:12:28 UTC