2004 Conference Proceedings

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


EVALUATING WEB SITE ACCESSIBILITY: A SEVEN STEP PROCESS

Presenter(s)
Jared Smith
WebAIM (Web Accessibility in Mind)
Center for Persons with Disabilities
Utah State University
United States
Email: jared@cpd2.usu.edu

Paul Bohman
WebAIM
6807 Old Main Hill
Logan, UT
Email: paulb@cc.usu.edu

Introduction

Web Accessibility is becoming a very critical topic in information technology. Assistive technologies are allowing individuals with disabilities the power to access Web content when and how they desire. Most Web developers and designers are aware of the issues of Web accessibility, but do not know where to begin implementing accessibility. The first step to creating an accessible Web site is evaluating the current accessibility level of the existing site. This hands-on workshop will teach participants a seven step process for evaluating the accessibility of their current Web site. Along the way, they will learn the basics of accessible Web design, assistive Web technologies, and how individuals with disabilities use the Web.

The Seven Step Process

1. Validate your HTML

This first step happens to be one of the most difficult, especially for people who are not very comfortable with HTML. It is, however, a very important step toward Web accessibility. Proper, standards-based HTML lends itself toward accessibility. Assistive technologies rely on proper HTML more so than most Web browsers. Valid HTML has many other benefits as well, including a decreased likelihood for cross-browser differences or incompatibilities and better support for emerging technologies.

To validate the accessibility of your page's HTML, use the W3C's HTML validator at http://validator.w3.org/. The results are often overwhelming at first. Most people are not even aware of the intricate rules and standards for HTML use. Even if you are using professional Web development software programs it is likely that your page will not validate as proper HTML when first validated. Be sure to read the explanations as to why the page does not validate as proper HTML. Learn about the common HTML mistakes and do what you can to fix them.

Creating proper HTML is a challenge, but one that every Web developer should take upon him or herself. When you understand the rules of HTML, you are much more likely to design more usable and accessible Web content.

2. Validate for accessibility

Once you have created proper HTML within your page, many of your accessibility issues will be gone, because proper HTML requires many accessibility techniques, such as alt text. The next step is to find other accessibility issues that may be present in your page. This is where automated accessibility tools come into play.

The Wave accessibility tool is a great place to start - http://www.wave.webaim.org/. The Wave provides useful information about accessibility features and errors within your page. It is designed to facilitate the design process by adding icons to a version of your page. The icons represent structural, content, usability, or accessibility feature or problems within your content. You can easily see the exact location within your page where an error is present.

The Wave (or any other software-based validator) cannot check all accessibility issues, but it checks nearly everything that can possibly be checked in an automated process. As soon as you have fixed the errors and applicable warning from the Wave, you may want to validate your page using other accessibility validators, such as Bobby (http://bobby.watchfire.com/) to get another way of looking at accessibility feedback. If you need to validate or audit the accessibility of an entire site, there are many evaluation tools you can use, including HiSoftware's line of products (http://www.hisoftware.com/) or InFocus (http://www.ssbtechnologies.com/).

3. Check for keyboard accessibility

This step is very easy. Just access the page and make sure that you can navigate through the entire Web page using the tab key. Ensure that every link and form item is accessible and that all forms can be filled out and submitted via the keyboard. If any content is displayed based upon mouse actions, make sure the content is also available using the keyboard.

4. Test in a screen reader

It is a great idea to have a copy of a screen reader available for testing. I suggest IBM HomePage Reader because it is easy to use and learn, whereas other full-featured screen readers are more expensive and have a very steep learning curve. 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 equivalent enough to 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.)?

5. Check your pages for WCAG compliance

Become familiar with the Web Content Accessibility Guidelines - http://www.w3.org/TR/WAI-WEBCONTENT/. The WCAG are a very complete set of accessibility guidelines. They are so complete that sometimes it is nearly impossible to comply with them. Though some of the guidelines are rather vague and some are outdated, they will give you a good idea of what it takes to be truly accessible. Manually evaluate your page against these guidelines. The WCAG guidelines are broken into three priority levels, based upon level of importance or impact on accessibility. At very least, try to meet the Priority I and Priority II guidelines. The Priority III guidelines are more of a wish list for accessibility, but contain some very important items that should be included whenever possible. The Wave (http://www.wave.webaim.org) can alert you of non-compliance with many of the WCAG guidelines.

6. Conduct user testing

One of the best ways to determine the accessibility of your pages is to get feedback from individuals with disabilities. Most are very willing to give you feedback if it will help increase the accessibility of your content to the disability community. Sometimes features of the site that you believed would increase accessibility end up being very confusing or inaccessible. 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.

7. Repeat this process

Web accessibility is a continual process and one that should be evaluated often. Each time you update or change content, quickly run through the previous 6 steps. You will quickly get very good at them and eventually you will understand how to both evaluate and create accessible Web content.

Acknowledgements

Web Accessibility In Mind (WebAIM) is administered in K-12 settings through a grant provided by the Office of Special Education Programs

(OSEP) of the Office of Special Education and Rehabilitative Services

(OSERS) and in Post-secondary Education settings through a grant provided by the Fund for the Improvement of Postsecondary Education

(FIPSE) Learning Anywhere Anytime Partnerships (LAAP).


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


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