A List Apart


Facts and Opinion About Fahrner Image Replacement

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.

Article Continues Below

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 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>

, 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:

  1. IBM Home Page Reader (which limits itself chiefly to web pages, web-based mail, and multimedia players)
  2. Jaws (Freedom Scientific)
  3. Window-Eyes (GW Micro)
  4. OutSpoken (ALVA Access Group; Windows and Macintosh, though the Mac version has been discontinued)
  5. Emacspeak (freeware for Linux; T.V. Raman)
  6. 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.


I set up two test pages:

  1. Using display: none
  2. Using visibility: hidden

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.


   display: none

   visibility: hidden

   Hal version 5.20

   Does not read


   IBM Home Page Reader 3.02

   Does not read

   Does not read

   Jaws (4.02, 4.50, 5.0 beta)



   OutSpoken 9

   Does not read

   Does not read

   Window-Eyes 4.2

   Does not read

   Does not read


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:


  • 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

44 Reader Comments

Load Comments