Comments on: Screen Readers and CSS Layout

by: 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

by: 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: 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: 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: 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: 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: 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: 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: 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: 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?