Welcome!

Websphere Authors: RealWire News Distribution, Mark O'Neill, Jayaram Krishnaswamy, Bob Gourley, PR.com Newswire

Related Topics: Websphere

Websphere: Article

Verifying Web Site Accessibility

Verifying Web Site Accessibility

Are you confident that your site works correctly for someone using a text-to-speech browser that vocalizes Web page text? For someone using a device that instantly translates Web page text into Braille? For someone using a special device or software (such as voice recognition software) for navigation and input?

If not, you are taking two serious risks:

  • People with disabilities (approximately 19% of the U.S. population) might not be able to access your site.
  • If the site is produced for or by a U.S. government agency, you might be violating a federal law and could lose government contracts and/or attract costly lawsuits.

    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:

  • It allows you to test the entire project (or each new page or project element) without manually loading and configuring it in a different tool.
  • It expedites the correction process as well as part of the manual verification process. Double-clicking accessibility error or warning messages in the Task panel prompts WSAD to open the related source file in the Page Designer and place the cursor at the line containing the violation. You can then inspect and modify the source code in the Source mode (as shown in Figure 1), or switch to the Design mode to make modifications. Also, you can instantly render a page containing a definite or possible violation by switching to the Preview mode, and then inspect it without leaving WSAD.

    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:

  • Follow and verify specific click paths through the site, including paths that involve the submission of passwords or other specific user inputs. At the least, your verification should involve creating and testing several different versions of the possible click paths representing your use cases. For example, to verify the accessibility of the login functionality, you should submit both a valid and invalid username/password set. To verify the accessibility of the search results page, you should submit search criteria that returns zero results, a small set of results, and an extraordinarily large set of results. One way to streamline the path recording process is to use a tool that can create and test the actual user paths recorded in your log files. If creating paths through your site requires the submission of a large number of inputs, you can further streamline the process by using a testing tool that can create paths by reading inputs from a database or other data source.
  • Provide virtual users that automatically create new paths through the site. For most sites, manually creating and testing all possible permutations of every possible path through the site simply is not feasible. Automatic virtual users provide a way to significantly increase the coverage of your testing with little additional effort. You will get the most mileage from intelligent virtual users that can randomly generate inputs for forms whose options you want to exercise, as well as submit specific inputs for forms that require them (such as login forms). Ideally, you want to flush as many possible combinations of page elements, contents, and configurations that could be sent to user devices, then check whether these pages are accessible.

    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:

  • Invoke the possible user click paths manually, then inspect the pages created at each path step. If you click the same links and enter the same inputs as your users will, you should receive pages similar to those the users will encounter. However, if you are considering this method, be aware that 100% manual verification is typically considered tedious, time consuming, and error-prone.
  • Enlist the help of an accessibility testing consultant. Before agreeing to a contract, consider how the site will be tested and how much of the site will be covered by the specified testing method. Also, ensure that the consultant will test all of your site modifications as they are implemented and that this testing will be comprehensive enough to verify whether a small change in one part of the application causes accessibility problems that might ripple throughout other parts of the application.

    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

  • More Stories By Arthur Hicken

    Arthur Hicken
    Director of Business Development
    Parasoft

    As Director of Business Development for ParaSoft, Arthur Hicken works very closely with the company's upper management in making strategic business development decisions. He has been quoted in Business 2.0 and CNET news.com regarding Web site quality issues.

    Hicken has been managing ParaSoft's corporate Web site since the inception of the World Wide Web and has included on-line purchasing and product evaluation capabilities, as well as technology that ties standard databases and data source to Web based applications. Mr. Hicken has also worked on preparing a consumer based Internet site for the wireless Web. In addition, Mr. Hicken's experience also includes supervising database technology, data mining, data warehousing, database marketing, and he has developed a state-of-the-art internal database system.

    Hicken has taught at College of DuPage in Illinois as well as developed and conducted numerous in-house sales and technical training courses at ParaSoft.
    He has also developed and instructed several training courses for ParaSoft clients.

    More Stories By Cynthia Dunlop

    Cynthia Dunlop is the lead technical writer for Parasoft.

    Comments (1) View Comments

    Share your thoughts on this story.

    Add your comment
    You must be signed in to add a comment. Sign-in | Register

    In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.


    Most Recent Comments
    Mayank Shah 04/01/08 05:00:45 AM EDT

    Can someone please suggest how to test all the accessibility guidelines manually.