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