Facts and Opinion About Fahrner Image Replacement

by Joe Clark

44 Reader Comments

Back to the Article
  1. What if the user has images turned off and views a page with FIR? Unfortunately that user views nothing more than white space.  Stuart Langridge has featured his own FIR called “A new image replacement technique.”  Instead of abolishing the text with display:none, we can just use an empty <span> tag to place an image over the text.  Although this adds a small markup, this method allows users with CSS on and images off to read the text. To get to my point, wouldn’t this method work in all the screen readers?  I would think so because the text is always there.
    Copy & paste the code below to embed this comment.
  2. I was surprised not to see any mention of the Leahy / Langridge hack, which has been public for a while now (there was even a link from Jeffrey’s web site…) Testing this one would have been interesting, as it seems to fail only in the “CSS but not images” scenario. Just in case: This alternative technique consists in pushing the text down with a padding as high as the image, and hide the characters using the overflow property. More at:
    http://www.moronicbajebus.com/playground/cssplay/image-replacement/
    http://www.kryogenix.org/code/browser/lir/ Anyway, congratulations for the redesign. It looks cleaner. And it validates, apparently ;-)
    Copy & paste the code below to embed this comment.
  3. Great article! I just posted the below message to Douglas Bowman/stopdesign:
    ———-
    Thanks for a helpful article. My concern is not only with screen readers, but also search engines. As you might or might not know, title tags are vital to search engine indexing. I’m designing and building web solutions based on my own CMS, and i work closely with a colleague whose focus is on SEO (search engine optimization). SEO is not my trade, so I don’t know how i.e. Google works, but I can’t risk the title not being indexed/disregarded because it’s hidden (visibility: none). Any thoughts/experiences on this? Final thought. The Fahrner image replacement technique makes the text unselectable. This could be overcome using a script to swap the image with the text, eventually hide the image if it’s just an overlaying layer.
    Copy & paste the code below to embed this comment.
  4. That’s the beauty of Stuart Langridge’s FIR at Kryogenix.  The text is “always on” and available for screen readers or search engines and visible with images off.  I use his technique on my website.
    Copy & paste the code below to embed this comment.
  5. I am not familiar with aural stylesheets, but conceivably a similar technique could be used to render (play) some sound file instead of the element’s text, using the cue property for example.
    Also, screen-readers might need to have speak:normal in addition to display:none to selectively read a FIR’d element.
    Copy & paste the code below to embed this comment.
  6. The article went through many betas in the summer, and then I left it in J the Z’s hands for the ALA relaunch. There’s been as much development on FIR since I wrote the piece as there had been immediately before, as the first graf states.
    Copy & paste the code below to embed this comment.
  7. Hi, Sitepoint has an article that appears to solve the accessibility issue. I haven’t implemented the technique myself but it seems to be sound:
    http://www.sitepoint.com/article/1221/1 Thanks,
    Terry
    Copy & paste the code below to embed this comment.
  8. Your article doesn’t mention the differences between imported and linked stylesheet for the screen-reader. It seems to matter.
    Anyway, the problem of screen reader is already solved by the Leahy / Langridge hack. Even better if we use negative text-indent instead of padding. Another way of addressing the problem, working only with flat color images, is to use font-size: 1px, eventually with negative letter-spacing, and same font-color than the background color of the image.
    Just one problem remains: css on + image off. But is this really an accessibility problem? I’m not sure. Bye!
    Copy & paste the code below to embed this comment.
  9. I use FIR sporadically throughout our site. Due to the fact that the machines here running ie 5.0 also are usually set to 480x600, the desired effect tends to fail. So I’ve implemented the Tantek hack. Wouldn’t this also suffice for screen readers? Thanks for the article, Andy
    Copy & paste the code below to embed this comment.
  10. Sadly the public beta expires on the 30th October 2003 and is only time unlimited for current registered users.
    Copy & paste the code below to embed this comment.
  11. One notion I haven’t seen mention of is what happens when you run a web page through a translator, such as Babelfish?  The text does get translated, but of course the images stay the same.  So when you use FIR and display a translated page, you don’t get the translated headers—but the translation is there!  It would be nice to have a way of getting the text version to show up in the form of a tooltip, or use some other device to force the text version that is replaced by the graphic to show up, so the page can be understood.
    Copy & paste the code below to embed this comment.
  12. ...can be solved by the (http://levin.grundeis.net/files/20030809/alternatefir.html) Levin Alexander modification, that brings back the empty span tag, and requires a non-transparent image, because it’s layered over the text. Still, I used it on http://www.sha.hu/ (with slight modifications), and will use on others, because it’s unacceptable to me that for a given case (images turned off) everything disappears with the other methods.
    Copy & paste the code below to embed this comment.
  13. I’m sure you’re aware of these, but ALA is missing: 1. A “Remember me” box for all this info.
    2. A “Print” style-sheet.
    3. It would be nice to see something like SmartPants (http://daringfireball.net/projects/smartypants/) to tidy up all these posts. ;) That is all. Keep up the good work!
    Copy & paste the code below to embed this comment.
  14. I feel honored that the Sitepoint article (mentioned in an earlier comment) discusses the method that I use and popularized.  The author did a great job talking about both the up and downsides to it. Made For All (www.madeforall.com) will soon be coming out with Issue 5 which includes my take on image replacement. Joe — I’m glad you referenced C. Z. in your article as the “originator” for the image replacement code.  I spoke with him after the late-summer hoopla regarding image replacement, and he was surprised that I actually took the time to figure out he was the first. As for the holy-grail of image replacement — complately semantic, totally accessible, and usable for those with images turned off — I don’t believe it has been developed yet.  CSS implementation on the world’s most popular browser will forever limit us, and until CSS3 content rules work in IE, the holy grail will stay hidden.
    Copy & paste the code below to embed this comment.
  15. Correct me if I’m mistaken, but isn’t a screen reader, in difference from an aural rendering engine, supposed to represent what is displayed on screen? An aural rendering engine would try to render the page in aural media, and naturally also handle aural stylesheets and not be affected by screen stylesheets, but shouldn’t a screen reader just try to represent the visual data in aural format? Thus, an image might be represented by it’s alternative text which is made for medias where it can’t be displayed, but the stylesheets for screen should still apply.
    Copy & paste the code below to embed this comment.
  16. Is a screen reader an aural device, yes?! then it should work with aural stylesheets but it does not. If it did then we could style it with one style for screen readers (aural) and one for browsers (screen). Great article Joe. The FIR technique is a great study to make us think. W3 and screen readers please get together before the next recommendation. W3 we may really need multimodal devices but what if the style sheets conflict in implementation? Keep it simple - keep it seperate I rekon. But to be sure we need user testing. This needs scientific research - maybe a university could start. Testing, testing, one, two, three, come in, over.
    Copy & paste the code below to embed this comment.
  17. This css hack could lead a search engin to consider your document as hidden keyword Spamdexing. Accessibility appart, i really think it’s a bad usage of css : - First, it sounds like a repetition of the alt or longdesc well know alt’s img attributes combined with a css. - Second, sometimes you have to break words in part, wich mean nothing or bring noise in your speech, goat and boat could be a good sample of nonsens (in cas of first-letter). - Third, you have to double tag and by the way bring weight for nothing. In conclusion, accessibility, search engine misinterpretation, repetition, noise and weight don’t make me think this is a usable css hacks, but let me ask another question… What about svg ?
    Copy & paste the code below to embed this comment.
  18. A method i have been using is to shrink the text down to a pixel and colour it the same as the image (a CSS background). Of course this will only work with certain images and non I.E browsers can resize the text. I have used this method on my department’s intranet—“standardized” to I.E. with a few rogue Mac users (me included), so it is a bit of a controlled system.
    The upside of this is the text is not hidden but just teeny-tiny so it *should* still be read by a screen reader.
    Anyway, it is at least another trick in the bag.
    Copy & paste the code below to embed this comment.
  19. FIR, FEAR, FIRE… | by Boris Meyer
    >This css hack could lead a search engine to consider your document
    >as hidden keyword Spamdexing. This might be true once SE spiders interpret css,
    then it would apply to any other css technique hiding text as well,
    making most of css driven nav systems or pure fancy effects spamdexing. I don’t think SEs could afford to cripple designer’s css options to that extend;
    punishing font coloured the same as the containing element’s background in ye olden times
    didn’t harm designer’s choices as this method hasn’t any conceivable benefit regarding
    layout and design. (except for very sloppy and inept coders) Instead, a more sensible approach would be to simply ignore hidden text for indexing;
    in fact most of spamdexing nowadays doesn’t relay on hiding text but of link farms whose
    visible text qualifies as spam because of it’s semantics.
    (or lack thereof to human readers,
    spammers don’t care much about that, it’s not meant to be read by humans) Concluding,
    hunting for spamdexing will force SE’s to rely on semantic analysis,
    hiding text by css (or script) should be harmless in times to come,
    as for now, I haven’t heard of css parsing bots. An -hopefully- educated guess,
    Marek Moehling
    Copy & paste the code below to embed this comment.
  20. Ok, Ok, Ok… no line breaks in paragraphs next time
    MM
    Copy & paste the code below to embed this comment.
  21. Very insightful article, and kudos for using actual screen readers to research accessibility principles. I have one, minor, philosophical difference with the article: >> Hence, display: none really means manifestation: none or elimination: total. An item assigned to display: none expunges itself. I’m not sure about this interpretation.  “Display” certainly seems to imply a visual issue, especially since the other options are “block,” “inline,” and “list-item.”  If “display: none” means screen readers should ignore it because it has expunged itself, how does that interpretation of “display” square with the other options? The only reason I bring this up is because there is a difference between stating what screen readers actually do and what screen readers *should* do.  I’m not sure I’m convinced that screen readers *should* ignore a display:none.
    Copy & paste the code below to embed this comment.
  22. I’ve always intepreted display:none as “don’t render me visually at all”.  It would be nice if screen readers conveyed the document structure, like a text browser, as opposed to what the user agent renders.  But then, it wouldn’t be a “screen” reader.
    Copy & paste the code below to embed this comment.
  23. FIR, FEAR, FIRE… | by Boris Meyer
    >This css hack could lead a search engine to consider your document
    >as hidden keyword Spamdexing. I looked into this issue a while ago and was told that the only real risk here is if one is clearly abusing display: none.  Spiders (AFAIK) don’t parse CSS, so the site in question whould have to be reported to a search engine administrator and an actual human being would have to determine that CSS was being abused to increase a site’s ranking.  It seems doubtful that would happen with FIR.
    Justin
    Copy & paste the code below to embed this comment.
  24. Two variants that I’d been wondering about, that I didn’t see mentioned above.
    1. If you were using this to replace an h1 with a image, what if you duplicated what is in the span in the title of the H1? Do screen readers catch things like that?
    2. What if you put specific media rules in for screen readers that make that span an inline element?
    Copy & paste the code below to embed this comment.
  25. What about making the CSS content property not be restricted to :before and :after pseudo-elements? This was the first thing that occured to me when I saw FIR. #foo { content: url(foo.gif); } <h1 id=“foo”>Foo and Bar</foo> It seems that usage of the content property should replace any content in the markup. Now, we may still have the issue with screen readers that has to be resolved, but at least we get rid of those damned span tags. With that change you could also do something nifty like: img[src] { content: url(att(src)); }
    object[data] { content: url(att(data)); } in the browser’s default stylesheet to make those elements that don’t use XLink render without needing special HTML processing. Caveat: I don’t know if it’s currently legal to nest the att() in a url(). Anyway, I’m just brainstorming. As a side note, a problem with <img alt=”” > is that you can’t mark up the text in the alt attribute (like in my example). Also, technically <img> is deprecated, and if it wasn’t for IE I would have switched to the <object data=“foo.gif”>Foo and Bar</object> long ago.
    Copy & paste the code below to embed this comment.
  26. Problems seem to come from programs like JAWS awkwardly falling somewhere between “screen reader” and “aural web browser”, neither simply reading off the display or working from the markup (and, ideally, aural CSS).
    I can’t see how selectively parsing a few bits of CSS clearly aimed at graphical browsers is helpful or reliable, am I missing something?
    Copy & paste the code below to embed this comment.
  27. You’re definitely right, Greg.  As soon as FIR came out, many people (including Tom Glider) started discussing how pretty much all image replacement techniques are non-semantic hack jobs.  When browser’s widely support the content property, that will be the preferred “weapon of choice”. Mike
    Copy & paste the code below to embed this comment.
  28. Surely the main reason that we’re embarking on such a convoluted series of hacks is misplaced.  If font embedding had matured as a technology, we wouldn’t even need to find ways of supplying GIFs and hidden text as headings. Rather than doing FIR of any sort, why don’t we start using embedded web fonts and therefore provide impetus to getting this better supported as a technology. Embedding fonts + CSS type control was for me the most exciting potential application of CSS back in 1998 - what the heck happened that we all ignore this approach? Just my £0.20 (inflation, you know…) Cheers Ian
    Copy & paste the code below to embed this comment.
  29. Correct me if I’m wrong about how this works.. I don’t think the type foundries would be too happy about us embedding fonts, making them available for everyone to download.
    Copy & paste the code below to embed this comment.
  30. In reply to Justin Peters… >I looked into this issue a while ago and was
    >told that the only real risk here is if one is
    >clearly abusing display: none. So exactly what FIR could lead to… how a search engine could make the difference between ? You could also put text in a div with a tiny-tiny width/height couple, or have the same color of your background… Today those well know spamdexing technics are known from Search Engine… Do you think they won’t find this one ? >Spiders (AFAIK) don’t parse CSS, so the site in
    >question whould have to be reported to a search
    >engine administrator… I don’t think so as css is a language, this can be analysed.
    Copy & paste the code below to embed this comment.
  31. 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.
  32. 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.
  33. 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.
  34. 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.
  35. 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.
  36. 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’.
    [html] H1
      SPAN (text) /SPAN
    /H1
    [css] 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.
  37. How about using display:none to hide the text only when the medium is screen?
    Copy & paste the code below to embed this comment.
  38. 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.
  39. 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.
  40. 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.
  41. 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.
  42. 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.
  43. 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 10x1 or 1x10.
    Copy & paste the code below to embed this comment.
  44. 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.