The Planning, Evaluation, Repair and Maintenance Process
Web Accessibility Evaluation and Repair Methods

Use a software tool to check for accessibility errors

Accessibility evaluation software tools provide an effective first glance at the accessibility problems of a web site. These tools can identify certain types of errors such as images without alt text, forms without labels, frames without titles, and other objectively identifiable errors. They are much less effective at (and in some cases incapable of) identifying more subjective problems.

A list of some of these tools can be found in Accessibility Tools. Some tools are free, while others are commercially marketed.

Each of these tools has its own strengths and weaknesses, and each has its own style of providing feedback and helping the designer to make accessible web content. Some evaluate one page at a time, while others can evaluate entire web sites. Some only generate reports, while others incorporate a wizard-style interface to help the designer make the necessary changes to the web page. It really doesn't matter which of these tools the designer uses. It is largely a question of personal preference and style. All of these tools can be used effectively within their limitations, the most obvious limitation being their inability to find all of the errors.

Check for keyboard accessibility

Keyboard accessibility is important to users who are blind as well as to many users who are unable to use their hands. The biggest potential barriers to keyboard accessibility are usually the result of mouse-dependent JavaScript and rich media content, such as Flash or embedded video.

Common keyboard accessibility problems include:

• "Popup" or "fly out" menus (menus that appear when you move the mouse over a link)
• "Jump menus" that automatically submit the first choice in a drop down list (preventing the user from selecting other items in the list)
• Pages that change dynamically in response to user actions (not all of these cause keyboard accessibility problems, but they have the potential to cause problems)
• Drag and drop functions
• Flash objects not designed with keyboard accessibility in mind

To test for keyboard accessibility, use the keyboard only (no mouse) to navigate through the entire web site, testing the site's main navigation, forms and scripts. Make note of any situation in which items are inaccessible by keyboard. In most browsers, keyboard accessibility can be tested by using the Tab key to navigate forward through links, Shift + Tab to navigate backward through links, and the Enter key to follow links. The Opera browser uses the A, Q, and Enter keys to perform these same functions. In some browsers, it may be necessary to use the arrow keys to navigate within sets of radio buttons or within drop-down lists.

Perform a manual check using a checklist

Performing a manual check of a web site using a checklist can expose additional accessibility errors that would otherwise remain unidentified. In fact, many of the automated tools on the market inform users that a manual check is required for many of the guidelines. The problem is that too many people ignore this advice. They don't take the time to obtain a more accurate picture of their site's accessibility status.

The question of which checklist to use depends upon which standard the site is being evaluated against. If the target standard is WCAG 1.0, the most appropriate checklist to use would be the one published by the W3C at http://www.w3.org/TR/WCAG10/full-checklist.html - external link. If the standard is Section 508, one option would be to use WebAIM's Section 508 Checklist.

"Walk through" the site's navigation, functionality, and content while considering different disability types

The act of trying to experience the web site from the perspective of people with various kinds of disabilities is a crucial part of the evaluation process, yet it is often overlooked.

Developers should "walk through" all aspects of the site, from beginning to end, while imagining what the experience would be like for people with different types of disabilities. This walk-through should include all important aspects of the site, such as the navigation system, the main content, forms, etc.

It is especially important to consider the totality of a user's interaction. For example, the goal of an e-commerce site is to sell things. It is not enough to just be able to find the merchandise, or to log in to a user account, or to submit an order. All of these steps, and many others, are critical. If any step along this process is inaccessible, the entire process is inaccessible.

Refer to the document Considering the user perspective: a summary of design issues for more information on the specific issues of each of these types of disabilities.

Validate the HTML

Like any language, the HTML markup language is based on rules of grammar and syntax. And, as with any language, when these rules are violated, there is an increased chance for misunderstanding. With oral languages—such as English, French, Japanese, and so on—the person listening may misinterpret the meaning of a sentence if it is spoken with incorrect grammar. In the case of markup languages, it is the browser and assistive technologies that may misinterpret the intended meaning. In other words, web sites created with invalid ("ungrammatical") HTML may not render correctly in web browsers, screen readers, screen enlargers, and other technologies. The end result is that the person using these technologies may experience difficulties accessing the content, or may be unable to access it at all.

Admittedly, a web site does not always require valid HTML to be accessible, in a strict sense. Some HTML validity problems are inconsequential to the overall accessibility of web content. Still, it is generally easier to apply accessibility features to sites with valid HTML, and the valid HTML ensures greater interoperability of the content between different versions of browsers and assistive technologies. In addition, one of the required attributes of valid HTML is the alt attribute for images. Sites with valid HTML, by definition, comply with this accessibility requirement, though it is only required that the alt attribute be present, not that it be appropriate or equivalent to the image itself.

To validate the accessibility of a page's HTML, use an automated tool, such as the W3C's HTML validator - external link. The results are often overwhelming at first. Even developers who use professional web development software programs may find that their content does not validate as proper HTML.

Creating proper HTML is sometimes a challenge, but developers who make a habit out of creating proper HTML often learn to also become more conscientious about other aspects of web design, such as accessibility.

Test using a screen reader

From the perspective of blind users, testing with screen readers can be an important and effective way to identify accessibility and usability problems. However, some words of caution are in order.

• First, don't assume that screen reader accessibility means full accessibility. It may mean full accessibility for blind users, but this is only one type of user with one type of disability. Don't focus on screen reader accessibility to the exclusion of other aspects of accessibility or other disability types.
• Second, screen readers can be difficult to use, especially at first. Many developers wrongly assume that nearly everything on the web is completely inaccessible when they use a screen reader for the first time, because they are unfamiliar with the way the program works. They become unnecessarily discouraged and sometimes give up on accessibility altogether. There are two possible solutions to this problem. The developer must either learn how to use screen readers correctly, or must use a screen reader such as IBM Home Page Reader which is more intuitive to sighted users. For those who wish to learn to use JAWS, a list of JAWS keyboard shortcuts and IBM Home Page Reader keyboard shortcuts are available. The keyboard shortcuts of most screen readers are available in the help documentation of the respective software programs.
• Third, although screen readers have similar functionality, they are not exactly alike in terms of support for accessibility features. For the most part, if content is accessible to one screen reader, it is accessible to the others. However, there are exceptions to this statement. The problem is that these exceptions are not well documented, and can be difficult to discover. As new versions are released, some differences disappear, while others remain.

The purpose of these cautions is not to discourage the practice of testing content with screen readers. It is to allow developers to set reasonable expectations about this practice. Testing with screen readers can be a powerful way to evaluate the accessibility of web content to blind users, as long as developers are willing to devote some time to understanding how to use screen readers skillfully.

All major brands of screen readers offer trial versions that developers can use to test their web pages. Popular screen readers include JAWS, Window Eyes, HAL, and IBM Home Page Reader. The trial versions for both JAWS and Window Eyes last for several months and can be used for 40 minutes at a time. After 40 minutes, the user must reboot the computer in order to continue using the screen reader. This usually provides an adequate amount of time for developers to evaluate thier content without having to purchase the full versions of the software.

Consider these ideas and questions when testing web content with screen readers:

• First listen to the entire page without stopping. Did everything make sense? Did the screen reader access all of the content? Was the alternative text for images appropriate and concise? Did the alternative text convey the content and meaning of the image? Was the reading order of the content logical?
• Now try navigating the page with the screen reader. Are link labels descriptive? Were forms accessible via the keyboard? Were form labels included? If the page includes data tables, were data cells associated with headers? Did the navigation structure make sense? Was there an option to navigate within lengthy pages of content? Was content structure, such as headings and lists, correctly implemented? Was any multimedia accessible (i.e., did video have captions, audio have transcripts, Flash have an alternative, etc.)?

Conduct user testing

User testing can be one of the most powerful methods of evaluating the accessibility and usability of web content. In fact, the greatest benefit of user testing occurs when evaluators focus on the usability of the site to people with disabilities.

Most users with disabilities are very willing to give feedback if it will help increase the accessibility of your content to the disability community. Sometimes features of the site that developers believed would increase accessibility end up being very confusing or inaccessible. The key is to be willing to make changes based on user testing. Especially seek feedback on your navigation structure and use of language. These two things can pose huge accessibility barriers to a large group of individuals. As soon as their recommendations for changes have been made, have them test again and see if things are better. Encourage feedback from all of your site visitors.

If possible, seek feedback from several individuals with different types of disabilities. Individuals with disabilities vary widely in their level of comfort with computers, in their familiarity with assistive devices, and with other issues. The opinion of one person may be valuable, but it may also be a skewed representation of the experiences of the general population of users with disabilities.

One potential problem of relying on user testing is that these users may not be able to identify inaccessible content by virtue of the fact that they can't access it, and they may have no idea that they can't access it. For example, a person who is unable to use a mouse may feel that the navigation system is totally accessible by keyboard, but if the navigation system includes mouse-dependent drop-down menus, this person may never know that the drop-down menus exist at all, because the keyboard will not activate them. The person will be unaware that the drop-down menus were completely inaccessible.

Making Sense of the Evaluation Data

Once the data-gathering phase is complete, the challenge is to make sense of it all. In many cases it can be a daunting task. The list of errors and problems may be so extensive that it is difficult to know where to begin. The key is to organize the issues into a prioritized list.

Compile a list of issues and organize them according to themes and/or according to severity. Once the issues have been organized, it is a matter of following through with the plan.