W3C home > Mailing lists > Public > w3c-wai-ig@w3.org > July to September 2004

Re: Who needs what Re: A Call to Reorganize WCAG 2.0

From: Alastair Campbell <ac@nomensa.com>
Date: Wed, 25 Aug 2004 12:26:54 +0100
Message-ID: <412C777E.90303@nomensa.com>
To: RUST Randal <RRust@COVANSYS.com>
CC: John M Slatin <john_slatin@austin.utexas.edu>, w3c-wai-ig@w3.org

Randal RUST  wrote:
> Would you like to know how most clients have us
> validate accessibility? If we are using Dreamweaver and templates, then
> we validate the templates with BOBBY. If the templates pass, then we're
> good to go. 

John M Slatin then wrote:
> The fact that some (maybe even most) clients "don't care" and "aren't
> about to take the time" to do serious accessibility evaluation is not an
> argument against writing the best guidelines we can possibly write to
> provide the best guidance we can think of for those developers and
> clients who who *do* care and do want to know how best to meet the needs
> of a diverse audience.

Whether the guidelines should be written to be include only machine 
testable items comes down to one thing:

Can machine testable rules predict the performance of users 
accomplishing tasks on a web site?

The answer is emphatically no. Even with the best tools, you would not 
be able to say that a page that passed is accessible in practice. A 
facile example is whether the alt text is at all appropriate, an image 
of a cat with alt text of dog. Other typical issues tend to involve 
using HTML code validly but not meaningfully.

Randal RUST  wrote:
 > Accessibility has as much to do with logically and correctly
 > structuring a web page as anything.

And this is machine testable?

I'm sure everyone here knows that there are pages that pass Bobby that 
are not usable by people with even the latest access technologies.

By all means categorise checkpoints into things that can be tested 
automatically, and things that need human interpretation. However, we 
should not get rid of the human element.

Accessibility does tend to have some things that are easy to check 
automatically, and tools can be a great help in catching certain issues. 
But tools should be just that, a useful thing to help development. Tools 
can't be the final 'test'.

Having best practices is an essential part of writing the best possible 
guidelines. Perhaps this involves re-writing the bridge or techniques 
documents rather than the technology-agnostic guidelines?



Alastair Campbell   |   Director of Technology

Please refer to the following disclaimer for this message:
Received on Wednesday, 25 August 2004 11:26:56 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 13 October 2015 16:21:29 UTC