W3C home > Mailing lists > Public > w3c-wai-eo@w3.org > January to March 2005

Re: Selecting Web Accessibility Evaluation Tools

From: Sailesh Panchang <sailesh.panchang@deque.com>
Date: Wed, 26 Jan 2005 14:49:31 -0500
Message-ID: <007f01c503e0$273b6a10$a201a8c0@deque.local>
To: "EOWG" <w3c-wai-eo@w3.org>
1. Definition:
"Web accessibility evaluation tools are software programs or online services that help determine if a Web site is accessible, and help improve Web accessibility."
SP: E-R tool is supposed to check Web content / underlying code for   conformance against a set of accessibility techniques.
This aspect is not stated in the definition.
2. Semi automatic and manual tools:
"Manual Web accessibility evaluation tools are designed to involve Web developers during the evaluation process.
Generally, semi-automated evaluation tools attempt to evaluate Web pages with little or no user interaction."
SP: Distinction is not clear. Semi automatic tools may require little user interaction while manual tools always need user action?
Tools that only render the content in an alternative  manner and leave it to the user to figure out if there is an accessibility issue is not an eval tool but something that merely helps the author ... more like an authoring tool. Also   assistive technology tools are not eval and repair tools but testing tools. AT tools too have some strengths and limitations. If Web content is not accessible with a particular AT tool, it can be due to a AT tool's weakness or lack of support for an accessibility technique.

3. I note that automated tools are omitted from this discussion. There are two aspects here:
-Automated evaluation: 
Certain accessibility barriers can be   detected in an automated fashion across a site efficiently using a tool. The results are very reliable because the criteria for evaluation are specific and objective. Form control has no label associated explicitly  checkpoint (12.4) or deprecated tags are used like <u> (11.2 or images or area element have null or blank alt (1.1). Absence of title for a page or frame is another instance that can be auto-detected. So there are several barriers that can be reliably detected in an automated fashion. 
-Automated repair: 
Some repair techniques can be  implemented in an automated fashion  accurately and reliably. Adding keyboard equivalent events like onFocus and onBlur for onMouseover and onMouseOut is an example. 
Yes certain barriers can be detected with user interaction and certain barriers can be fixed  using user input.
Consider, once an alt text is given for an image, an automated tool can create an alt-text repository and use that alt-textfor all occurrences   of the img on the page or site. Example: there is a img of a pdf icon next to every PDF file on the site and it has a null alt. The user enters "PDF Acrobat File" as alt-text and the tool assigns it across the site. Would one characterize this as almost entirely automatic or as semi automatic?
True  it cannot judge if the alt-text is appropriarte
A tool can have a rudimentary  algorithm for detecting data tables and might again ask the user for confirmation. Once it is confirmed as a data table, the tool can ppoint out that it has no markup for associating header and data cells.

So I think it is unfair to  not even recognize the presence of automated tools for eval and repair.
The only reasons certain barriers cannot be identified in  an automated fashion is because there is no objective criteria for detecting  these. 

Sailesh Panchang
Senior Accessibility Engineer 
Deque Systems,11180  Sunrise Valley Drive, 
4th Floor, Reston VA 20191
Tel: 703-225-0380 Extension 105 
E-mail: sailesh.panchang@deque.com
Fax: 703-225-0387
* Look up <http://www.deque.com> *
Received on Wednesday, 26 January 2005 19:53:30 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:55:52 UTC