A smaller crowd today, and a shorter session.
We got a demo from the blind Ph.D. Google guy of his audio desktop, which is a collection of scripts that run the gamut from API-based extensibility of sites to old-school screen-scraping. Basically, he said, out of necessity, he started doing the stuff Greasemonkey does now, about five years before Greasemonkey started doing it. He showed how direct access to content is vastly superior to parsing through a visually-oriented site using a browser rendered by a screenreader, and there's no doubt to me that he's right about that. The problem, for now, is that he has such a poweruser setup that it really isn't useful to blind folks who aren't Ph.D.s at Google.
After the coffee break, we had a free-for-all session. Several of the attendees had websites that we tested, on the big screen, using the Window-Eyes screenreader. This was useful on several levels. First, coming on the heels of the audio desktop demo, it was further proof that direct content beats the clunky screenreader, hands down, and the poor Window-Eyes vendor's protestations didn't help his case any. It's not that his screenreader is such an awful screenreader, as screenreaders go; it's that screenreaders seem like totally the wrong paradigm. I can't help but think of the difference between Signing Exact English and ASL.
The website testing was a bit of déjà vu for me. One after another, websites created by really passionate people, who believed they had really rigorously followed accessibility standards, flunked out when tested with a real live screenreader. Heck, even one of the organizers of the conference, who does these kinds of standards for a living, was surprised by some of the screenreader's behaviors. The same thing happened to me when I, a really passionate person who believed I had really rigorously followed accessibility standards, took my web app to a beta test with a real live blind user and real live JAWS.
I had a lightbulb moment during today's testing session. It isn't just that the accessibility standards are out-of-date, though they are. We are really dealing with two totally different issues, both of which have their analogues in the sighted web. There's standards-based accessibility, the traditional kind, and then there's accessible usability. If you think about the early web, it's clear that these were different things for the sighted world, too, and that one lagged behind the other.
Standards are pretty concrete. Well, OK, less so these days, but still. The problem is, nobody follows them, and the screenreaders know that nobody follows them, so the screenreaders have no choice but to adopt workarounds, which break the standards. (Déjà vu again? Isn't this what some of the early (sighted) browser wars were about?)
But beyond that, standards are not enough. Just like in the sighted web, a perfectly standards-compliant site may be incomprehensible to users; in the case of accessibility, may be incomprehensible to users with screenreaders. Poor organization, badly-designed widgets, counter-intuitive behaviors are not usable. And if a site isn't usable, it isn't accessible, no matter how "compliant" it is.
I doubt very much that I'm the first person to think of accessible usability. It sounds like some of the other (sighted) attendees at this week's conference figured out something along these lines themselves. Screenreader users probably thought of it a long, long time ago.
The problem is, like sighted usability, accessible usability is bound to be much more abstract, less understood, more widely variable among users, and generally debatable for years to come.
And that's even before we attack the paradigm.
This stuff is hard.
Friday, December 01, 2006
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment