Quiz 1.1.4: Image Replacement Techniques
Just over two years ago Todd Fahrner, and others, showed us how to have well structured text headings (h1 through h6) and fine looking heading images as well. Standards based structure and good looks too; who could ask for more?
Well, we could. Joe Clark quickly told us the original FIR technique lacked any sort of accessibility features.
Many other techniques since then have done better. How good are they?
This quiz asks about four techniques. Three of them are described in Dave Shea’s excellent collection, Lehy / Langridge, Phark, and Gilder / Levin. The fourth is the newly announced version 2 of the scalable Inman Flash Image Replacement technique.
As we look at each of these techniques, I want to ask accessibility questions that go beyond the need for a text alternative that can be spoken by a screen reader. Text alternatives don’t solve all accessibility problems. What happens if these headings have links within them? Will the link display the expected hover and visited effects? Will the link indicate an active border when tabbed to? Will the link even work at all?
Try a test case to see how each technique behaves. Every heading is a link to another page on this site.
Q.Which of the techniques has the best accessibility features? Screen reader tests of the test case are certainly welcome.
- A Lehy / Langridge uses overflow : hidden to hide text. Are you ready for a surprise? Try tabbing to it in the test case.
- B Phark uses a very popular negative text indent method. It is modified here from em units to px units to avoid problems in Safari.
- C Gilder / Levin has the image simply overlaying the text. OK, except for images with transparent backgrounds.
- D The scalable Inman Flash Image Replacement technique generates a Flash image on the fly, and uses overflow : hidden to hide text.
May 8th, 2005 at 1:58 pm
Apple VoiceOver + Safari 2.0:
All headings are announced, and the links for A-C can be activated by pressing Ctrl-Option-Space bar. The sIFR link can only be activated by pressing Return, and after announcing the sIFR heading, VoiceOver skips out of the viewport, announces the window title, and stops with the cursor on the Back button. Oops.
Safari 1.3 and 2.0:
Only the sIFR heading is clickable. No feedback is given when you hover over the others. All links can be activated by tabbing to them and pressing Return, but only the link in C is outlined, so there is no way to tell if the others have focus.
Not sure which of these techniques actually is the most accessible. I’d avoid sIFR though, mainly for aesthetic reasons. It is cool and all, but I find the flashing as the page loads very annoying.
May 8th, 2005 at 2:32 pm
Opera 8:
Using spatial navigation, accessing the Phark Image Replacement and sIFR is impossible using regular spatial navigation.
Using previous/next element navigation (S and W keys) - which is different from navigating links - I am able to get an outline around the sIFR example, but unlike any of the other methods, I can’t actually activate the link.
Using previous/next link (Q and A keys), I can access all of the links, but I am, totally unable to see what I’m accessing.
Voice works in exactly the same way: The links I can access are read out loud, the ones I can’t access are silent.
May 8th, 2005 at 6:00 pm
“Well-structured text headings” that are h1-h6? How else can you have well-structured text headings?
Perhaps I just don’t understand the debate here. None of the examples make sense, and for me (Firefox on Tiger) only the fourth image is clickable.
An image cannot be a heading, and a heading cannot be an image. Period. There’s a reason that images are not allowed inside elements. Because headings are text, and images are images. Images can represent text, but they cannot BE text, and elements can only contain text — philosophically if not technologically.
If you have a heading, and you don’t want to display the text for it on the screen, but you want an image of it, use an element, set the display properties of the text such that it won’t display on visual user agents, but will be exposed on non-visual user agents (as you discussed in a previous column), and then follow it by an image.
Grumpy’s Dog Food
You could, theoretically, put an alt attribute in the image element as well, but it seems to me that it would be redundant to do so.
May 8th, 2005 at 6:07 pm
I guess code gets eaten by your blog. The example was:
<div id=”h_1″>
<h1 style=”visibility : hidden ; “>Grumpy’s Dog Food</h1>
<img src=”grumpys_dog_food_header.jpg” alt=”" />
</div>
And if that doesn’t work, just delete my comments and I give up. :-)
May 9th, 2005 at 5:19 am
“An image cannot be a heading, and a heading cannot be an image. Period. There’s a reason that images are not allowed inside elements.”
Nonsense. It’s perfectly valid to have an image within an element, and if you have something like <h1><img src=”blah” alt=”blah” /></h1> then modern browsers will display the alt text with the appropriate size and weight of the h1 header.
Also, using visibility: hidden will still preserve the space taken up by the h1 text, including all margins and padding. display: none will remove it entirely from the document flow but then you run into the problem of screen readers obeying display: none as well.
May 9th, 2005 at 5:25 am
For the record, we (the sIFR folks) don’t advice sIFR being used for links. There are some usability problems with links in Flash, in comparison to normal browser links.
As for VoiceOver, that sounds an awful lot like a bug in that application. I assume it reads the alternate text in the HTML, and not the Flash (reading the Flash is kinda impossible, right?), so why it stops after reading it I don’t understand.
May 10th, 2005 at 8:02 pm
The main reason for css-image-replacement for semantic elements (e.g. headings etc.) was SEO. Google wasn´t indexing ALT atributes in cases when the images were not links. So when I had relevant keywords in H1 tag and wanted Google to index it, I had to write them as plaintext and use some css-replacement method.
Nowadays Google indexes ALT atributes even though the images are not links.
So my question is: Is it still necessary to use methods of css-image-replacement for text content and not to include IMG tag into H1 tag?
May 10th, 2005 at 9:23 pm
David asks:
In short, YES!
Image replacement was originally for aesthetic purposes, not for SEO. As designers and developers were persuaded to use valid structural markup (some say semantic), many were not pleased with the poor results of large scale fonts with no anti-aliasing and poor kerning. Remember, this is why so many used images for headings in the early years. How can we have good markup and attractive headlines too? Todd Fahrner, a highly regarded W3C member, led the way.
The reasoning is this: Use solid, clean, uncluttered structural markup. Then, put the presentational effects in CSS. Don’t clutter up the HTML with (redundant) images if you can use CSS to display those images instead.
The benefit for SEO purposes wasn’t because of image replacement, but because of well structured HTML markup.
The aesthetic need for attractive headings has not changed. I’m sure the techniques will be around for a long time. So, how do we make then as accessible as possible?
May 11th, 2005 at 6:48 am
A few weeks ago I wrote an article (sorry, only in German) about Image Replacement Techniques and how they are related to accessibility. One example I missed is “Definitive Solution to Image Replacement” (DS2IR) by Anatoly Papirovsky, probably the only solution that works with screenreaders, text-only-browsers and graphical browsers with images turned off.
If I turn off images, only Gilder / Levin Image Replacement keeps working. But only as long as I do not resize the page. In addition I have to mess with the code using and / or classes.
May 19th, 2005 at 5:22 am
Using Jaws 5 on IE6, all worked fine.
I use Phark myself, but that’s just choice.
July 4th, 2005 at 7:30 pm
If you want hover states for the <hx> tags, why don’t you image replace the links rather than the headings?
Something like:
/* for Phark - my preferred image replacement */
#pir {
font-size: 8px; /* for IE/Win */
width: 305px;
height: 35px;
margin: 0;
}
#pir a {
display: block;
width: 305px;
height: 35px;
text-indent: -5000px;
background: url("http://access-matters.com/images/pir.gif") no-repeat;
}
#pir a:hover {
background: url("http://access-matters.com/images/glir-hover.gif") no-repeat;
/* no PIR hover image??? */
}
#pir a:active {
background: url("http://access-matters.com/images/glir-active.gif") no-repeat;
/* no PIR active image??? */
}
July 4th, 2005 at 7:33 pm
Follow up: you can’t use my code “as is”, because you need to remove the underline effect on anchor tags. Otherwise in Firefox you get an underline heading straight off the page, presumably for about 5000px. :P
August 18th, 2005 at 8:14 am
Thierry Image (re)Placement is another technique which appears to resolve all accessibility problems. It uses a spacer IMG coded in the heading as a flexible window to cover the actual heading text. A background image can then be used as with other techniques for the more appealing image. It looks like Thierry has solved all of the problems with images on/off, css on/off, js on/off, and screen reader accessibility too. — a fine article by Thierry Koblentz.
September 1st, 2005 at 8:22 am
Thierry Image (re)Placement is basically the same text covering technique (Gilder, Levin, et. al.) using an IMG instead of an empty EM or SPAN (If it saves from so having to do so many bug fixes for older browsers, I guess it’s OK).
What’s novel is the height in EMs (allowing expanding of the header area depending on text-size), but you could do this in any of the other methods, and it seems more of a cover-up for IE/mac’s inability to do overflow:hidden than a feature because the background image isn’t going to scale.
September 1st, 2005 at 8:30 am
I should also mention the test page has incorrect markup for the linked version of Gilder/Levin. The SPAN should be the first element inside the anchor. The CSS then may have to be nudged because Gilder/Levin never made linked versions, but Michael Ryznar did (same link as last comment).
September 6th, 2005 at 1:01 am
Following Stephen’s comments.
The method (TIP):
- doesn’t require any hack to work in all browsers,
- gives access to some attributes (alt, title, etc.)
- can make the image scale [1],
- allows the image to be printed [1].
[1] http://www.tjkdesign.com/articles/tip_5.asp
Same technique, different implementation. No meaningless element in the markup…
September 7th, 2005 at 11:46 pm
I do like that TIP doesn’t require hacks. I worked on a JS-assisted IR technique based on Gilder/Levin/et.al., but using TIP might be a lot simpler (and prove more reliable).
The problem with [1] (mentioned above) is that you can’t change the image w/o changing the markup, so you’ve lost the separation of style from content, which is the main goal of IR. In that, TIP example 5 is really a completely different technique.
What I’d be interested to know is how reliable an image can be sized in relative units so that the default font-size in most browsers would yield the original size of the image. Since the CSS2 browsers can resize px values, the problem remaining is IE/win; the IE user can’t scale text with a font-size in px (without a font style switcher) but you can’t reliably use only relative units due to DPI scaling and the like. Maybe I’ll set up a test page…
September 8th, 2005 at 1:21 am
Stephen,
I don’t really agree about losing separation of style from content.
With method [1], it is easy to set the
srcvalue of the image elements through SS-Scripting, so the content layer is not bound to a particular set of images.Actually, this has some advantages over CSS or Javascript solutions since it does not rely on the user’s settings.
Regarding scaling, I agree that it is somehow limited, but my point was just to show how versatile this method was.
May 4th, 2006 at 10:44 pm
Can any of these image replacement techniques (negative indents, etc.) potentially be viewed as keyword spamming, resulting in a site being penalized or even dropped by search engines?
May 6th, 2006 at 3:54 pm
David,
As far as we know, no search engine yet parses CSS. So, there’s no current penalty for these techniques. I’m also confident that when someone like Google does start taking CSS into account, if they go that far, they will consider how it combines with the HTML. These combinations will rank very low on their “spam probability” scale.
September 3rd, 2006 at 9:53 pm
All these other Typography methods fail to do what SIFr does so well.
Which is that SIRf swf’s can be highlighted with ur cursor and copied as Text into a text document.
How can you highlight an image hey?
September 3rd, 2006 at 10:46 pm
which i just noticed does not work on ur exampel page.
You have obviously implemented in wrongly
July 8th, 2007 at 4:26 pm
Using Jaws 5 on IE6, all worked fine.
February 21st, 2009 at 6:54 pm
An image cannot be a heading, and a heading cannot be an image. Period. There’s a reason that images are not allowed inside elements. Because headings are text, and images are images. Images can represent text, but they cannot BE text, and elements can only contain text — philosophically if not technologically.
February 22nd, 2009 at 8:59 am
Jack,
Either you are being more pedantic than most web designers, or you missed the premise of the situation. You are correct in what the HTML designers intended. Text is text and images are images. Beyond that, many developers are not at all satisfied with the very limited range of fonts available for the web. In short, many developers think that headings (using h1 through h6 and the fewer than a dozen font faces) are just plain ugly.
That was why Todd Fahner developed the “image replacement” method. It is a method that allows the actual h1 through h6 heading code and original text to be retained, but to have that material replaced by a more attractive image of the text. This opens the possibility to literally thousands of font faces for text for headings. Using these methods, we can have heading text that is very attractive and have the original text too. The end result is a heading that is BOTH text and image.
The question here, in this test case, is whether the various image replacement techniques are accessible. Can the underlying text still be found and announced by a screen reader?
April 17th, 2009 at 9:19 pm
[…] Quiz 1.1.4: Image Replacement Techniques - Bob Easton […]
August 12th, 2009 at 6:29 am
[…] The usage of em causes some slight problem with old Version of Safari, so whenever possible (actually I can’t think of a situation when this isn’t possible) […]