Developing a Section 508 Compliance Strategy for Web Site Accessibility

(This post is a continuation of my article on Section 508 compliance for Web accessibility.)

I've been working with a federal government agency to validate Section 508 compliance for their online registration form. Before this process began, had you asked me if our attendee-facing web pages were Section 508 compliant, I would have replied, "Absolutely, yes." But working with Angela Hooker (http://www.angelahooker.com/) on this project, I've learned a few things about web accessibility:

1. You cannot rely on automated testing tools, like WebXact, to insure Section 508 compliance.
2. You must validate compliance with multiple applications geared toward different audiences. For example, try JAWS for sight-impaired users, navigate without a mouse to simulate motor-skill deficient users, and view pages with a lower resolution for technologically-disadvantaged users.
3. Complying with the spirit of the law (i.e., to provide universal accessibility to Web content) requires an expert who can show you the end users' experience, beyond strict compliance with the letter of the law.

I also learned that the World Wide Web Consortium (W3C) and International Organization for Standardization (ISO) are both following the United States' lead in web accessibility guidelines, and in the future Section 508 regulations will be rolled into the international standards embodied in the W3C Web Content Accessibility Guidelines 2.0 (WCAG). Adopting Section 508 compliance now gives you a head start on interoperability with the next generation of web browsers and platforms (such as iPhones and tablet PCs).

Specific Issues with Section 508 Compliance

Over the past month, I've identified and resolved a few issues with our Section 508 compliance of the online registration forms:

• We disabled a client-side Javascript function, which hid payment fields that did not apply to your selected payment method. Although this area passed the WebXact screening, the script confused the JAWS screen reader and resulted in content being read out of order.
• We added text and hyperlinks designed specifically for blind users. We inserted these instructions in a white font color (on a white background), so that they would be "invisible" and not detract from the experience of sighted users.
• We replaced a web mail interface with a simple "mailto" link. The web mail interface had the same look and feel as the registration form, but opening an e-mail message in your client application (such as Outlook) made us 508-compliant.

Looking at the bigger picture, however, we don't want to have to deal with Section 508 issues one form at a time. So I've been working with our IT, Development, and QA groups in order to develop a systematic approach to build, maintain, and audit Section 508-compliant Web applications.

Developing a Company Policy for Section 508 Compliance

The goals of our Section 508 compliance policy are to:

• Meet U.S. Federal regulations for our public sector clients (comply with the letter of the law)
• Produce Web sites that are universally accessible (comply with the spirit of the law)
• Educate our staff on Section 508 requirements
• Adopt international standards for more consistent development of Web applications

Why be Section 508 compliant?

• It is a law for U.S. federal government (and many state/local government) agencies, representing about 25% of both our current and potential customer base.
• Section 508 compliance is spreading beyond the public sector, becoming an internal requirement for major corporations and non-profit organizations
• Section 508 regulations are being merged into the W3C Web Content Accessibility Guidelines (WCAG 2.0) and ISO standards, so compliance with these HTML standards help us operate on future web browsers and platforms (PDAs, phones, etc.)
• Section 508 is a design standard for universal accessibility, just as PCI Compliance is a design standard for financial data security. Following Section 508 guidelines can help multiple developers in a globally-distributed work environment produce consistent, quality HTML code.

Section 508 Compliance Policy

Our policy for Section 508 compliance is:

1. 100% compliant on the registrant-facing side (i.e., Forms and Web Sites)
2. Strive for compliance with documentation and Help files, or offer a 508-compliant option
3. Strive for compliance on Admin side (intranet application), but not at the expense of harming the UI experience for sighted users.

"Strive for compliance" means that where possible on the Admin side and Help files, we should write HTML to the standards of the W3C WCAG and Section 508 guidelines. These standards are international best practices and insure maximum interoperability of HTML as the web moves to new browsers, mobile devices, kiosks, etc. So all images should have ALT tags, all form fields should have ID attributes with Label tags, all data tables should have header descriptors (as defined in the standards), all HTML should be checked for syntax errors such as end tags and tag nesting.

But for areas where meeting 508 compliance would result in an inferior UI for sighted users, we can make an exception in the admin side and Help files. An example here is the Help files "Table of Contents", which is not 508 compliant but has a much better UI for sighted readers through its dynamic interface.

In cases where compliance will not be achieved, then we should try to offer a 508-compliant alternative. For example, Robohelp allows us to save Help files in a separate 508 compliant format, which we can add to our Certain Support Center for vision-impaired users.

Section 508 Compliance Implementation

Many teams will work together to build, maintain, and certify our Section 508 compliance.

Developers and QA engineers:

• Read the Section 508 Rules
• Take Jim Thatcher's Tutorial on developing accessible Web applications and apply the lessons learned when writing HTML

QA Testing:

• For as many releases as possible (i.e., if automated and feasible), we should validate Section 508 compliance on a "sample" form and web site with Watchfire WebXact (included in HP Mercury testing tool)
• This automated tool is a good first pass for testing - it gives the specific line number of problems, along with a proposed solution for the developer

Note that the automated testing tools may return "508 Compliant" when a web site is not truly compatible with the advanced screen readers that disabled users actually employ. In order to comply with the spirit of the law, further User Acceptance Testing is needed.

User Acceptance Testing (UAT)

In order to comply with the spirit of accessibility, UAT should follow the guidelines outlined in Section 3 of Jim Thatcher's tutorial for checking the accessibility of our web pages.

• With major releases, or once per quarter, UAT should run through a comprehensive "standard" form and web site with the JAWS screen reader (the 40 minute version is adequate for this) - this exemplifies how vision-disabled users experience the web site
• UAT should navigate the sample form and web site without using a mouse (using Tab and keyboard only) - this exemplifies how motor-disabled users experience the web site

Compliance/Audit (IT)

• We should conduct an annual or biannual audit with an independent third party expert, e.g. Jim Thatcher (http://www.jimthatcher.com/) or Angela Hooker (http://www.angelahooker.com/)

One deliverable from the audit is for the consultant to produce a Section 508 compliance report for sales to be able to give to clients and prospects instead of having to conduct multiple internal audits one at a time.