R: Selecting Web Accessibility Evaluation Tools

Hi Sailesh, hi group

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.

Roberto:
So "scanning Web content, underlying code and list out specific instances of
clear violations and likely / suspected violations.." cannot be considered a
kind of authoring aid for developers? I'm not sure about it... anyway, I've
never mentioned Frontpage or similar authoring tools.
 

Sailesh:
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 [CUT]
Go ahead and clearly say that there are  no such tools out there. 

Roberto:
Maybe my poor english is not helping me in writing what I exactly mean, if
so I do apologize... 
I was talking about "deprecated tags and other few really automatic
evaluations a tool can provide". 
So, I'm not denying that some automatic evaluation can be performed, but we
should simply say in the document that only limited tasks can be done in
fully automated fashion. I still believe that those tasks (evaluation ones)
can cover a small percentage of potential accessibility problems in a Web
page/site, and all the others must be followed by a human and well skilled
developer, helped by a manual or semi-automated tool. 


Sailesh:
... then I am not sure why you want to devote even a sentence or small
section to automated tools in the doc

Roberto:
I could live with this new section because some developer reading the
document may find that there's something missing: manual tools,
semi-automated tools... and then, what about automated ones: do they exist?
Are they useful?  

I'm still doubtful about it, but if the group should decide to insert a new
section, that section - in my opinion - should put the stress on the fact
that it's not possible using tools without knowing exactly what they are
trying to do, also because they may fail in doing it and the developer must
know how to notice that. 


Sailesh:
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?

Roberto:
I'll try and make an example: do we really think that automatic "Find &
Replace" features always work fine? They may work nice in some cases, and
this doesn't allow us to consider them an automatic tool for finding and
fixing errors in a text file; it is just a useful semi-automatic tool.


Sailesh:
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.  

Roberto:
If the developer does not know how to make a table accessible, that
developer will never be able to build a single accessible page! The
developer has to know what to insert into th tags, otherwise the tool will
correctly add new tags which will stay untouched; is it really useful?

What I'm trying to say is that any kind of tool must be used by skilled
developers and cannot replace developer's lack of knowledge; they can
improve developer's efficiency or, as already said in the document, can help
the developer in improving his knowledge and learning new techniques, but
cannot merely substitute the knowledge. Developers must always get in touch
with the code, otherwise no kind of Web accessibility can really be reached,
and a divulgative document must show off the conscious use of any kind of
tool.


My best regards,


Roberto Castaldo
------------------------------
Webaccessibile.Org coordinator
IWA/HWG Member
r.castaldo@iol.it
rcastaldo@webaccessibile.org

Received on Thursday, 27 January 2005 22:42:39 UTC