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.
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 
Fax: 703-225-0387
* Look up <> *

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


  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 ( or Chris Ridpath's 'Color Visibility Test Program' ( for colour contrast. Others, like our own Web Accessibility 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.

  Dr Andrew Arch 
  Manager Online Accessibility Consulting 
  Accessible Information Solutions, NILS 
  Ph 613 9864 9222; Fax 613 9864 9210; Mobile 0438 755 565 | | 

  Member, Education & Outreach Working Group, 
  W3C Web Accessibility Initiative 

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

    -----Original Message-----
    From: []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.
    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 
    Fax: 703-225-0387
    * Look up <> *


Received on Monday, 18 October 2004 16:31:14 UTC