Facts and Opinion About Fahrner Image Replacement
by Joe Clark
- Published in: Accessibility, Browsers, CSS |
Development of the Fahrner Image Replacement technique and its analogues is moving faster than the destruction of the Berlin Wall. This article provides some much-needed empirical data on how FIR actually works in screen readers.
Named after Todd Fahrner, apparently invented by C.Z. Robertson, and popularized by Douglas Bowman (see his site for full coding details) and Jeffrey Zeldman’s Designing With Web Standards, FIR is a standards-compliant technique that uses stylesheets and ordinary HTML to provide a visible image, usually consisting of text. The designer specifies, through CSS, that the image will display in most cases; if it should not display for some reason, the underlying structural HTML markup is supposed to take its place.
Using FIR, it becomes possible to nicely typeset headlines and other
design elements while using markup no more complicated than <span> inside
<h1>. The HTML plain text is concealed through a
stylesheet declaration of display: none
(canonically, at least – you could also use
visibility: hidden). The picture of text displays
as a CSS background image.
The advantages here are a nice graphical appearance most of the time
and markup somewhat more elegant than <h1><img
alt=""></h1>, which is pretty much your only
alternative if, say, you want to use a picture of text as a headline.
Because it does not nest an image inside a heading, FIR is at least
superficially better for accessibility.
Screen readers
As explained in a previous story for A List Apart, screen readers are applications that read web pages, and usually anything else on your computer, out loud. They make a computer accessible to a person who is blind or severely visually impaired, and have been used occasionally by people with learning disabilities like dyslexia. They are a form of adaptive technology – software or hardware used to make a computer accessible to a disabled person.
The leading screen readers are:
- IBM Home Page Reader (which limits itself chiefly to web pages, web-based mail, and multimedia players)
- Jaws (Freedom Scientific)
- Window-Eyes (GW Micro)
- OutSpoken (ALVA Access Group; Windows and Macintosh, though the Mac version has been discontinued)
- Emacspeak (freeware for Linux; T.V. Raman)
- SpeakThis (Fonix)
Stylesheet interpretation
In Fahrner Image Replacement, two CSS techniques are in typical use, though only one relates to visual styling. That’s true even though both derive from visual, not auditory, CSS media types.
display: none is our bugbear here. The W3C
specification states:
This value causes an element to generate no boxes in the formatting structure (i.e., the element has no effect on layout). Descendant elements do not generate any boxes either; this behavior cannot be overridden by setting the ‘display’ property on the descendants.
Please note that a display of ‘none’ does not create an invisible box; it creates no box at all.
Hence, display: none really means
manifestation: none or
elimination: total. An item assigned to
display: none expunges itself.
There’s another option that can be used:
visibility: hidden, in which, the spec tells us,
“[t]he generated box is invisible (fully transparent), but
still affects layout.”
The visual distinction, then, is between nonexistence and an empty bounding box. How should screen readers handle these?
User testing with screen readers
I do not know the answer to that question, but, thanks to some user testing, I can now tell you how screen readers do handle them.
I asked various contacts and a few mailing lists (WAI Interest Group, UVIP-Web-Test) to try reading FIR-encoded text with every screen reader they could put their hands on.
The test case was the rather simple intro page for Ten Years Ago in Spy, my
pæan to the now-defunct satirical magazine that Matt
Mullenweg had recently re-coded using CSS
layout and Fahrner Image Replacement. Two images on that page were
marked up with FIR. Previously, I had used ordinary img
elements.
Results
I set up two test pages:
I was able to locate users of three versions of Jaws, plus Window-Eyes, Home Page Reader, and another product, Hal. I was also able to get results for the now-discontinued OutSpoken for Macintosh.
The results are unreassuring.
| Product |
display: none
|
visibility: hidden
|
|---|---|---|
| Hal version 5.20 | Does not read | Reads |
| IBM Home Page Reader 3.02 | Does not read | Does not read |
| Jaws (4.02, 4.50, 5.0 beta) | Reads | Reads |
| OutSpoken 9 | Does not read | Does not read |
| Window-Eyes 4.2 | Does not read | Does not read |
Analysis
It seems clear that any element given a style of
display: none should not be rendered, read, or
manifested at all by any device in any modality. Hal, IBM Home Page
Reader, OutSpoken, and Window-Eyes are behaving properly under this
interpretation, while Jaws is misbehaving.
It seems also that an element styled with
visibility: hidden, because it generates a box with
invisible contents, should not be read by any device whether visual
or not (that is, either a graphical browser or a screen reader). The
sole difference between the two stylesheet declarations is the effect
on the rendered layout, which a browser must obey but a screen reader
could theoretically ignore. (Recall the difference between
display: none, which takes up no space, and
visibility: hidden, which does.)
An exception could be a case where the bounding box styled with
visibility: hidden affects reading order or some
other consideration that is perceptible in a sequential voice
presentation, in which case a screen reader could alter its voice
output in some way. Perhaps some uses of FIR fall into that category.
We could use some test pages to examine that theory.
In any event, it seems that no screen reader should work with Fahrner Image Replacement except in rare cases. The fact that the dominant such program, Jaws, and the smaller-market product Hal actually do understand FIR is an accident we should not rely on for the future.
Improving CSS
A little-known feature of Jaws, Window-Eyes, and Home Page Reader is the ability to synchronize voice output with either onscreen display (scrolling the screen and/or highlighting sections as they are read) or Braille or both.
- Window-Eyes release notes call it a “surfing with sighted friends” feature.
- IBM Home Page Reader “is synchronized with a moving cursor to make reading even easier.”
- Jaws and Window-Eyes can both produce Braille instead of or concurrent with voice.
Thus, screen readers in widespread use are multimodal devices.
They are clearly at odds with the current CSS media-type definitions because their
behaviour is multimodal, for which the existing screen,
aural, and braille media types are not really suited.
Perhaps it’s time for a new media type that screen readers in
actual use today could comply with – one that gives clear
guidance on how a system that displays, talks, and produces Braille
should handle real-world style definitions.
I suggest here that the World Wide Web Consortium fail to repeat its
mistake with embed, a widely-used and still-supported
element that was never made legal in the (X)HTML spec. The multimodal
behaviour of current screen readers should be explicitly legal
according to the CSS spec even if that requires adding to it.
That wouldn’t require overturning the existing spec, which already says, “Media types are mutually exclusive in the sense that a user agent can only support one media type when rendering a document. However, user agents may have different modes which support different media types.” It doesn’t look like a tough job to expand these definitions to provide for multimodal output.
With a media type that relates to the way screen readers in wide use actually behave, we’d have a stronger basis from which to insist that screen-reader manufacturers comply with stylesheet specifications. A full discussion of that would, of course, require a separate article.
Not an accessible technique
Unfortunately, Fahrner Image Replacement cannot be said to be an accessible web technique when used for text. Screen-reader users either already cannot read any text marked up that way or will not be able to in the future when the software is updated to interpret CSS correctly. Other people with disabilities will probably never be adversely affected by its use, and many will benefit the way nondisabled people do, since a lot of disabled people online have normal vision and enjoy attractive websites. But we cannot exclude screen-reader users from a conception of accessibility.
For that reason, standards-compliant designers should use FIR only for images that could be called “nonsemantic,” that is, not meaningful. Background patterns might be one example, or a company logo that is reproduced in plain text (possibly as a heading) somewhere nearby. Use your common sense.
Help for developers
This case of a standards-compliant technique, advanced by the most sophisticated developers, that nonetheless hits an iceberg and sinks when it comes to accessibility at least has the benefit of highlighting a few deficiencies that need to be remedied. In particular:
- Developers need access to inexpensive,
full-featured, uncrippled versions of screen readers for
independent testing.
- We shouldn’t have to ask people to take time out of their day to test our pages for us, as I did here.
- Developers need to be able to research for themselves whether or not their compliant techniques that look good on paper actually work in practice.
- The permutations involved in testing only FIR are staggering – Bob Easton’s proposed test suite has seven variations that would have to be tested in at least the top three screen readers.
- For formalized study, a greater number of screen-reader users should be identified to do field testing. The UVIP-Web-Test mailing list is a good start. But even the mighty Nielsen Norman Group had trouble assembling enough disabled subjects for usability testing (PDF). Even with tens of thousands of screen-reader users (Jaws alone has 80,000 users), arranging any kind of testing is unduly difficult.
- However, it’s a two-way street: Screen-reader and browser makers need to test their products on the most advanced standards-compliant sites, which are not difficult to find if you read the right sites and weblogs, many of which themselves exemplify the techniques and are a sufficient proving ground.
- A petition is currently making the rounds to lobby Freedom Scientific to release an inexpensive developer version of Jaws. No similar petition appears to be directed at other manufacturers, which isn’t really fair, but Jaws is the most-widely-used product, so focusing on it makes sense politically. {Ed. – the petition has since gone offline.}
- It’s argued, quite reasonably, that 30- or 40-minute demo versions of screen readers don’t run long enough for a developer to become fluent with the software. At press time, however, Jaws for Windows 5.0 was available in public beta for free.
- With licensed, affordable, legit versions on their own machines, developers can put in the time necessary to learn the intricacies of screen-reader usage, putting their experimental and production sites to the test.
- Meanwhile, screen-reader manufacturers have to get with the program themselves. They urgently need greater participation in the CSS working group, and in turn, CSS WG members need to provide much better media-specific guidelines based on real usage of screen readers and adaptive technology. Standards-compliant developers are trying to make everything function well; screen-reader manufacturers and the W3C have to work harder.
Acknowledgements
- Brandon Bowersox
- Douglas Bowman
- Rich Caloggero
- Tomas Caspers
- Antonio Cavedoni
- Tantek Çelik
- Tom Croucher
- Bob Easton
- Todd Fahrner
- Chris Hofstader
- Michael L. Johnson
- Andrew Kirkpatrick
- Eric Meyer
- Will Pearson
- Seth Rothberg
- Dave Shea
- Aaron Smith
- Jim Thatcher
- Léonie Watson
- Translations
- German (byteshift.de)
Learn More
Related Topics: Accessibility, Browsers, CSS
Discuss
Was it good for you, too? Join the discussion »
About the Author
Toronto journalist, author, and accessibility consultant Joe Clark wrote the book Building Accessible Websites, but assumes readers of A List Apart know that by now.
