2003 Conference Proceedings

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


FAST TRACK TO WEB ACCESSIBILITY USING A TEMPLATE-BASED DESIGN STRATEGY

Presenter
Paul Bohman, M.S.
WebAIM, Utah State University
Center for Persons with Disabilities
6801 Old Main Hill
Logan, UT 84322
Phone: 435-797-7138
Fax: 435-797-3944
Email: paulb@cpd2.usu.edu

Introduction

As Web developers learn more about the need for accessible Web sites, they can sometimes feel overwhelmed by the perceived enormity of the task. This perception is more accurately characterized as a misconception, though, since even minor changes to Web sites can sometimes dramatically improve their accessibility. Unfortunately, developers often miss the opportunity to make even these small changes because they are unsure where to start or what, out of all aspects of their design, they should fix first. Feeling overwhelmed, some developers avoid or abandon the issue entirely. Part of the perceived difficulty stems from the misconception that every part of each individual Web page must be fixed individually, separate and apart from the other pages. In reality, most Web sites use a limited number of templates (often between one and three) in which the contents of the individual pages reside. When the templates are fixed, so are most of the problems on all of the pages that use the templates. Thus, by fixing only a limited number of files, most of the site's accessibility problems disappear. Once Web designers understand the role that templates play in accessibility, the task seems less overwhelming, because they have less to fix than they originally thought. One of the keys to implementing a practical and sustainable Web accessibility effort, then, is to adopt a clearly-defined, prioritized, template-based design strategy.

The Strategy

The strategy presented here applies most directly to the process of fixing the accessibility problems of existing sites, although the same basic approach can be adapted to the process of designing sites from scratch. In fact, the process itself is iterative, and developers should periodically reassess their sites using a strategy such as this one. This strategy has five basic steps:

  1. Evaluate the current site
  2. Fix the easy issues on the home page
  3. Fix the template(s)
  4. Fix all of the remaining HTML-related issues, starting with second-level pages
  5. Fix all non-HTML issues

Each of these steps is important to consider, although not all steps are equally relevant to all sites. For example, while some sites use a mixture of HTML, Flash, video, and other Internet technologies, other sites use only HTML. Such HTML-only sites could ignore the fifth step in this strategy. Even so, this strategy is a useful method for categorizing and prioritizing the main tasks that are necessary in order to make a site accessible to people with disabilities.

Step 1: Evaluate the Current Site

The first step is to evaluate the current site with a combination of automated tools and focused human testing. Such a combination is necessary because neither approach, by itself, can be considered accurate or reliable enough to catch every type of error.

Automated tools are great for pointing out missing elements, such as alt text, frame titles, table headers, form labels, and the like. They are not as good as human testers at evaluating the quality of elements when they are present. They cannot detect inaccurate alt text, confusing frame titles, inappropriate table headers, or ambiguous form labels, for example. Some tools generate reports, some provide visual feedback, and others use a more wizard-like interface. Some can evaluate only one page at a time, while others can spider through and evaluate entire Web sites. It does not matter which automated tool the developer uses, as long as the developer is able to make use of the results generated.

Human testers should evaluate the site against a specific standard, such as the Web Content Accessibility Guidelines 1.0(i) or Section 508 of the Rehabilitation Act of 1998(ii). The testers can use a checklist format(iii) of their chosen guidelines, rather than the full document, to simplify the evaluation process. In addition, testers will need to clarify how the guidelines are to be interpreted in situations where there might be disagreement between testers. Once the testers have agreed upon a standard and its interpretation, they should document all of the accessibility problems that they find on the site, being careful to differentiate the problems that exist in the templates versus those that exist outside of the templates. In some cases, where sites are prohibitively large, or where time is an issue, the testers may wish to limit their tests to the templates, the home page, and the pages to which the home page links directly. These pages are considered top priority.

Apart from evaluating the site against published standards, testers should perform a general usability review of the site, from the perspective of those with visual, hearing, mobility, and cognitive disabilities. At a minimum, testers should ensure that Web content (including the navigation system) is:

Step 2: Fix the Easy Issues on the Home Page

A site's home page is likely to be its most visited page, and therefore warrants the most attention from the developer at the beginning of the accessibility repair process. Based on the information gleaned from the automated and human testing processes, the developer should immediately fix all of the easy issues on the home page (e.g. alt text, frame titles, table headers, form labels, etc.) , ignoring, for the moment, any of the more complicated issues that may exist (Flash, multimedia, mouse-dependent JavaScript).

In some cases, the home page is a part of the template system which exists throughout the site. In other cases, the home page is unique unto itself. Either way, developers should first concentrate their effort on the home page. If the home page is part of a template system, then developers will have a head start on step three of this process. Even if not a part of the template system, the home page needs to be fixed, and it needs to be fixed first.

Step 3: Fix the Templates

Once the developer has applied the easy fixes to the home page, it is time to concentrate on the templates. Some templates are static, such as Dreamweaver templates. Others are dynamic, such as those created in JSP, PHP, Cold Fusion, or other server-side scripting languages. Whether they are static or dynamic is irrelevant. The end result in both cases is nothing more than HTML. It is simply a matter of ensuring that the resultant HTML is accessible. Some specific concerns with regard to the accessibility of templates include the following:

Step 4: Fix all of the remaining HTML-related issues, starting with second-level pages

Once the home page and the templates are taken care of, it is time to focus on the pages that are directly linked to from the home page. Developers should fix only the HTML-related issues at this stage, ignoring any non-HTML elements for the moment. After fixing these pages, the next logical step would be to continue fixing the HTML-related issues on the remaining pages.

Step 5: Fix all non-HTML issues

In most cases, the issues that are most time-consuming, and/or difficult to fix are those related to non-HTML technologies such as Flash, video, multimedia, and Java. It may be necessary to construct an HTML alternative to these elements either as a first step in accessibility, or as the final solution, depending on the circumstances.

Conclusion

The strategy outlined above provides a framework within which to organize Web accessibility tasks. It allows developers to focus in on one particular area of the site at a time, rather than haphazardly applying accessibility fixes to random areas of the site. The tasks are organized by both the importance of the tasks and the ease of implementation, thus taking into account the needs of the developers as well as the users with disabilities.

Notes:

  1. http://www.w3.org/TR/WCAG10/

  2. http://www.section508.gov/index.cfm?FuseAction=Content&ID=12

  3. Web Content Accessibility Guidelines 1.0 checklist: http://www.w3.org/TR/WCAG10/full-checklist.html

  4. WebAIM Section 508 Checklist: http://www.webaim.org/standards/508/checklist


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


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