Re: Conformance issues with AU guidelines

Here is my reply to Jon, sans Jon's original message. I will ask Jon 
if he is comfortable in posting both his messages to AU.

-----------------------
Thank you for your thoughts. They are very helpful. I think your 
comments have served to highlight the present differences between the 
authoring tools and the user agents. (I say present because I'm still 
hoping that the two tecnologies will converge so we have a true 
read-write web soon.)

Let me address some misunderstandings.

1. The problem to be addressed through the evaluation tool, as I 
stated, is not that developers don't know how to comply but that we 
want to be sure that the evaluations of the same tool by different 
evaluators are consistent. The evaluation tool will formalize the 
evaluation process and make sure that things are consistently checked 
in a consistent manner. This will give developers the confidence to 
proclaim that they are compliant, knowing that one evaluation will 
not be contradicted by another.

Developing minimum requirements for checkpoints will not work for 
authoring tools for the following reasons:
- compliance to all but guideline 7 is relative to the type of tool. 
The guidelines need to be interpreted relative to the look and feel 
of the tool, the target author of the tool, and the features 
available in the tool. Minimum requirements will look very different 
for a text editor than for a WYSIWYG video editing tool.
- we know that the goal is that the average author of the tool is 
more likely than not to generate an ATAG compliant web page using the 
tool. The whims, knowledge and motivation of the average author 
varies enormously. The busy executive who doesn't know what HTML 
means is going to respond very differently to a prompt to include an 
alt-text attribute than an HTML savvy programmer using a text editor. 
The tool developer knows their consumer, the ATAG checkpoints need to 
be seamlessly integrated into the design of their tool. The 
checkpoints are written in such a way that respects the design 
knowledge of the developer.

2. I did not say that the Techniques Document is used to identify 
conformance. The techniques document is used to show examples of how 
to conform. We are using it to show the range of ways to conform. It 
is good that it is not a normative document, this means that it is 
flexible and that we can easily respond to significant changes in 
authoring tools. The guideline document is written with the right 
level of abstraction so that it remains fairly stable. This level of 
abstraction and flexibility of interpretation was at the request of 
the developers and has helped to maintain the goodwill of the 
developers.

3. We are not planning to take a minimum requirements approach to 
evaluation. The evaluation process to be specified will formalize the 
steps to the evaluation. If you go to the AU list you will see some 
of the specifics we are trying to formalize.

Jutta

Received on Tuesday, 1 August 2000 16:03:07 UTC