Long Term Goal – Total Accessibility – 100% Usability

A good test case then might be someone who is very old and has multiple disabilities. They are adjusting to the latest disability, blindness, and are not on the technological cutting edge.

The user would need able to easily do the following using a public browser:

Choose a vehicle of transmission (how the user communicates with the browser. (spoken, keyboard, signs, sounds, gestures / movement, binary interface (sip & puff switch / big red button ;)

Choose a language
ie. English

Choose a Dialect (perhaps less important / optional?)
ie. Canadian

Choose the data reception vehicle / mode
Spoken (in this case)
But it might be
Signed
Gesture (optional?)
Sounds
Pictures / icons

Then the user might require and the site might offer varying degrees of complexity or detail depending on the users abilities and desires.

Data Detail a.k.a. “view”
Collapsed
Standard
Detailed
In Depth

So we are talking about a mode of transmitting information.By designing it for “multiple disabilities” we end up making accessible to everyone and super flexible for all users.

Hope this is of interest to you tech headz…

Personally, I feel that screenreaders—primarily built for the blind—should ignore CSS entirely (aural properties being the exceptions). (The content property is a bit of an issue: I have never liked the property because it allowed the designer to add content that wasn’t in the HTML.) On the other hand (getting back to screenreaders), there are some people who use them who are not blind: dyslexic users benefit from them and perhaps visually impaired persons too.

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.

Read the full results at Access Matters.

You may try it with meyerweb.com or stopdesign.com for example. It’s fun to hear how it speaks meyerweb’s hidden navigation links or how stopdesign’s page stucture presents the most interesting content first (articles) and less interesting content later (such as lists of links).

As you said, the era of table-layout (tag soup) is ending. Yet, you must agree that badly coded pages will exist as long as humans exist. The simple fact web developers are switching to CSS layout is not enough.

I’m not sure that !DOCTYPE switching is the answer. Your hypothesis is that screen readers are currently screen scrapers, that they somehow glean stuff from the screen left to right, top to bottom. Maybe the older ones behave that way, but later versions are much more DOM dependent and don’t literally scrape the screen. Yes, they base themselves on IE. But, they extract the DOM tree and work from that. For the most part that is going to be very similar to the document source, no matter what the CSS does.

To illustrate, I’m running some tests based on the first part of Joe Clark’s question, a question not dissimilar from some of what you have said. Over on Access-Matters, we’re testing 4 of the Zen Garden pages with assistive technology. I selected pages that have very different visual layouts. Of course, we all know they have exactly the same source. Results so far show that the latest screen readers (JAWS 6.01 and IBM HPR 3.04) read those four pages almost identically. The differences are in the areas where image replacement techniques are done with inaccessible methods.

Next week, we’ll do more test cases with source that varies more.

So in one sense, the latest screen readers are the “speaking browsers” you seek. They faithfully speak the source document independent of how CSS says it should be displayed. This is what you ask for in your fourth paragraph.

What I think we really need is not mode switching, but standards compliance. The real problems are (1) inability to parse imported style sheets, and (2) total ignorance of aural style sheets. Fix those first. Then, add a configuration option where users can tell the screen reader to ignore CSS positioning.

The last thing I want is yet another piece of software that warrants quirks mode considerations and pampering.

…ignore the CSS—at least that CSS which is meant for visual media, which these days is pretty much all of it.

And it will continue to be pretty much all of it until auditory styling is supported. If combined with speech recognition, I think that even people with normal vision would use a speaking browser from time to time.

But alas, with no support, why should I even try to learn to write them? And how could I practice.