Facts and Opinion About Fahrner Image Replacement

by Joe Clark

44 Reader Comments

Back to the Article
  1. My biggest question is what is wrong with the alt attribute? It seems like that is what it was specifically designed for, right?

    I can see one drawback in that some screen readers may preface the alt attribute by saying ‘image: (alt text)’.

    As for the screen reader comments, I agree that the screen reader’s job is to read the screen. Jaws, for instance, is an OS-level screen reader. Not an aural web browser.

    As for font embedding, that never took off, and probably never will. Type foundries can be a bit paranoid (take a look at some of the font embedding restrictions with PDFs).

    Copy & paste the code below to embed this comment.
  2. Nothing is wrong with alt, but <h1> tag has much more importance for a SE’s spider… and with normal html you can even format that text separating from the main title, the subtitle (<h2>) etc.

    However i agree with Phil Ledgerwood, I really think that screen readers should not consider css at all… (i mean visual css offcourse).

    Not parsing visual css at all i think cannot lead to problems, if they just are visual element, how can a blind user need’em?

    Copy & paste the code below to embed this comment.
  3. And about font embedding I agree that Type foundries would not be happy of this, but I think problem would even be another too… why should I download a font (sometimes they are quite heavy) just to see some text? Even embedding just used chars (as you can do with flash) I don’t think this two problems could be solved.

    I think a more limited but lighter solution would be very easy: implementing the ability of use antialias on text alone, would be enough to avoid 90% of text images, then combinig it with a stroke effect, a pattern fill effect (to place a backdrop inside a big text) and a couple of other such as dropshadow or glow, would really low the need for images.

    I think all this effects are quite easy to implement and not so heavy for the CPU, and offcourse for the bandwidth -coz most of them are procedural. Even without embedding fonts, but just using standard font with this effects applied, designers possibilities would raise a lot.

    Byez [and sorry for bad english]

    Copy & paste the code below to embed this comment.
  4. I have a suggestion for solving the problem in a very easy way. It should work for screen readers, images turned off and seo:

    <h1 class=“img”><img…>Header Text</h1>

    img { display: block; }
    h1 { height: [height of image]; overflow: hidden; }

    what do you think about this?

    Copy & paste the code below to embed this comment.
  5. Nice, but…
    making so you have got picture and text… the picture in in the html, but it’s better to have the picture just as backdrop image, because it’s a non-structural element, but just a graphical one

    instead of this put pic just as h1 background and not in html, and to h1 say also

    padding-top: 100%;
    overflow: hidden;

    as explained some post before

    Copy & paste the code below to embed this comment.
  6. I think, the feature ‘z-index’ makes pages with image-replacement more accessible than hidden visibility or ‘display: none’.

    The only problem is: what if a user enlarges the text under (!) the image. Than you can set the text smaller, or set the box of ‘span’ to ‘overflow: scroll’.


      SPAN (text) /SPAN


    h1 {
      background-image: url(’/pic/h1.gif’);
    h1 span {
      z-index: -1;

    But, I prefer the tag ‘image’ with the alt.

    Copy & paste the code below to embed this comment.
  7. How about using display:none to hide the text only when the medium is screen?

    Copy & paste the code below to embed this comment.
  8. I wonder if we can make the method accessible.

    Let see.

    instead of using visibility: none;

    why not making a height and width equals to 0px.
    I’m pretty sure, it will generate other issues. but at least it’s accessible to screen readers.


    Copy & paste the code below to embed this comment.
  9. But I thought the whole point of this technique was that it enabled you to create different stylesheets for the same content, one (for normal browsers) which shows the image and not the text, and one (for old browsers and screen readers) which shows the text but no image. The correct stylesheet could be selected using client-side or server-side user agent detection, or just using media types in the case of the screen reader.

    In the light of this surely worrying about screenreaders not reading out the hidden text is a bit pointless since you would provide an audio stylesheet which didnt hide the text? or am I missing something else?

    Copy & paste the code below to embed this comment.
  10. Using text-indent. Setting it to a ridiculously high negative value (like text-indent: -100000) would prevent the text from ever displaying in a Visual Browser. But it’s still there. And the image is there.

    However the issue of displaying the image when images are turned off in web browser and showing text, still applies. Haven’t really tried this technique out full-scale, so I don’t about browser compatability or being valid.

    Maybe someone can shed a light on it?

    Copy & paste the code below to embed this comment.
  11. FIR is just a hack to make our CSS “pure” by seperating images (which are style) from our content, while still making the content of the image (usually text) available to people using screenreaders. Lame, ugly, and a hassle – all for the sake of fickle “purity”.

    CSS 3 is more capable of seperating eye-candy images from content, so I intend to use old-fashioned <img> tags until CSS3 is widely supported.

    Copy & paste the code below to embed this comment.
  12. Just an aside…

    While all this discuss on FIR is very interesting and useful, the biggest issue I can see with FIR is a purely design one: images are not fluid in size like text is.

    The image is going to stay the same size when you resize the text using the browser’s text size (unless some doofus has used pixel font sizes in IE) so the beautiful design work which required FIR in the first place is going to break down the moment a user wants to view bigger/smaller text.

    Purely based on that I’m going to stick with text for text ;)

    Copy & paste the code below to embed this comment.
  13. There may well be a lot of issues which reveal themselves after testing on screen readers.  For example, at least one release of Jaws 4 does not read the contents of the alt attribute if a graphich is smaller than 10×1 or 1×10.

    Copy & paste the code below to embed this comment.
  14. To clarify, the non-reading of the alt attribute on small graphics was an intentional feature of that release of Jaws 4.  Since I don’t have access to Jaws 5, I don’t know whether it is still a feature.

    (As to why someone would do this, we use small transparent graphics with alt attributes to provide instructions to be read by screen readers, but which are not visible to sighted users, such as “skip navigation” or “content begins here”.)

    It is also not sufficient to ask someone to test a page in their screen reader using their settings.  Jaws (and possibly other screen readers) offers a choice of modes for reading the page, at least two (one is called Virtual Cursor Mode).  The different modes may give different results for specific coding techniques.  So this actually multiplies the number of tests one must do.

    Copy & paste the code below to embed this comment.