skip navigation barsW3C home pageWeb Accessibility Initiative (WAI) home page
W3C Index - W3C Search - W3C Translations
WAI Resources - WAI Site Map - About WAI

[Draft] Selecting Web Accessibility Evaluation and Repair Tools

Note: This document is a draft [see change log in progress] and should not be referenced or quoted under any circumstances. This document is under development by the Education and Outreach Working Group (EOWG), and will be offered to other W3C groups and the public for review.

1. Introduction

Selecting appropriate Web accessibility evaluation and repair tools to assist the development, review and retrofitting of Web sites can reduce the involved time and effort significantly. This document assists the selection of Web accessibility evaluation and repair tools by highlighting some of the user requirements, tool features, as well as other factors which may arise in this process.

W3C/WAI does not endorse or promote any tool or vendor but encourages the development and evolution of Web accessibility evaluation and repair tools and features. A collection of evaluation, repair and transformation tools is maintained by the Evaluation and Repair Tools Working Group. Please note that no evaluation tool can determine the conformance level of a Web site without judgement from skilled reviewers, and no repair tool can remove all accessibility barriers without intervention of skilled users.

2. User Requirements

In a Web project, several user roles and responsibilities may be involved in implementing accessibility. Each user profile requires a slightly different view on the Web accessibility evaluation data which is generated by the review process. In the following, some of these user profiles will be discussed with respect to their requirements.

Web Developers

Implementing service transactions and other functionalities of Web applications is usually the core focus of Web developers. Accessibility barriers presented by Web applications are often a result of generating incorrect markup and requires fixes to the source code or configuration of the underlying application logic. Providing Web developers with accessibility evaluation reports which include detailed information about the location of the errors and how the correct markup should look like can help them trace and fix the source of the problem.

User Interface Designers

User interface designers usually implement more static modules of Web applications such as templates, navigational structures and design frameworks which are reused throughout a Web project. The impact of accessibility barriers in such areas often have a very significant impact on the overall accessibility of the Web site. Providing user interface designers with detailed error messages and conceptual design aspects on how to repair these errors can help them understand the nature of the problems which people with disabilities encounter on the Web.

Content Authors

Web content authors are usually non-technical users who publish information with the help of authoring tools such as content management systems or editors which cascade the markup code and technical details. Web accessibility evaluation tools also need to consider these requirements of the content authors and cascade cumbersome error messages and technical detail away from them. Easy to understand user interfaces such as wizard dialogs which carry users through each Web accessibility evaluation and repair step are essential to some content authors.

Managers

Web project managers and executive managers are usually more interested in a higher level, birds-eye view on the status and progress of the respective Web site. Facts and numbers about how many accessibility errors are present on the Web site, the severity and complexity of repairing these errors, as well as a progress history over time is essential information. Collecting such large amounts of data and deducing precise information can be very challenging if the evaluation tools do not provide sufficient functionality to process and analyze the generated reports.

Reviewers

Reviewers may be part of an in-house development or procurement team, or a third party sub contractor doing independent Web accessibility evaluations as a service. Reviews may be conducted as an initial conformance review or on an ongoing monitoring basis to ensure the accessibility and quality standard of a Web site is maintained. Web accessibility evaluation reviewers require tools which support them in generating comprehensive reports which can be used effectively by Web developers, user interface designers, content authors, or managers.

3. Tool Features

Web accessibility evaluation and repair tools come in a wide range of variety which represents the diverse end-user requirements while carrying out a review process. Tools provide different user interfaces and functional features which allows the selection of one or a combination of tools that best fit the specific development environment. The following points are intended to highlight some of the Web accessibility evaluation and repair tool properties that might be of interest during the selection process.

Checkpoint Support

Web accessibility evaluation and repair tools vary greatly in their support and coverage for checkpoints. While some tool vendors focus on analyzing specific checkpoints only (focused tools), other tool vendors aim to address as many checkpoints as possible in the implementation of their tools (general tools). It is important to address all relevant checkpoints in order to determine a conformance level and sometimes combining two or more tools in order to take advantage or overcome certain tool disadvantages may be the best way to reach an appropriate level of checkpoint support.

Precision

While every Web accessibility evaluation or repair tool is prone to producing false positives (not identifying existing errors) and false negatives (incorrectly reporting errors), some tools perform better than others. Key factors which may affect the performance of the tools can be the nature of the content, the size and complexity of the Web site, and the technologies utilized to code the content (such as HTML, CSS, SVG, etc). According to the specific Web site, users of Web accessibility evaluation and repair tools must be aware of when to rely on a specific tool claim for a specific checkpoint.

User Interface

There are several types of user interface paradigms which are employed by currently available Web accessibility evaluation and repair tools. These paradigms usually serve specific purposes and tasks such as to providing technical reports for developers, educating users and promoting awareness, or assisting non-technical users in remedying accessibility barriers. Selecting appropriate tools is strongly dependant on the structure and the skills within a Web site development or maintenance team. Combining more than one tool to address different tasks may also be an option.

Repair

In most cases, both Web accessibility evaluation and dedicated repair tools need judgement from skilled users to select a repair method for a given situation and context. While non-technical users may prefer educational resources to help them determine a method, developers may prefer markup and coding suggestions for replacement. In either cases Web accessibility evaluation and repair tools need to provide their users with sufficient information about the context of the occuring error as well as the repair suggestions in order to assist them in their respective task and role.

Configurability

Especially for large or complex Web sites it becomes increasingly important that Web accessibility evaluation and repair tools can be tailored to better perform within the specific scenario. For example, some configuration tools can be adapted to only target the dynamically generated sections of Web pages and neglect the sections which are generated by templates. In other cases it may be helpful to be able to configure tools so that they only analyze specific sections of a Web site, or so that they generate reports in a specific format.

4. Other Factors

Selecting Web accessibility evaluation and repair tools involves considering numerous user requirements and tools features with regard to the context of the specific Web site. There are also several other factors which influence the relevance and importance of the user requirements and tool features highlighted in this document, some of these factors are described below.

Organizational Factors

The structure and skills of a development team play a vital role in deciding which Web accessibility evaluation and repair tools to utilize. While a team with more technical background may prefer more technically oriented tools, non-technical teams may prefer more verbose tools. In a heterogeneous environment, combining several tools may best address the opposing demands of the user requirements.

Technical Factors

Depending on the existing infrastructure such as operating systems and development environment, different Web accessibility evaluation and repair tools may be selected for interoperability reasons. The compatibility of the tools with the technologies employed by the Web site (for example HTML, CSS, SVG, etc) is also an important aspect to consider when selecting an appropriate tool.

Policy Factors

Policies for Web accessibility define the overall scope and goals for the evaluation and repair tools. Tools need to support the respective conformance level which has been set as a target by the policy sufficiently. Reliability of claims and ongoing monitoring capabilities may also gain importance by stricter policies or more if the mission and visibility of a Web site is particularly delicate.


Last modified: $Date: 2005/01/27 12:51:20 $ by $Author: shadi $

Note: This draft WAI Resource developed by W3C/WAI's Education and Outreach Working Group (EOWG). We invite review and discussion. Please address your feedback to wai-eo-editors@w3.org, a mailing list with a public archive. Change log available.

Last updated 7 Ocotober 2004 by Shadi Abou-Zahra. Editors: Shadi Abou-Zahra and Judy Brewer, with assistance from participants of the EOWG.

Copyright © 2004 W3C (MIT, ERCIM, Keio ), All Rights Reserved. W3C liability, trademark, document useand software licensingrules apply. Your interactions with this site are in accordance with our public and Member privacy statements.