- From: Sailesh Panchang <sailesh.panchang@deque.com>
- Date: Wed, 26 Jan 2005 14:49:31 -0500
- To: "EOWG" <w3c-wai-eo@w3.org>
- Message-ID: <007f01c503e0$273b6a10$a201a8c0@deque.local>
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. Thanks, 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