STC Usability SIG Newsletter
Usability Interface

Applied Theory:
Working Toward an Accessible Web Site

By Kim McConnell, Central Ohio Chapter

With the passage of Section 508 and the efforts of the World Wide Web Consortium (W3C), interest in Web site accessibility continues to increase. Web designers and Web content developers are finding that knowledge in Web accessibility is becoming essential to be marketable to government contracts and private industry since accessibility is becoming a best practice, and in some cases a legal requirement, in Web development.

This article is written for those who already have a general knowledge about the reasons for, and the techniques of, designing accessible Web sites. In this article, I will share the steps that I have taken to work toward transforming a Web site that I manage to one that is accessible according to the W3C recommendations. Detailed information about Section 508, the W3C, and specific recommendations and techniques are covered in an article entitled "What Makes a Web Site Accessible" that appeared in the January - March 2003 Issue of Achieve!, the newsletter of the Special Needs SIG (www.stcsig.org/sn/PDF/achieve_jan03.pdf). Links to other accessibility resources are listed in the newsletter, as well.

Background

Ensuring the rights of people with disabilities, in particular their right to equal access, is somewhat of a personal quest for me. My youngest son, who is seven years old, was involved in an accident when he was a baby that left him permanently physically and mentally disabled. When his accident occurred in 1997, I quit working so I could take care of his medical needs. In March of 2001, I returned to work by contracting with the Ohio Legal Rights Service (OLRS). OLRS is an independent agency of the State of Ohio with the purpose of protecting and advocating for the rights of Ohio citizens with disabilities. I was hired to manage a Web site that they were administering for a project called the Family Support Collaborative (FSC). The FSC focuses on the needs of Ohio families who have children with disabilities.

A few months after I began managing the FSC Web site, Section 508 of the Federal Rehabilitation Act was implemented. Section 508 is a law that requires Federal government agencies to ensure that their information technology is accessible to employees and members of the public with disabilities. This includes Web sites. Since OLRS is a protection and advocacy agency, they had a special interest in how Section 508 impacted people with disabilities. Although Section 508 is a requirement for Federal agencies, advocates feel that there will be a "trickle-down" effect to the State agencies and, in some instances, to private industry. Our agency wanted to be proactive and to be an example to other agencies of how a State government Web site could be usable, accessible, and attractive.

The agency asked that I research Section 508 and Web accessibility in general and to see what we needed to do to have an accessible Web site. My goal was to create a successful experience for the users of our Web site, regardless of their physical and mental abilities. The following is a summary of the steps I took to achieve this.

There are some things to keep in mind as you read through these steps. The FSC Web site is:

• An information and referral site, not an e-commerce site
• A medium sized site, averaging 35,000 hits per month
• Funded through a grant from the Ohio Developmental Disabilities Council
• Administered by the State government agency, Ohio Legal Rights Service
• Managed by one person who works part-time; this person (me!) researches, writes, and manages all aspects of the site

Although your Web site may differ from the construction of the FSC Web site, I think these steps, when applied in general terms, are helpful for all Web site administrators.

Step 1: Get Approval

I had one huge advantage in the beginning-automatic buy-in from management. Because the Family Support Collaborative is a government protection and advocacy agency for people with disabilities, the agency saw the value of investing time and resources into Web site accessibility. Unfortunately, that is usually not the case for people who work in private industry. You might have to go to steps 2 and 3 first to help build your case to present to management. Books, such as Constructing Accessible Web Sites (Glasshaus Ltd, 2002), Web Accessibility for People with Disabilities, (CMP Books, 2000), and Maximum Accessibility (Addison-Wesley, 2003) offer sections that provide reasons and strategies for proving the importance of accessibility to management.

Step 2: Conduct Research

The Internet was my first stop. For Section 508 information, I found "Section 508: The Road to Accessibility" at www.section508.gov. For Web accessibility recommendations and techniques, I found the Web Accessibility Initiative (WAI) of the W3C at www.w3.org/WAI/. I read several books, such as those listed in Step 1, and networked with others in the profession through local STC chapter meetings and listservs.

I found an excellent online training class, Accessible Web Design, through the International Webmasters Association (IWA) at www.iwaguild.com. Accessible Web Design is a seven-week course that offers a hands-on experience to learning about Web site accessibility. You can take the course whether or not you are a member of the IWA. It is well worth the investment.

Step 3: Identify Issues

I used checklists to identify accessibility issues, such as the "Checklist of Checkpoints for Web Content Accessibility Guidelines 1.0" (www.w3.org/TR/WCAG10/full-checklist.html) and the "Section 508 Summary Table" (www.icdri.org/section508/section_508_summary_table.htm). This gave me an idea of how involved it would be to re-design our Web site in order to implement accessibility features and helped me to prioritize what should be changed first. Also, it was a great way to show management where we presently stood with our Web site and accessibility. Fortunately, the issues that I discovered for the FSC Web site were not going to require an all out re-design. Incorrect use of HTML mark-up, improper use of tables, and an over-reliance on PDF documents were the main problems.

After identifying the problems I found in the checklists, I consulted the full recommendations, such as those found in the "Web Content Accessibility Guidelines 1.0" (www.w3.org/TR/1999/WAI-WEBCONTENT-19990505/) published by the WAI. I decided to work toward Level A of the WAI recommendations, which meant that we would be compliant with all Priority 1 checkpoints of the recommendations (Level AAA is the highest a site can achieve, which means that all Priority 1, 2, and 3 checkpoints are met). For our circumstances and available resources, it seemed more feasible to work toward a fully accessible Web site in phases, rather than trying to do it all at once.

I began implementing the changes and eventually arrived at the point where the Web site was at a Level A compliance level. At that point, I needed to verify that the changes I had made were on target.

Step 4: Perform a "Tech Check"

When the changes were made, I used several tools to help do a "tech check" - in other words, to check for incorrect HTML mark-up and accessibility issues that can be detected by accessibility testing tools. Some tools I used (and continue to use) were:

• A-Prompt (University of Toronto) offers a free online accessibility-testing tool. (aprompt.snow.utoronto.ca/)
• Bobby (Watchfire) offers a free on-line accessibility-testing tool. A downloadable version is available for purchase. (bobby.watchfire.com/bobby/html/en/index.jsp)
• HomeSite (Macromedia) is an authoring tool that is an excellent HTML validation tool and provides helpful features to aid in creating accessible pages. (www.macromedia.com/software/homesite/)

One important point to remember is that using these tools will simply assist a content developer. We all know that true usability testing, including accessibility testing, goes beyond the tools and onto the user's actual experience.

Step 5: Conduct Usability Testing

This is the most important part of the process. The user's actual experience is what determines whether a site is truly accessible. Accessibility testing uses the same techniques that are commonly used with usability testing: audience analysis, proper navigational aids, writing style, and overall design principles.

I completed the following activities to perform usability testing:

• Used a voice/text browser. I Used HomePage Reader by IBM (www-3.ibm.com/able/hprtrial3.html) to test how the pages rendered for a person who uses a voice browser. A 30-day trial version is available for download. The purchase price is quite reasonable (approximately $150), and I was pleased enough with the performance of the product that I requested a copy of the software so I could test pages in the future. I also used Lynx Viewer (www.delorie.com/web/lynxview.html), a free online tool that displays a text-only version of a Web page.
• Performed keyboard techniques. I used keyboard techniques, such as tabbing through a page (tabbing through a page usually goes in the same order as a voice browser would read), were used for quick tests.
• Changed computer settings. I turned off style sheets, images, and frames settings to see how the page rendered. Many people, especially those with disabilities, turn these features off in order to read a page better. Also enabled the ALT text expansion feature to see how graphic images were labeled.
• Conducted user testing. I used volunteers with and without disabilities to test the usability of the Web site. Because we are an agency that is in regular contact with people who have disabilities, we have been fortunate to find willing participants to test the Web site. We also have a staff attorney who is blind and uses the JAWS screen reading program. When her schedule permits, we ask her to check the Web pages or to perform a specific task. As with all user testing, having a range of people with varying computer and Internet experience is necessary in order to get a good idea of the usability of a site; therefore, we also ask families who use the site to test its usability.

Step 6: Create an Accessibility Statement

Many Web sites that achieve a level of accessibility choose to display a logo of compliance on their Web site, such as the "Bobby Approved" logo or one of the WAI's logos. Displaying these logos is a visual cue showing the site owner's level of commitment to accessibility for people who visit the Web site. Note, however, that placing these logos on a site is at the discretion of the site owner, not the entity that provides the logo. Therefore, it is reasonable to believe that some sites that display these logos may not be truly accessible.

For our site, we chose to display a WAI logo and to create an accessibility statement. We felt an accessibility statement was important since the statement would detail our efforts for people who visit the site and would serve as documentation for internal purposes. The content of the accessibility statement lists the efforts we have taken toward Web accessibility, identifies areas that may not be compliant, and gives Web visitors direction on how to contact us with accessibility issues. The statement can be read at www.state.oh.us/olrs/fsc/ASP/Accessibility.asp.

Step 7: Review and Revise

Web site accessibility is an on-going process. It is not something that you can simply check off of a "To-Do" list. It is a long-term commitment. The ultimate goal with our Web site is to work toward a Level AAA WAI status and 508 compliance.

For the short term, we are working on the following goals to be completed by the end of 2003:

• Redesign the main Web site of OLRS. Presently, the FSC Web site is managed separately.
• Continue to assess and correct recent features that were added to the FSC Web site that are not entirely accessible.
• Implement a formal usability testing procedure.
• Achieve 508 compliance status.

Conclusion

My experience with working toward an accessible Web site is far from over, and I realize that my experiences are much different from those who manage larger sites or e-commerce sites. I think, however, that the basic steps described in this article - getting approval, conducting research, identifying issues, performing tech checks, conducting usability testing, and creating an accessibility statement - can be applied to all Web site development to a certain extent.