21 Philosophical Issue

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.

posted at 06:54 am on October 23, 2003 by Phil Ledgerwood

22 re: Philosophical issue

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.

posted at 08:22 am on October 23, 2003 by Ray

23 re: FIR, FEAR, FIRE... second take

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

posted at 08:28 am on October 23, 2003 by Justin Peters

24 Options?

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?

posted at 09:36 am on October 23, 2003 by John Keller

25 content property on non-pseudo elements

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 [em]and[/em] 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 [em]and[/em] Bar</object> long ago.

posted at 02:31 pm on October 23, 2003 by Greg Pfeil

26 "screen reading"

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?

posted at 03:44 pm on October 23, 2003 by Matt Round

27 content property

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

posted at 06:31 pm on October 23, 2003 by Mike

28 Why are we doing this?

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

posted at 02:38 am on October 24, 2003 by Ian Anderson

29 Re: Why are we doing this?

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.

posted at 04:33 am on October 24, 2003 by Inge Jørgensen

30 re: FIR, FEAR, FIRE... second take

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.

posted at 08:41 am on October 24, 2003 by Boris Meyer