RE: Comments-Selecting and Using Web Accessibility Evaluation Tools

Sailesh,

While you recommend one tool that can be 'toggled' between everything and a
persons immediate needs, I am not aware of any tool that can check all the
checkpoints - the automatic tools can only check for the presence/absence of
certain attributes, not whether the values are sensible or appropriate. Some
focussed tools are the only way to check some checkpoints - e.g. Gez Lemon's
Colour Contrast Analyser
(http://www.juicystudio.com/services/colourcontrast.asp) or Chris Ridpath's
'Color Visibility Test Program'
(http://aprompt.snow.utoronto.ca/ColorVisibilityProgram.html) for colour
contrast. Others, like our own Web Accessibility Toolbar
(http://www.nils.org.au/ais/web/resources/toolbar/) provide a toolbox where
the user can choose a tool (often a simple script) to test many of the
checkpoints that the large automatic tools advise need to be checked
manually.

I personally think a suite of tools is required if a developer or
organisation is serious about accessibility and wants to comprehensively
check against WCAG.

Andrew
_________________________________
Dr Andrew Arch
Manager Online Accessibility Consulting
Accessible Information Solutions, NILS
Ph 613 9864 9222; Fax 613 9864 9210; Mobile 0438 755 565
http://www.nils.org.au/ | http://www.it-test.com.au/ |
http://www.ozewai.org/

Member, Education & Outreach Working Group,
W3C Web Accessibility Initiative
http://www.w3.org/WAI/EO/

National Information & Library Service, Australia
A subsidiary of RBS.RVIB.VAF Ltd.

  -----Original Message-----
  From: w3c-wai-eo-request@w3.org [mailto:w3c-wai-eo-request@w3.org]On
Behalf Of Sailesh Panchang
  Sent: Saturday, 16 October 2004 8:25 AM
  To: 'EOWG'
  Subject: Re: Comments-Selecting and Using Web Accessibility Evaluation
Tools


  Shadi writes:
  >Testing with a focused tool which assists in examining a >specific issue
in greater detail may sometimes (for >example during design and development
stages) be >more helpful than a full evaluation to determine >conformance.
  Sailesh:
  Your point that one needs to focus on a certain checkpoint or a group of
related checkpoints is well taken. Likewise it may be necessary not to test
for checkpoints that clearly do not  apply to a site. For example if my site
has no multi media, I need not  check for those checkpoints. But consider a
company that renders services and  has clients   with all kinds of websites.
  So how many  focussed tools is the company expected to invest in?
  A better option is to have a   a tool that can do a comprehensive
evaluation and  allows user to turn on / off the checkpoints that are not to
be tested for the time being. And there are tools that can offer that
feature not only during  evaluation but also during reporting. So one should
be able to evaluate  against all  checkpoints if one wants to but generate
separate report  for specific checkpoint(s) for use by different developers.
  I do not subscribe to the concept of focused tools- they are just
incomplete tools   and the EO doc authors should not legitamize them. All
tools should be compared  on one scale and one should be able to say that
Tool X checks   compliance against n checkpoints and Tool Y checks against n
+ Delta checkpoints.
  Again  are all users in an org expected  to  learn the user interfaces and
idiosyncrancies  and features of several tools?  Just the experts  should
evaluate a tool and the org should standardize on one.
  Then again there are tools that do only eval and some can do eval and
repair. So this is a functionality offered and the user should knowingly
select  one tool  that meets his / her needs.

  Shadi, I also forgot an important feature in my previous mail: the tool
should be accessible to users of assistive technologies.

  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> *