Usability, Accessibility, Profitability
Web Design & Technology News, November 3, 2003

November 3, 2003

It's not only good business sense to make Web sites accessible, it's the law, says Carl Zetie. Listen to users for continuous feedback on both usability and accessibility shortcomings in Web apps and on sites.
By Carl Zetie

The novelty of doing business over the Internet wore off long ago, so you'd think that Web-site designers would get basic usability issues right by now. Think again.

I continue to be amazed at the number of companies that seem determined to make it difficult for potential customers to do business with them. It's bad enough for users who are able to deal with the typical assumptions of Web-site designers -- that they can read small fonts, position the mouse precisely, hear audio, and identify often-obscure images and icons. But for browser users with any kind of disability, it's still often hit and miss whether they'll even be able to use a given Web site. The most amazing aspect of the continuing widespread disregard for usability and accessibility is that failure to attend to these factors directly turns away customers. Smart companies realize that usability and accessibility translate into profitability.

There's a glimmer of hope. Many companies are increasingly concerned with ensuring that the applications they provide for their employees and the Web content they publish on their intranets and Web sites be accessible to all users. The pressure comes both from the desire to ensure that all employees and customers can use the applications and information as well as the need to comply with relevant accessibility legislation, such as the Americans with Disabilities Act (ADA) in the USA or the United Kingdom's Disability Discrimination Act (DDA).

Accessibility isn't just a good idea, it's the law. This focus on accessibility forces companies to think about, often for the first time, how users use and navigate their sites. This means that they have to start considering the needs of different kinds of users with differing abilities -- and from there, it's sometimes only a short step into thinking about users with differing tasks and needs. Addressing accessibility can become a backdoor into addressing usability more generally.

Any Web user can point to an endless list of minor and unnecessary irritations in just about every Web site they use. For users with accessibility needs, these irritations become major annoyances or even showstoppers.

Most of my own pet peeves relate to the clumsy design of forms that ask for your name, address, and telephone number. You would think that such a common requirement would be both well understood and totally standardized. Unfortunately, not only is it not so, but many Web sites go out of their way to make it harder than necessary. (And it's costing them money. One online brokerage recently lost my business before I even signed up because "Forrester Research" is too long for a company name, and "Mary Louise," my wife's first name, is unacceptable because it has a space in it.)

The most annoying error is the misuse of pop lists. Many Web sites ask users with a U.S. address to enter their state abbreviation -- something every American can do faster than they can think about it -- by picking from a pop list. Because the HTML pop list is such an ill-conceived control, you can't just type two characters into it. For example, typing "VA" scrolls you first to start of the "V" states, then back to the start of the "A" states. Typing "V" twice might get you to "Virginia," but no guarantee: Some lists are sorted by state name, some by state abbreviation, and if the list might or might not include the Virgin Islands, all bets are off.

Picking dates -- say on a travel site, or when entering the expiration date for a credit card -- is even worse. To enter the "19th" of the month, you would have to hit the 1 key 11 times (accidentally hit it once too often? Start over!) or the down arrow key 19 times. In fact, most users resort to operating the list with the mouse (which has annoyances all its own). But what about the user who can't use a mouse (for example, because they lack fine motor control) and is forced to use keyboard navigation? What should be two rapidly typed characters becomes 10 or 20 tedious keystrokes. A minor annoyance becomes a major time-waster, repeated on Web site after Web site. Worst of all, there's no good reason for it to be this way: a moment's usability testing would show that the pop lists trip people up, slow them down, and break their train of thought. (The counter-argument that it ensures valid data input doesn't hold up to examination: any competent Web developer is validating all user input on the server side as a matter of course, to protect against URL spoofing as well as client-coding errors).

Of course, these examples are relatively minor -- I picked them because they're so common and readily understood. They also provide a good example of how making the form more accessible for nonmouse users makes it more usable for all users.

Unfortunately, the Web is littered with far greater accessibility and usability barriers. Users with visual disabilities, for example, face a constant fight against fixed fonts too small to read, text rendered as graphics (making it invisible to screen readers), labels not properly attached to their input fields, and images without tags. Other users struggle with dynamic menus that pop and hide at the slightest touch or navigation elements unreachable with the keyboard.

Although accessibility compliance awareness is growing, it isn't always easy to achieve. The limitation with acts such as ADA and DDA is that the legislation isn't very specific about requirements. In practice, this is a good thing: the acts are largely concerned with ensuring that the provision of services (of which access to information is but one dimension) shouldn't unreasonably discriminate. The challenge is in determining what's "reasonable accommodation" of those with disabilities, and it wouldn't be possible or sensible for the legislation itself to describe in detail what is "reasonable" across all aspects of daily life. However, this leaves both the vendors and buyers of IT with the problem of determining what constitutes compliance in the specific domain of software applications and Web content.

Fortunately, there are well-defined standards that are increasingly widely accepted as proxies for compliance. In other words, they provide a reasonable benchmark for buyers to be confident of accessibility for their users and for both buyers and vendors to believe that they have made a reasonable, good-faith effort to comply.

The most widely accepted such guidelines are the Web Content Accessibility Guidelines (WCAG) from the World Wide Web Consortium (W3C) Web Accessibility Initiative (WAI). These guidelines are generally accepted in the United States, the United Kingdom, and other jurisdictions, and specify a number of levels of support, starting with the most basic level of accessibility.

However, even these standards don't claim to represent the ultimate in accessibility requirements. Rather, they represent a starting point and a benchmark. It's still essential to listen to users for continuous feedback on both usability and accessibility shortcomings in applications and Web sites. There are none so blind as those that will not see, none so deaf as those that will not hear, and none so stupid as those that turn away good business for no good reason.