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.
Ray
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.
Justin Peters
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.
Copy & paste the code below to embed this comment.
John Keller
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?
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:
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.
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?
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”.
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?
Copy & paste the code below to embed this comment.
Darrel
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).
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?
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.
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
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’.
Copy & paste the code below to embed this comment.
Matt
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.
Fredrik Carlsson
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.
Copy & paste the code below to embed this comment.
qwasty@hotmail.com
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.
Shakey
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.
Charles
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.
Charles
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.
44 Reader Comments
Back to the ArticlePhil Ledgerwood
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.
Ray
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.
Justin Peters
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
John Keller
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?
Greg Pfeil
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.
Matt Round
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?
Mike
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
Ian Anderson
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
Inge Jørgensen
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.
Boris Meyer
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.
Darrel
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).
Panta
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?
Panta
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]
Alex
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?
Panta
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
Garçon
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.
Lenny
How about using display:none to hide the text only when the medium is screen?
Karl Dubost
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.
Matt
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?
Fredrik Carlsson
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?
qwasty@hotmail.com
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.
Shakey
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 ;)
Charles
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.
Charles
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.