You can make your site accessible to people with disabilities (and thus mitigate these risks) by following the guidelines the U.S. government and the World Wide Web Consortium (W3C) have established for making Web sites accessible in a wide variety of contexts. Ensuring the accessibility of a static site or even a simple dynamic site is fairly straightforward - you automatically verify whether the pages comply with many accessibility guidelines, then manually verify compliance with the remaining guidelines. However, verifying the accessibility of the highly dynamic sites that WebSphere developers typically create is more challenging. If the pages change depending on variables such as username/password, user preferences, click paths, time, and so forth, how do you verify that the site will be accessible to every user all of the time? This article attempts to provide a practical solution to those challenges.

Understanding the Standards
You can ensure a basic level of accessibility by following accessibility guidelines during design and implementation. There are two main sets of Web site accessibility guidelines: the U.S. government's Section 508 Web Standards and the Web Accessibility Initiative's Web Content Accessibility Guidelines. Both sets of guidelines generally prompt you to follow design and navigation best practices and add optional or redundant elements to ensure that the site functions on a variety of different devices and settings. In fact, following these guidelines not only makes a site accessible to people with disabilities, but also makes it more accessible to users on desktop systems, PDAs, Web-enabled phones, kiosks, and other existing and upcoming internet devices.

The Section 508 amendment to the Rehabilitation Act requires that any technology produced by or for U.S. government agencies must be accessible to people with disabilities. Section 508 Web Standards detail 16 specific requirements that a Web site must satisfy to comply with Section 508 legislation. Most of these guidelines focus on ensuring graceful page transformations to a variety of devices and making content understandable and navigable on a variety of devices. Although these guidelines were designed specifically for federal agencies and vendors producing technology for federal agencies, they have become the standard that many Web developers use to gauge site accessibility. These guidelines are listed in the Section 508 Guidelines sidebar.

The Web Accessibility Initiative (WAI), a W3C organization committed to making the Web more accessible for people with disabilities, developed the Web Content Accessibility Guidelines. These guidelines are similar to Section 508 guidelines because Section 508 guidelines were largely based on the WAI guidelines. These guidelines are listed in the WAI Guidelines sidebar.

Accessibility Testing Fundamentals
You can automatically verify compliance with the majority of the Section 508 and WAI guidelines by using an automatic verification tool. However, while accessibility testing tools can be a tremendous aid in verifying accessibility, a gold stamp from even the best verification tool does not mean that the site is actually accessible. Some degree of human inspection is always required to fully guarantee compliance because the criteria for some guidelines are too subjective and/or complex for today's systems to evaluate. For example, machines cannot automatically verify WAI Guideline 13. ("Provide clear and consistent navigation mechanisms - orientation information, navigation bars, a site map, etc. - to increase the likelihood that a person will find what they are looking for at a site.")

For both automatic and manual verification, you can save yourself considerable time and grief by starting your testing early in the development process - before accessibility problems have the opportunity to multiply as the result of code reuse or interactions.

Automatic Inspection
The W3C maintains a list of tools that automate many aspects of accessibility verification; this list is available at www.w3.org/WAI/ER/existingtools.html.

The automatic verification process is simple - provided that your tool can correctly access the versions of site pages that will be sent to client devices (we discuss specific strategies for loading and testing dynamic pages in the next section). Assuming that the verification tool you select has a way to access the various pages you need to test, you can verify compliance with many accessibility guidelines by telling the tool how to find those pages, and then clicking the Start button. The tool will then request the specified pages, load the code delivered in the responses, and then analyze the code to determine whether it violates any of the Section 508 and/or WAI accessibility guidelines it is configured to enforce. After each accessibility test, the tool will report code that violates the selected accessibility rules. Messages vary by tool, but typically include a description of the violated guideline, as well as the filename and line number in which the violation occurs.

WSAD developers can simplify the accessibility verification and improvement process by selecting an accessibility verification tool that integrates into the WSAD environment. This integration offers two main benefits:

If you want to guarantee that new code is verified immediately after it is added, you can configure your tool to automatically perform accessibility testing daily. Setting up such an automatic testing infrastructure typically involves writing a simple command-line script that runs the test, then configuring a cron job or other scheduling program to run this test at the specified time each day.

Manual Inspection
As mentioned in the introduction to this section, manual inspection is required to check compliance with some guidelines, and no site can be deemed "accessible" without some degree of manual inspection. For example, tools cannot make the subjective analysis required to determine whether a page is readable when rendered without a stylesheet or whether the site's navigation aids are clear and consistent. However, tools can help you pinpoint some of the elements that require human inspection.

Most accessibility testing tools can be configured to report occurrences of elements (such as links to stylesheets) that indicate that the related page requires human inspection and possibly additional modification. These warning messages relieve you from having to search for each of these elements.

In addition, some accessibility testing tools reduce the burden of manual inspection by automatically checking custom accessibility guidelines. For example, imagine that you discover a certain company logo used on your site does not provide the necessary contrast for someone with color deficits or someone viewing the site on a black and white screen. Instead of manually searching for all occurrences of this logo, you could automatically identify all pages that use this logo by designing and applying a custom guideline that detects any occurrence of this logo.

Verifying Dynamic Sites
Accessibility verification is more challenging if your site is truly dynamic (e.g., pages change according to user preferences, variables, time, inputs, and so on) and your verification tool cannot reach all possible page instances by following links or crawling the site. However, dynamic sites are by no means exempt from accessibility standards.

The W3C states:

Dynamically generated pages are usually assembled from one or more templates that provide common layout and navigation features, and content provided automatically from a database or other content management system. To achieve full conformance, the accessibility of both templates and generated content must be evaluated. It is not sufficient to evaluate only templates: content may also contain markup, or be required to contain markup in order to be accessible....If all dynamic content cannot be evaluated, generate broadly representative samples, capture content, and test the output.

(More information is available at www.w3.org/WAI/eval.)

You can find and control many accessibility problems at their source by inspecting templates (with the tools discussed in the previous section) and content management system contents (if applicable), then fixing problems found before you generate and test any actual pages. However, since the final determination of accessibility is based on the code/content delivered to client devices, all testing of dynamic sites must ultimately verify the code/content delivered to a client. This means that if your e-commerce application's shopping cart page can be created a thousand times a day and can be created differently each time it is invoked, you need to verify that a "broadly representative" sample of those possible pages are accessible.

To verify a broadly representative sample of your dynamic pages, you must create and test a number of specific instances of the precise pages that your users are likely to encounter. However, this can be challenging. With most dynamic sites, specific state and input variables are required to invoke certain pages. For example, if you want to invoke and test a checkout page, you must first set valid username and password variables and have at least one item added to a shopping cart. If you want to test the pages returned for both valid and invalid logins, you must set the inputs necessary to create those pages.

Many accessibility testing tools do not allow you to specify the path or inputs required to invoke specific pages, and thus are unable to accurately verify many of the pages that might be sent to user devices. For example, say that you are building an e-commerce site and you want to verify the accessibility of a page built based on the user's past purchases and browsing patterns. Assume that this page will only display the customized information if a valid user login and password are submitted. If you submit the same URL to a tool that does not allow you to enter specific inputs, the tool will not be able to create the customized page, and will instead create and test a generic version of the page. This can be especially troublesome on sites that implement frames. Often, one frame might alter the contents of another frame; if your testing tool loads just the URL of one of the subframes (rather than the complete series of frames), your test results might be seriously skewed.

If you have a dynamic site and want to automate as much of the verification process as possible, look for a tool that can:

If you are unable to access a tool that can help you with your specific verification needs, you have two main alternatives for accessibility verification:

Conclusion
Verifying your site's accessibility is mandatory if you are producing technology for a government agency, and it is highly recommended if you want to ensure that your site does not exclude people with disabilities or people accessing your site in a variety of contexts. Automated tools can significantly facilitate the accessibility verification process for even very dynamic sites. However, it is important to realize that today's programs and systems are simply not intelligent enough to verify every accessibility requirement, so tools alone cannot guarantee a site's accessibility. By carefully designing your site, then performing both automated and manual accessibility inspections from the earliest possible phases of the development process, you should be able to efficiently guarantee that your site is accessible to everyone who wants to use it.

One way to facilitate the accessibility verification process is to test your site with Parasoft WebKing, which automatically identifies code that positively or possibly violates Section 508 and WAI guidelines. This tool is specifically designed for testing dynamic sites, but works equally well with static pages. To facilitate verification of dynamic sites, it automatically creates, follows, and verifies the most frequently accessed paths through the site (based on your log file) or any specific paths you record. In addition, WebKing automatically creates and verifies new paths through the site for increased testing coverage. Inputs for password pages and other forms can be specified prior to the test, or generated automatically. In addition to its accessibility verification features, the tool also automates functional testing, regression testing, and load testing to prevent and expose errors throughout the Web development process. WebKing has completed the WSAD integration process and has applied for Ready for WebSphere validation.

SIDEBAR
Section 508 Guidelines

Here is a list of the Web-related guidelines in Section 1194.22 of Section 508:

a) A text equivalent for every nontext element shall be provided (e.g., via "alt", "longdesc", or in element content).
b) Equivalent alternatives for any multimedia presentation shall be synchronized with the presentation.
c) Web pages shall be designed so that all information conveyed with color is also available without color, for example from context or markup.
d) Documents shall be organized so they are readable without requiring an associated stylesheet.
e) Redundant text links shall be provided for each active region of a server-side image map.
f) Client-side image maps shall be provided instead of server-side image maps, except where the regions cannot be defined with an available geometric shape.
g) Row and column headers shall be identified for data tables. h) Markup shall be used to associate data cells and header cells for data tables that have two or more logical levels of row or column headers.
i) Frames shall be titled with text that facilitates frame identification and navigation.
j) Pages shall be designed to avoid causing the screen to flicker, with a frequency greater than 2Hz and lower than 55Hz.
k) A text-only page, with equivalent information or functionality, shall be provided to make a Web site comply with the provisions of this part, when compliance cannot be accomplished in any other way. The content of the text-only page shall be updated whenever the primary page changes.
l) When pages utilize scripting languages to display content or to create interface elements, the information provided by the script shall be identified with functional text that can be read by assistive technology.
m) When a Web page requires that an applet, plug-in, or other application be present on the client system to interpret page content, the page must provide a link to a plug-in or applet that complies with §1194.21(a) through (l).
n) When electronic forms are designed to be completed online, the form shall allow people using assistive technology to access the information, field elements, and functionality required for completion and submission of the form, including all directions and cues.
o) A method shall be provided that permits users to skip repetitive navigation links.
p) When a timed response is required, the user shall be alerted and given sufficient time to indicate more time is required.

To view a more detailed explanation of these guidelines, visit www.section508.gov/index.cfm?FuseAction=Content&ID=12#Web

SIDEBAR
WAI Guidelines

Here is a list of the WAI Guidelines (each of which is divided into a number of specific "checkpoints"):

1.   Provide equivalent alternatives to auditory and visual content.
2.   Don't rely on color alone.
3.   Use markup and stylesheets and do so properly.
4.   Clarify natural language usage.
5.   Create tables that transform gracefully.
6.   Ensure that pages featuring new technologies transform gracefully.
7.   Ensure user control of time-sensitive content changes.
8.   Ensure direct accessibility of embedded user interfaces.
9.   Design for device-independence.
10.   Use interim solutions.
11.   Use W3C technologies and guidelines.
12.   Provide context and orientation information.
13.   Provide clear navigation mechanisms.
14.   Ensure that documents are clear and simple.

To view a more detailed list of these guidelines and their checkpoints, visit www.w3.org/TR/WCAG10