Usability, Accessibility, and Profitability

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.

Carl Zetie is an analyst with Forrester Research.

To discuss this column with other readers, please visit the Talk Shop.