A Call for Accessibility

The following is an early draft of the intro to Chapter 6 of Refactoring HTML. The remainder of the chapter will address specific recipes for improving site accessibility, especially those tasks that remain after a site has been made strictly valid (which is addressed in earlier chapters). Comments, suggestions, and corrections, are appreciated.

The Web has the potential to more fully integrate people with seeing, hearing, physical, learning, and other disabilities into society. By limiting the interaction necessary to communicate, as well as enabling delayed communications so that participants can move at their own pace, the Web has transformed our relationships with each other. Properly designed web pages neither know nor care whether you’re reading them with a CRT or a screen reader. Properly designed forms neither know nor care whether you’re inputting data with a keyboard, a mouse, or voice recognition software.

However accessibility does not come automatically. Many pages are locked into one modality of use, most commonly visual. Many pages are designed with the assumption that the user will view the page in the same way that the designer does. Such pages can lock out people with different levels of eyesight, attention, motor skills, and a dozen other characteristics.

Accessibility is not just about supporting people with extreme physical impairments such as blindness either. Ability and accessibility are both continuums. People don’t merely see or not see. They see better or worse. Most of us see worse with age. By age 40, we’ve either discovered the Ctrl-+ keyboard shortcut for increasing the font size of our browser or we’ve begun cursing out 20-something web designers as we surf (or both). The changes you make to improve accessibility don’t just help people who meet the legal definition of disabled. They help everyone’s who’s seeing, hearing, or motor skills are less than perfect. At least some of the time, that’s all of us. If it isn’t today, it will be tomorrow. As we age, eye sight and motor skills decline, and accessibility becomes more important. When I started on the Web, college students were a majority of the population on the net. Today they’re probably less than 10%, and are vastly outnumbered by senior citizens.

Accessibility also improves your site for people accessing it with non-traditional devices. A 28-year old Wall Street trader may prefer to view your news through the small screen of her Blackberry. Even an airline pilot with 20/20 vision may as well be blind when listening to your page on their cell phone while jogging.

Of course, accessibility isn’t just about supporting people with physical or device impairments. Wheelchair ramps are far more commonly used by parents with strollers, students with bicycles, and delivery people with hand trucks than they are by people in wheelchairs. Properly done, increasing accessibility for the disabled increases accessibility for everyone. That’s as true on the World Wide Web as in the physical world.

In many jurisdictions, accessibility is not just a good idea, and the right thing to do. It’s the law. In the United States, the Americans with Disabilities Act requires that all web sites built or procured by the Federal government be accessible to users without regard for physical handicap.

And if all that isn’t enough to convince you that it’s important to invest time and resources in making your pages accessible, consider this. The most profoundly disabled user of your page is going to be a search engine robot. Robots can’t see, hear, touch, or think. They are unbelievably stupid. While a person can eventually make sense out of a strange layout or text encoded in an image, a robot never will. Almost everything you do to make your pages more accessible to and usable by people will be paid back ten-fold in search engine optimization.

Simply making documents valid XHTML makes documents a lot more accessible than they otherwise would be. Making them strict XHTML rather than transitional goes even further. Removing presentational elements like b and replacing them with semantic elements like strong helps a little. Separating the content from the presentation using CSS stylesheets helps a lot.

However, that’s the beginning of accessibility, not the end. If you aren’t careful, you can create completely valid but almost totally inaccessible pages. Validation is an automatic and unthinking process. It focuses purely on the syntax. It can’t tell if you’ve chosen green on red text that will be impenetrable to many color blind visitors. It doesn’t know that the first 20K of your page are advertising and navigation that blind users have to slog through before getting to the actual content. It can’t distinguish between a well designed data table containing monthly financials and a layout table that rearranges the linear flow of text into unintelligible gibberish.
Making web sites accessible requires applying human intelligence to recognize and then fix problems like these.

As usual there are tools that can help. The W3C HTML validator discussed in Chapter 2 notes many accessibility problems as well as pure well-formedness and validity errors. Other tools are available that check more deeply for accessibility. The W3C maintains a list of many such tools at http://www.w3.org/WAI/ER/tools/complete/. These tools are helpful, but they are relatively stupid. They may find problems a validator won’t, such as green text on a red background; and they may suspect that certain tables are likely being used for layout. However, they don’t know this, and there are many problems they will never find. You must spend some time looking at the site with an eye toward accessibility.

Accessibility is ultimately about people, not following a fixed set of rules. If your site is open and accessible to all users you’ve done your job, even if you’ve violated a rule here or there. If your site is confusing or hard-to-use, you haven’t, even if it validates and passes all the automated checks. To really tell how well you’ve succeeded you have to do user testing. Observe actual users navigating your site. Watching even a single user will reveal problems you didn’t know you had. Time and budget permitting, you should observe many, and endeavor to include users with different skill sets and abilities. Watching a senior citizen navigate your site will tell you very different things than watching a teenager. Watching a blind user navigate with a screen reader will reveal issues you won’t encounter with a sighted user. Try to test as many different classes of users as you can. Even if your budget does not permit formal user testing, do some informal testing by recruiting your friends, family, and co-workers for simple tests.

Sometimes even seeing the difficulties other users experience isn’t enough. We have to experience them for ourselves. If you do not have easy access to blind users, you can simulate their experience. First try surfing your site through the text mode browser Lynx. Second, buy and install screen reader software such as JAWS, turn off your monitor, and try to surf your own site. This will give you a decent approximation of how a blind user views your site. The turn the monitor back on, disconnect the mouse and the keyboard, and try navigating with voice recognition. This will help teach you how some physically disabled people will approach the site and where their pain points are likely to be.

Web site accessibility is still quite poor, and in 2007 there’s no excuse for that. Most users are inconvenienced, some critically so. However there are some simple changes and improvements you can make to the design of your sites to improve matters.

This entry was posted on Wednesday, March 28th, 2007 at 8:50 am and is filed under Refactoring HTML, Web Development. You can follow any responses to this entry through the Atom feed. Both comments and pings are currently closed.