2003 Conference Proceedings

Go to previous article 
Go to next article 
Return to 2003 Table of Contents 


ENSURING ACCESSIBILITY AND USABILITY IN A FEATURE-RICH, DATABASE-DRIVEN WEB SITE

Presenters
Crista L. Earl
American Foundation for the Blind
11 Penn Plaza, Suite 300
New York, NY 10001
Phone: (212) 502-7605
Email: crista@afb.net 
Website: http://www.afb.org

Elizabeth Neal
American Foundation for the Blind
11 Penn Plaza, Suite 300
New York, NY 10001
Phone: (212) 502-7733
Email: lneal@afb.net 
Website: http://www.afb.org

Introduction

The presenters have participated in and helped to lead the development of a full-featured web site, including a sophisticated database search, subscription-based and free content, children's games, e-commerce, an administrative area for staff use, and other complex features. Throughout the project, it was understood that it was necessary that every feature be accessible.

What did it mean to be accessible? Who would decide when it was accessible? How would we do this without sacrificing usability? How could we guarantee that it would be both accessible to blind users and appealing to sighted users unfamiliar with the "limitations" of accessible web design?

This presentation details our recommendations to those undertaking the building of an accessible web site, or the conversion of an existing web site to compliance with WAI or 508 guidelines.

Who to Involve: Including Relevant Viewpoints in the Process

Technical Skill

It might seem obvious that technical expertise is necessary. However, there is a widely-held belief that web design is 92% magic and that technical skill is not required, or can simply be recruited once a few decisions have been made. The authors strongly urge you to include technical skill in your team.

Diversity

A common error in web-site building is to fail to include a variety of users in the process. While it is not practical to include a representative of every possible combination of skill level, knowledge level, and access method, homogeneity ensures failure. Your web site may be pleasing to the wider group represented by your team members, but it will almost certainly fail to be effective for other types of users. If your web site is to be useful and attractive to users who are blind, include blind users as an integral part of your team. Be aware that users with low vision approach web pages differently than blind users. Be sure to include users who are familiar with the use of the mouse, not just the keyboard. Don't neglect the macintosh users.

Accessibility Experts

The authors strongly believe that an expert in accessible web design is essential. Ideally, this person would be a regular team member, but if one is not available, an expert who can be consulted on a frequent basis will help answer questions and may fill the knowledge gap.

Defining Accessibility and Usability

In order to make your web site accessible, you must decide what that means. Accessible to whom? Within what boundaries? If we decide that we mean accessible to blind users, must we ensure that the web site is accessible to blind users who use Netscape? Is it necessary that our web site be accessible to those who use equipment that is four years old? Do we include usability in our definition?

The WAI and 508 guidelines give excellent definitions to start with. Since our organization focuses on resources for people who are blind or visually impaired, we determined that it was necessary to make certain that our site was attractive to those users. We adopted the guidelines of the World Wide Web Consortium's Web Access Initiative as our starting point, then added a set of our own guidelines, some which were intended to improve usability and others to provide our interpretation to WAI guidelines that were found to be confusing to vendors.

Whatever your starting point, how you will know what is meant by "accessibility" will likely be a contentious issue. Establishing your organization's understanding of the goals will be essential in moving forward.

Build it In, Don't Add it On

You've heard it a thousand times: it's much easier (cheaper) to make a web site accessible when you've planned accessibility into it from the beginning than when you try to make an existing web site accessible. We know, however, that accessibility is often added on later.

Understanding Access Methods

In order to understand what the guidelines mean and how to implement them it is necessary to have a fairly detailed understanding of how users, especially users with disabilities, work with web pages. This means that the web team must become familiar with the whole range of user agents, forms of assistive technology, and skill levels. Each combination is used by skilled and unskilled users with varying degrees of effectiveness. Few users are using the latest equipment.

It is important that web designers learn to use these types of equipment and how these types of equipment interact with web pages. Since your team can hardly be large enough to include users of every combination of equipment and skill level, a series of usability tests with live, "real" users is a superb solution.

Challenging Parameters

You may have inherited a set of givens. The web site must look exactly as it does now, but be accessible. HTML pages that will be posted must all be done using a specific tool. Working accessibility into all the parameters already carved in stone may yield a compromise web site that no one can live with. Don't hesitate to challenge the parameters imposed on your team.

Working with vendors

It is likely that you will not be doing all the work yourself. You might make some decisions, perhaps fairly detailed ones, and then hire a company or a consultant to do as much as design and build the project or as little as coding some of the pages.

Selecting a Vendor: Don't Take Yes for an Answer

Ideally, you would hire a company with a long accessibility-resume and references from organizations with accessible web sites. It will be nearly impossible to find such a company, and probably impossible to afford to pay them.

We ask our potential vendors if they can build an accessible web site. They say yes. Few out-of-the-yellow-pages web designers have ever heard of the WAI guidelines or are aware that people with disabilities use computers. They are not lying when they say they can do it, they are only attempting to make a reasonable estimate of their talent. They are very smart people and the WAI guidelines, at least, have clearly written examples of what to do. How hard could it be?

How can you know if the vendor who claims to be able to make your web site accessible actually can? Some vendors are willing to demonstrate their knowledge or their willingness to do homework. If you're considering a company, ask for an example of their work. If they've worked with similar requirements before, they can show you the web sites they worked on. If not, they can create an example of how they would approach a specific feature.

Put your accessibility requirements in writing. Just as you spell out the requirements of any other characteristic of your web site, make it clear that payment for the project is contingent upon accessibility.

Speaking the Language

Unless you can express accessibility, usability, and inaccessibility in terms the vendor can understand, the process of getting the work done will be a struggle.

We've mentioned that your accessibility requirements need to be part of any contract for development. Money is certainly part of the language of web developers. When solving a problem becomes difficult, having the contract and check in your hands may be your only leverage.

Most issues that arise are the result of more elementary forms of miscommunication. The vendor simply doesn't know what you want.

First, prevent confusion. We provide each potential vendor with four documents (provided to presentation attendees):

The WAI guidelines and our own, additional, guidelines provide many examples written in HTML, a language any web developer can understand.

When confusion arises, be as definitive as possible. Your vague idea that a feature is difficult to use must translate into keys a programmer can press.

Don't forget how to communicate to non-accessibility-savvy people within your organization. When a programmer gives a complicated explanation of why something can't be done, you might need to translate it into "they can't figure out a way to fix that for the keyboard users without breaking it for the mouse users" or "that will cost us another $4000."

Testing: Knowing When You've Succeeded

It goes without saying that if pages don't work, if links go nowhere, if database access falls apart, it is the vendor's (or internal programmer's) job to fix them. They were hired to create those pages, after all.

Rule number one: nothing goes without saying. Vendors often create or modify pages and check nothing.

It is even more essential to have a formal process of accessibility testing than for generic technical testing. Accessibility testing is more difficult, in part because the ramifications of badly done work may not be apparent to the programmer. A formal process of accessibility testing must be set up independent of the process of verifying that links go where they should and that databases are available when users search them.

Technical Testing

No automatic software tool for checking the accessibility of web pages can replace rigorous testing done by your accessibility expert. Knowledge of the guidelines you're using, an understanding of how users use web pages, and a collection of tools combined with good judgement give the best technical accessibility test.

If your expert is expensive, use automatic validators to give the first pass over your pages and save your expert a great deal of time. A better solution is to become skilled yourself in what to look for.

User Testing

Nothing replaces user testing. Real users do things with web pages web developers never think of. Users of assistive technology will reveal errors in design judgement you will probably find no other way.


Go to previous article 
Go to next article 
Return to 2003 Table of Contents 
Return to Table of Proceedings


Reprinted with author(s) permission. Author(s) retain copyright.