Re: Selecting Web Accessibility Evaluation Tools

Roberto writes:
We could consider to add a sentence or a small section dedicated to
automatic evaluation (not repair) tools, and this can be useful to make the
document more complete: a not skilled developer reading our document may ask
himself: "what about automated evaluation and repair? Why this document
doesn't talk about them?". If so, this section should stronlgy warn the user
that automated tools can only give some suggestions, and cannot complete any
task in repairing a not accessibile web page.
Sailesh:
1. The doc clearly needs to talk of eval and repair tools and not  authoring tools. If FrontPage offers the ability to enter an alt it is part of authoring tool functionality and not an eval / repair function. Likewise a tool that allows one to play around with different color combinations and  determine which one produces appropriate level of contrast (as per that one developer), is an aid to authoring and not an eval and repair tool. Such tools are out of the scope of the doc whose title is selecting eval and repair tools.
I suppose we are talking only about tools which can scan Web content / underlying code and list out  
- specific instances of clear violations and 
- likely / suspected violations or where the program needs more specifics  for making a decision.
2. If one is just not willing to accept that there are tools  which incorporate algorithms (some of which have been suggested and documented by W3C in Techniques for eval and repair) and that certain eval and repair tasks can be done in a fully automated fashion, then I am not sure why you want to  devote even a sentence or  small section to automated tools in the doc. Go ahead and clearly say that there are  no such tools out there. 

I use a tool that can detect and fix several violations without user involvement. 

Roberto:
Roberto:
I agree, but only if we're talking about using deprecated tags and other few
really automatic evaluations a tool can provide; but let's make attention
not to give a wrong message: even this kind (or any other kind) of
automation cannot replace the intervention of a skilled human developer, and
this must be clearly said in our document if we decide to speak about
automated evaluation.
Sailesh:
Which of the examples given (other than one about 11.2) relate to deprecated tags? I can give some more examples that can be detected automatically.
Roberto, you misunderstood  the example of the PDF image icon. The image is not a thumbnail of a specific PDF doc but a generic image  next to the doc's name that tells the user it is a PDF doc. So the image is the same for all docs and occurs multiple times on a page / site.  
Once the user gives an alt-text for the img, is it not great  if a tool can automatically identify all occurrences of the img and assign the alt-text to it while the developer sits back?
And about the table: If the developer  does not know how   to make a table accessible but can point out  column and row headers to the tool, is it not great if the toolcan insert th tags or even header-id markup? Please do not say that there are no tools that can do that.  
Failing to say that   there are automated tools which can do eval and repair is  not telling the truth. The doc will give a wrong impression   about tools. I reiterate that the doc should say that certain barriers can be detected and fixxed  only with user interaction because there are no objective methods / algorithms for doing so. And say that there are several barriers that can be detected and fixed automatically with no user interaction.
Consider 13.6 says : there should be a method to bypass a group of navigation linnks without saying how many links make a group. There is a tool that allows a user to set some options for evaluation including how many links constitute a group. Then the tool finds all such groups of links and inserts a skip nav link whose target is the end of the group. What's more, one can even say if the link should be visible or not and there is a tool that can do that. 
Please note that the Techniques for WCAG ( and even the doc for Sec 508 by the U.S. Access Board) too have a  line that says that  these technniques  are not the only way to implement accessibility. Likewise, eval and tool techniques are evolving with technology and  getting better and better.

If anyone wishes  to know more about such an eval and repair tool, write to me  off list.
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> *