Screen Readers and CSS Layout
Screen readers are mostly mystical devices for almost all of us. Few of us actually own them. They’re incredibly expensive. Fewer yet know how to use them well, what their capabilities are, or how they actually work. Is it little wonder then, that big names in our web design world question how screen readers handle modern layout techniques? Not at all. The two gurus quoted below have other strengths, and specialities. They probably haven’t used a screen reader in ages.
Recently Joe Clark said the following about testing CSS layouts,
…, we don’t have a clue how the variations of CSS layout techniques – particularly floated elements – function in today’s adaptive technologies. … It wouldn’t’t take long to test these, you know.
In one regard, Joe was really issuing a call to action to the National Center for Accessible Media, citing them as an appropriate agency for testing. In another, he’s right. It doesn’t take long to test. All we need is a few people with a few tools and some patience.
Eric Meyer recently wrote in “Don’t Read, Speak!“
What I’m saying is that screen readers need to become speaking browsers: they need to ignore how the page is visually displayed, and read the content. … Go from the beginning of the document to the end of the document, and ignore the CSS
Joe suggested testing. Eric suggested modernizing the screen readers, and then using !DOCTYPE switching to help them determine how to speak contents.
Test Results with Three Leading Screen Readers - Summary
Joe, we don’t have to wait for a bureaucracy to lumber into action to get some basic testing done. Test results for the three leading screen readers are coming up.
Eric, these particular products already do what you suggest.
Executive summary: Current versions of the three leading screen readers speak page contents in the exact order the content is coded in the HTML source. CSS positioning is irrelevant.
Yes, other products and older versions of these same products might perform differently. If anyone has different results, add them to the comments for this article.
Test Results with Three Leading Screen Readers - Details
We have two batches of results. The first batch is based on Joe’s suggestion to test the Zen Garden pages. As you already know, we don’t need to test all of them. I selected four which had markedly different visual layout, numbers 000, 019, 151, and 167, and exposed them as a quiz question a few days ago. I then tested each of those pages with current versions of the three leading screen readers: Jaws 6.1, Window Eyes 5.0, and IBM Home Page Reader 3.04.
The second batch of results comes from a much starker set of material. I used the typical three column layout: header, column 1, column 2, column 3, footer. As with the Zen Garden, the HTML remained exactly the same for four variations. The variations reordered the visual position of the columns using CSS floats. That group of test cases was posted yesterday, and I again ran through the same testing regime used earlier.
Zen Garden Details
Distill the HTML for the Zen Garden into a simple outline, and you end up with 31 content elements: title, headings, paragraphs, lists, and a footer full of links. Make 12 copies of the outline and listen to four pages in each of three screen readers. Tick off the results.
In every case the material was spoken in exactly the same order as it appears in the HTML. In every case, save one, the cause for material not being spoken was the use of display : none. The one exception was page 019, where HPR failed to read two paragraphs that the others read. I suspect this is a bug, and mark with “?” in the results table.
Anyplace you see a “-” in the table of results, the designer has used display : none to explicitly hide that material. Almost all of these cases were replacing header text with images. We tested various image replacement techniques in an earlier quiz and found several that are more accessible than these examples.
One other omitted utterance happens when Window Eyes fails to pronounce the “%” character. I don’t know if this is a bug, or a verbosity setting not turned up high enough.
I am not especially adept with these tools and have used them with settings very close to what arrived as defaults. In Window Eyes, I had to dig in and find a setting to persuade it to read more than the first 24 lines of material. Other than that, I just point them at web pages and let them ramble on.
| ZG 000 | ZG 019 | ZG 151 | ZG 167 | |||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Content Elements | J | W | H | J | W | H | J | W | H | J | W | H |
| 1 title: CSS Zen Garden… | - | - | X | - | - | X | - | - | X | - | - | X |
| pageHeader | ||||||||||||
| 2 h1: CSS Zen Garden | - | - | - | - | - | - | - | - | - | - | - | - |
| 3 h2: The Beauty of CSS Design | - | - | - | - | - | - | - | - | - | - | - | - |
| quickSummary | ||||||||||||
| 4 p1: A demonstration of what … | X | X | X | X | X | X | - | - | - | - | - | - |
| 5 p2: Download the sample … | X | X | X | X | X | ? | - | - | - | X | X | X |
| preamble | ||||||||||||
| 6 h3: The Road to Enlightenment | X | X | X | - | - | - | X | X | X | - | - | - |
| 7 p1: Littering a dark and … | X | X | X | X | X | ? | X | X | X | X | X | X |
| 8 p2: Today, we must clear … | X | X | X | X | X | X | X | X | X | X | X | X |
| 9 p3: The css Zen Garden … | X | X | X | X | X | X | X | X | X | X | X | X |
| explanation | ||||||||||||
| 10 h3: So What is This About | X | X | X | - | - | - | X | X | X | - | - | - |
| 11 p1: There is clearly a need … | X | X | X | X | X | X | X | X | X | X | X | X |
| 12 p2: CSS allows complete … | X | X | X | X | X | X | X | X | X | X | X | X |
| participation | ||||||||||||
| 13 h3: Participation | X | X | X | - | - | - | X | X | X | - | - | - |
| 14 p1: Graphic artists only … | X | X | X | X | X | X | X | X | X | X | X | X |
| 15 p2: You may modify the … | X | X | X | X | X | X | X | X | X | X | X | X |
| 16 p3: Download the sample … | X | X | X | X | X | X | X | X | X | X | X | X |
| benefits | ||||||||||||
| 17 h3: Benefits | X | X | X | - | - | - | X | X | X | - | - | - |
| 18 p1: Why Participate? … | X | X | X | X | X | X | X | X | X | X | X | X |
| requirements | ||||||||||||
| 19 h3: Requirements | X | X | X | - | - | - | X | X | X | - | - | - |
| 20 p1: W would like to see … | X | X | X | X | X | X | X | X | X | X | X | X |
| 21 p2: Unfortunately, designing … | X | X | X | X | X | X | X | X | X | X | X | X |
| 22 p3: We ask that you … | X | X | X | X | X | X | X | X | X | X | X | X |
| 23 p4: This is a learning … | X | X | X | X | X | X | X | X | X | X | X | X |
| 24 p5: Bandwidth graciously … | X | X | X | X | X | X | X | X | X | X | X | X |
| footer | ||||||||||||
| 25 validation links … | X | X | X | X | X | X | X | X | X | X | X | X |
| lselect | ||||||||||||
| 26 h3: Select a Design | X | X | X | - | - | - | X | X | X | - | - | - |
| 27 list of 8 designs.. | X | X | X | X | X | X | X | X | X | X | X | X |
| larchives | ||||||||||||
| 28 h3: Archives | X | X | X | - | - | - | X | X | X | - | - | - |
| 29 list of 2 archives | X | X | X | X | X | X | X | X | X | X | X | X |
| lresources | ||||||||||||
| 30 h3: Resources | X | X | X | - | - | - | X | X | X | - | - | - |
| 29 list of 5 resources | X | X | X | X | X | X | X | X | X | X | X | X |
| Recordings (about 1.2mb each) | J | W | H | J | W | H | J | W | H | J | W | H |
Ordered Column Details
Same procedure here as above: 12 listening sessions. The results are absolutely identical except for the title of each page and the single line of text which mentioned column order. These are much shorter, with recordings about 150 kb each.
| Test case | Recordings | ||
|---|---|---|---|
| Column order 1-2-3 | JAWS | WE | HPR |
| Column order 2-1-3 | JAWS | WE | HPR |
| Column order 3-1-2 | JAWS | WE | HPR |
| Column order 3-2-1 | JAWS | WE | HPR |
Wrap Up
One is tempted to test more examples, but we can see already that the results will be the same. Today’s screen readers speak the content in the order it is written in the HTML. Knowing this, you can give documents the structure you want. If you want to emphasize center column content, making the left and right columns less relevant, place the center material highest in the HTML and use CSS to control visual layout. Screen readers will then present the most important material first, just as you want.
July 4th, 2005 at 6:14 pm
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.
July 4th, 2005 at 7:20 pm
Cheers Bob! Thanks for the great article.
July 5th, 2005 at 1:37 am
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.
July 5th, 2005 at 3:45 am
Great work, Bob et al.
One for my perenially-unfinished canonical access resources page
July 5th, 2005 at 4:48 am
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.
July 5th, 2005 at 1:00 pm
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…
July 5th, 2005 at 3:51 pm
Thanks a lot for your article and work. It was a pleasant read an very informative - I could improve my accessibility-knowledge.
Cheers.
Julian.
July 5th, 2005 at 4:08 pm
I did further tests using VoiceOver under MacOS X. The results and recordings are at http://www.raggedcastle.com/webcrumbs/archives/003829.html
July 5th, 2005 at 9:55 pm
“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.
July 5th, 2005 at 10:44 pm
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).
July 6th, 2005 at 3:00 am
Final blog mergings and source-ordered markup
Source-ordered markup with content first is better for accessibility.
July 6th, 2005 at 5:37 am
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?
July 6th, 2005 at 5:46 am
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.
July 6th, 2005 at 5:52 am
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?
July 6th, 2005 at 8:59 am
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.
July 6th, 2005 at 8:09 pm
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.
July 7th, 2005 at 6:47 am
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?
July 7th, 2005 at 9:32 am
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.
July 18th, 2005 at 2:15 pm
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 :-)
July 18th, 2005 at 5:41 pm
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.
July 20th, 2005 at 10:02 am
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. :)
September 13th, 2005 at 5:31 am
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.
September 13th, 2005 at 11:36 am
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…
November 15th, 2005 at 3:19 am
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.
November 15th, 2005 at 3:26 am
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.
May 2nd, 2006 at 6:22 am
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