Comments on: Screen Readers and CSS Layout

By: nortypig

nortypig — Mon, 04 Jul 2005 22:14:46 +0000

Thanks for the heads up on this one. I’d suddenly become uncomfortable with the way I had been working and it’s good to know the answer at last. Maybe this should become one of those ‘Myth Busters’ sections on the site (tongue in cheek).

Seriously, your site is making a big difference so keep it up. Thanks again on behalf of the many who can’t afford the resources to check this kind of thing for ourselves.

By: Neil Ford

Neil Ford — Mon, 04 Jul 2005 23:20:20 +0000

Cheers Bob! Thanks for the great article.

By: Philippe

Philippe — Tue, 05 Jul 2005 05:37:01 +0000

The results are reasuring, given some discussions elsewhere that structured code doesn’t help screen readers.

I listened to the Ordered Column demo files with iCab3.0 beta (which has a build in ’screen speaker’) on OS X. The results: it reads the content of the page in the order of the source code, just as Jaws does.

By: Bruce Lawson

Bruce Lawson — Tue, 05 Jul 2005 07:45:49 +0000

Great work, Bob et al.
One for my perenially-unfinished canonical access resources page

By: Andy Hawkes

Andy Hawkes — Tue, 05 Jul 2005 08:48:39 +0000

A genuinely extremely useful article!
I am glad to find some simple vindication of the use of clean, semantic markup irrespective of the choice of user agent. There has been a glut of commentary on this subject without the benefit of simple empirical analysis to enlighten the debate. Perhaps now we can make further genuine progress in understanding how our work can develop to encompass best practice and present the same “experience” of the content to all of our users, irrespective of visual accuity or physical ability.

By: CSSHilfe

CSSHilfe — Tue, 05 Jul 2005 17:00:23 +0000

Screenreader und CSS Layouts

In Screen Readers and CSS Layout berichtet Bob Easton über das Zusammenspiel von (X)HTML / CSS Layouts und aktuellen Screenreadern. Das Fazit: One is tempted to test more examples, but we can see already that the results will be the…

By: Julian

Julian — Tue, 05 Jul 2005 19:51:40 +0000

Thanks a lot for your article and work. It was a pleasant read an very informative - I could improve my accessibility-knowledge.

Cheers.

Julian.

By: Andy Affleck

Andy Affleck — Tue, 05 Jul 2005 20:08:18 +0000

I did further tests using VoiceOver under MacOS X. The results and recordings are at http://www.raggedcastle.com/webcrumbs/archives/003829.html

By: Eric Meyer

Eric Meyer — Wed, 06 Jul 2005 01:55:55 +0000

“Eric, these particular products already do what you suggest.”

No, they don’t, as you yourself point out:

“In every case, save one, the cause for material not being spoken was the use of display : none.”

When I say screen readers need to become speaking browsers, and ignore the CSS, I mean that in every sense. it isn’t just about where things appear on the page. It’s about audibly rendering content that’s been visibly hidden for the screen medium.

Until these tools change that behavior, they’re still at some level screen readers, and they’re still broken.

By: Philippe

Philippe — Wed, 06 Jul 2005 02:44:44 +0000

One more tidbit about the ’screen speaker’ that comes with iCab 3.0. It does read (ahem, speak) text set to display: none. The simple text case was a paragraph of text containing a span set to display:none, the speaker marked a little pause at the span, I think.
(basically ignoring the stylesheet altogether, stylesheet specified as media screen).

By: Farlops Industries

Farlops Industries — Wed, 06 Jul 2005 07:00:23 +0000

Final blog mergings and source-ordered markup

Source-ordered markup with content first is better for accessibility.

By: Bob Easton

Bob Easton — Wed, 06 Jul 2005 09:37:12 +0000

Eric, I’m shocked, shocked I tell you, shocked!

I thought you were an advocate for standards compliance. Which part of standards compliance do you advocate for screen readers? That they comply with the same standards everyone else, or some arbitrary subset?

If they should speak everything, why stop at display : none? If we extend your logic, they should speak every single ALT and TITLE attribute whether redundant or not. Then, should also speak meta contents … and maybe HTML comments too. Where does it end?

By: Bob Easton

Bob Easton — Wed, 06 Jul 2005 09:46:11 +0000

Philippe, In your iCab testing, was that with inline styles, linked styles, or imported styles? We found in earlier testing that some screen readers don’t read linked or imported sheets as we expect broswers to do.

By: Bob Easton

Bob Easton — Wed, 06 Jul 2005 09:52:28 +0000

Andy, THANKS for more recordings! As I listen to them, the first one sounds as I expected, but the others have words and phrases abbreviated or clipped. Do you know why this is?

By: Georg

Georg — Wed, 06 Jul 2005 12:59:17 +0000

Bob, screen readers should either ignore CSS completely - as Lynx does, or use their own media style. ‘Voice’ would be fine, I think.

iCab speaks text in containers which have inline style ‘display: none; visibility: hidden;’. From testing a few of my own pages, and one from CSS Zen Garden, it sounds like iCab does it ‘right’ - ignoring all styling.

By: Eric Meyer

Eric Meyer — Thu, 07 Jul 2005 00:09:09 +0000

Bob, I’m not quite certain if you’re joking or not. But if not, then Georg said what I would say. All screen CSS should be utterly ignored by non-screen devices. I expect an aural (audio, speech, whatever) medium device to ignore screen CSS just like I expect a print device to do the same. In fact, why should I expect anything else?

As to whether a speaking browser should ignore any CSS, period, regardless of whether it’s set up for “all” media or not, is another (far more interesting) discussion.

And yes, speaking browsers should read ALT and TITLE text, at least in standards-mode documents. Whether they should do so in quirks-mode documents is yet another interesting discussion.

If I seem to be advocating intentional violation of the standards (beyond a quirks/standards type mechanism), then either I’m not communicting clearly or I’m being misinterpreted.

By: Bob Easton

Bob Easton — Thu, 07 Jul 2005 10:47:51 +0000

Eric,
The opening line was certainly intended to be light hearted. I see now that it needed a smiley. The rest was aimed at drawing out more of your thinking. THANKS for responding.

Your points are where I started when I first began testing screen readers. I assumed that standards compliant aural user agents would behave as you suggest. Instead, we have this mis-mash of capability that’s based in part on DOM reading, part on hooking very low level Windows events, and part on smoke, pink liquids and mirrors.

Over on Accessify, Ian Lloyd is asking Screen Reader Users - What Bothers You Most? While his question asks specifically about (X)HTML support, I think the problems run far deeper. We should certainly offer him at least these expectations about how CSS should be handled.

Screen readers should ignore styles for screen media.
Screen readers should adhere to styles for aural media

Doing only these two things would make a spectacular difference.

I’m not yet convinced that quirks vs. standards mode matters. If we want screen readers to ignore screen CSS, what would be different for quirks mode? The CSS in older legacy material could easily be ignored. Most of it is font colors and sizes anyway, not much positioning. And we now know that it is source order that matters most in speaking order, not positioning. Am I missing some other reason to have !DOCTYPE switching in screen readers?

By: Philippe

Philippe — Thu, 07 Jul 2005 13:32:01 +0000

Bob, all my test are done with media=”screen” style sheets. Georg already pointed out, iCab ignores all styling. I’ve been planning to test the CSS2.1 Aural media stylesheet (iCab claims full CSS2.1 support), but haven’t gotten that far, yet.

I agree with you otherwise, as far as ignoring stylesheets, except when media=”speech” or “aural” (http://www.w3.org/TR/CSS21/aural.html). That is the purpose of the various media types.

The Doctype switching might be useful to ease the transition, in the short term.

By: pam

pam — Mon, 18 Jul 2005 18:15:50 +0000

I’ve listened to the Zen Garden examples using Fire Vox, which is an extension for Firefox. Fire Vox reads all the elements regardless of display: none although things sometimes get interesting when it tries to highlight chunks of information that aren’t displayed :-)

By: pam

pam — Mon, 18 Jul 2005 21:41:38 +0000

In Opera 8.01, I’ve used Ctrl+A to highlight all and asked Opera to speak. Here are the following results:

ZG 001 - started reading at 4 p1: A demonstration of what …
ZG 019 - started reading at 4 p1: A demonstration of what …
ZG 151 - started reading at 6 h3: The Road to Enlightenment
ZG 167 - started reading at 5 p2: Download the sample …

Opera continued reading the text contained in every element throughout the rest of the document.

By: Andy Affleck

Andy Affleck — Wed, 20 Jul 2005 14:02:07 +0000

The clipped sounds on my mac recordings of VoiceOver are just me skipping ahead and not letting the voice finish saying whatever it was saying. I was being impatient is all. :)

By: Jens Meiert (of UITest.com)

Jens Meiert (of UITest.com) — Tue, 13 Sep 2005 09:31:15 +0000

As Tomas Caspers already pointed out in Roger Johanssons blog, the “IBM Home Page Reader” actually is a voice browser, not a screen reader (though me, I also often refer to it as a “screen reader” - silly, silly Jens). Your nice overview proves that there are several faulty implementations which need to be addressed.

By: Faruk Ateş

Faruk Ateş — Tue, 13 Sep 2005 15:36:13 +0000

Thanks for the tests; pretty much what we’d hoped for all along, concerning screenreaders and CSS layouts. Excellent work :-)

The display:none / screen reader (vs. voice browser) issue was pretty much known already, and all this has pointed out is that they’ve not fixed their flaws in that sense. Mreh, a pity, but I doubt this test will mean any change in the products. Active lobbying would probably get more done…

By: Matthew McArdell

Matthew McArdell — Tue, 15 Nov 2005 07:19:53 +0000

It’s encouraging that certain screen readers read the DOM (unfortunately only for IE?) as I had previously assumed that the source may have been read at the time of loading instead.
Unfortunately the advantages of reading the DOM won’t be fully realised until modifications to the DOM (via JavaScript) can be detected and handled appropriately by the screen reader. Once this occurs - use of AJAX techniques to selectively update the content of a document (rather than reloading the entire thing) will be screen readable. It is the screen reader afterall that is the limitation here - the web browser renders the updated DOM just fine.

By: Matthew McArdell

Matthew McArdell — Tue, 15 Nov 2005 07:26:10 +0000

Hold on! I just read on an accessify forum that JAWS will read an updated DOM. Assuming that a sensible operation is performed like adding items to a list using JavaScript after the document has been fully loaded, can anybody tell me whether the reading is triggered at this point? Would the whole document be read again or only a portion? If reading is triggered at this point wouldn’t this imply that (when used sensibly) JavaScript modification of the DOM is in fact screen readable (although perhaps not fully accessible)?
Thanks,
Matt.

By: Anthony

Anthony — Tue, 02 May 2006 10:22:33 +0000

Interesting article. I’ve been struggling with the issue of source ordering because I’m not sure presenting content first is what users are expecting. Do they expect nav first as that’s what the majority of sites use? As a counterpoint, read: http://www.usability.com.au/resources/source-order.cfm

cheers
Anthony