W3C home > Mailing lists > Public > w3c-wai-eo@w3.org > October to December 2004

RE: Comments-Selecting and Using Web Accessibility Evaluation Tools

From: Andrew Arch <andrew.arch@nils.org.au>
Date: Wed, 20 Oct 2004 10:28:51 +1000
To: "'Sailesh Panchang'" <sailesh.panchang@deque.com>, "'EOWG'" <w3c-wai-eo@w3.org>
Message-ID: <002b01c4b63b$c6d4d860$7dc8a8c0@yourdh7axfhyur>
Hi Sailesh,

"classifying tools as focused and general" - I missed your point, get it
now. Yes, I agree we could have a better classification scheme for tools.

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


  Hello Andrew,
  The  color contrast checker  on Chris' site says that there are plans to
incorporate it into A-Prompt.  When this happens, the latter will be able to
do color checking too.
  Deque-Ramp-Ascend
  (http://www.deque.com/index_products.html)
  does color contrast checking and can even fix the problem so   that the
difference between foreground and background colors meets the   recommended
range. It gives the user an option to select a color shade that will comply
with accessibility guidelines.
  Ramp is able to identify an image that might need a longdesc even though
it has an alt. It highlights suspicious alt as well as suspicious link names
or pieces of text that should  be marked up as a heading (h1 to h6). It
fixes the flicker problem,adds headers and ids to complex  data-tables after
user identifies the association, and much more.
  Some tools highlight situations where user checking might be needed. Ramp
has an interface through which in certain situations, it asks user for input
and then determines if there is a violation. So it is able to add more value
to the process of identifying violations and fixing them too.
  It is true that the need for manual checking for accessibility   will
remain- in cases where judgment needs to be exercised and to actually check
with assistive tech tools.

  The point I am trying to make is that  the need to use more than one tool
will probably  exist during the time when tools are evolving. Tools labeled
as focused tools might continue adding features till they become fully
featured. Or, they might get incorporated into bigger tools- like the
A-Prompt case. Or just continue  as they are.
  So the EO doc on eval and repair  should say that tools differ in
capabilities and the user should select one that meets his/her org's needs.
I am not against selecting more than one tool per se - it might a short term
solution and is fraught with its own set of problems referred to in previous
e-mails. But I object to classifying tools as focused and general.
  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> *




  ----- Original Message -----
    From: Andrew Arch
    To: 'Sailesh Panchang' ; 'EOWG'
    Sent: Sunday, October 17, 2004 3:14 AM
    Subject: 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> *
Received on Wednesday, 20 October 2004 00:31:04 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 10:33:37 GMT