| home / programming / usability / 1 |    [previous][next] |
|
|
|
When people start reading about accessibility, they usually come across one piece of advice that sounds very promising:
The problem is, when they run their site through a validator, it turns out to be more like a grammar checker than a spell checker. Yes, it does find some obvious mistakes and oversights that are easy to fix, like missing alt text.6 But it also inevitably turns up a series of vague warnings that you may be doing something wrong, and a long list of recommendations of things for you to check which it admits may not be problems at all.
This can be very discouraging for people who are just learning about accessibility, because the long lists and ambiguous advice suggest that there’s an awful lot to learn.
And the truth is, it’s a lot harder than it ought to be to make a site accessible. After all, most designers and developers are not going to become accessibility experts. If Web accessibility is going to become ubiquitous, it’s going to have to be easier to do. Screen readers and other adaptive technologies have to get smarter, the tools for building sites (like Macromedia Dreamweaver) have to make it easier to code correctly for accessibility, and the guidelines need to be improved.
Real progress is going to require improvements on four different fronts, motivated by things like profit incentive, the threat of lawsuits and legislation, and the desire to support mobile devices, which share some problems with accessibility.
The fact that it’s not a perfect world at the moment doesn’t let any of us off the hook, though.
Even with current technology and standards, it’s possible to make any site very accessible without an awful lot of effort by focusing on a few things that will have the most impact. And they don’t involve getting anywhere near a buttered cat.
One of the things that I find annoying about the Tang argument (“making sites accessible makes them more usable for everyone”) is that it obscures the fact that the reverse actually is true: Making sites more usable for “the rest of us” is one of the most effective ways to make them more effective for people with disabilities.
If something confuses most people who use your site, it’s almost certain to confuse users who have accessibility issues. (They don’t suddenly become remarkably smarter because they have a disability.) And it’s very likely that they’re going to have a harder time recovering from their confusion.
For instance, think of the last time you had trouble using a Web site (running into a confusing error message when you submitted a form, for instance). Now imagine trying to solve that problem without being able to see the page.
The single best thing you can do to improve your site’s accessibility is to test it often, and continually smooth out the parts that confuse everyone. In fact, if you don’t do this first, no matter how rigorously you apply accessibility guidelines, people with disabilities still won’t be able to use it. If your site’s not clear to begin with, making it Bobby-compliant is like [insert your favorite putting-lipstick-on-a-pig metaphor here].
As I hope you’ve seen by now, the best way to learn how to make anything more usable is to watch people actually try to use it. But most of us have no experience at using adaptive technology, let alone watching other people use it.
If you had the time and the motivation, I’d highly recommend locating one or two blind Web users and spending a few hours with them observing how they actually use their screen reader software.
Fortunately, someone has done the heavy lifting for you. Mary Theofanos and Janice (Ginny) Redish watched 16 blind users using screen readers to do a number of tasks on a variety of sites and reported what they observed in an article titled “Guidelines for Accessible and Usable Web Sites: Observing Users Who Work with Screen Readers.”7
As with any kind of user testing, it produced invaluable insights. Here’s one example of the kinds of things they learned:
7 Published in the ACM Magazine, Interactions (November-December 2003). With permission from ACM, Ginny has made it available for personal use at http://redish.net/content/ papers/interactions.html.
Screen-reader users scan with their ears. Most blind users are just as impatient as most sighted users. They want to get the information they need as quickly as possible. They do not listen to every word on the page—just as sighted users do not read every word. They “scan with their ears,” listening to just enough to decide whether to listen further. Many set the voice to speak at an amazingly rapid rate. They listen to the first few words of a link or line of text. If it does not seem relevant, they move quickly to the next link, next line, next heading, next paragraph. Where a sighted user might find a keyword by scanning over the entire page, a blind user may not hear that keyword if it is not at the beginning of a link or a line of text. |
I highly recommend that you read this article before you read anything else about accessibility. In 20 minutes, it will give you an appreciation for the problems you’re trying to solve that you won’t get from any other articles or books.
After you’ve read Ginny and Mary’s article, you’re ready to spend a day (or a weekend) reading a book about Web accessibility. There are several good ones…
> Building Accessible Websites by Joe Clark
> Constructing Accessible Websites by Jim Thatcher et al.
> Maximum Accessibility: Making Your Web Site More Usable for Everyone by John Slatin and Sharron Rush
> A CD-ROM called The WebAIM Guide to Web Accessibility Techniques and Concepts
…and I’m sure there will be more in the near future.8
These books cover a lot of ground, so don’t worry about absorbing all of it. For now, you just need to get the big picture.
8 I’ll keep an updated list of recommendations on my Web site.
| home / programming / usability / 1 | [previous][next] |
Legal Notices, Licensing, Reprints, Permissions, Privacy Policy.
Advertise | Newsletters | Shopping | E-mail Offers | Freelance Jobs 
Created: March 27, 2003
Revised: November 22, 2005
URL: http://webreference.com/programming/usability/1
