RE: Normative status of techniques checklists

It seems to me that writing good checklists goes hand in hand with
meeting our requirement that all success criteria be testable.

It's true that the checklists could fall behind as technologies continue
to evolve.  But this could be addressed (not "solved") by chartering the
WG to review and update the checklists according to a specific
timetable.  Such a review wouldn't *require* that the checklists change;
the review might result in a finding that no changes were necessary at
that time.

I suspect that the checklists would be *more* likely to fall out of date
if they were not normative-- there would be less pressure to stay on top
of them if they were "merely" informative.
John

"Good design is accessible design." 
Please note our new name and URL!
John Slatin, Ph.D.
Director, Accessibility Institute
University of Texas at Austin
FAC 248C
1 University Station G9600
Austin, TX 78712
ph 512-495-4288, f 512-495-4524
email jslatin@mail.utexas.edu
web http://www.utexas.edu/research/accessibility/


 



-----Original Message-----
From: w3c-wai-gl-request@w3.org [mailto:w3c-wai-gl-request@w3.org] On
Behalf Of Chris Ridpath
Sent: Thursday, May 13, 2004 8:55 am
To: Web Content Accessibility Guidelines
Subject: Re: Normative status of techniques checklists



To use the guidelines you must interpret their meaning. In the absence
of checklists, everyone is free to interpret them differently. This is
the current situation where many people claim conformance but no one is
sure which interpretation is correct.

Normative checklists are the WAI's description of the what the
guidelines mean for each technology. They will ensure that people can
effectively implement the guidelines.

The WCAG1's lack of clear specification has been a hindrance of its
implementation. This has been detailed in several recent papers and has
led to the development of other accessibility standards, like 508, that
aim for clearer definition.

> 1. W3C notes are easier to modify than Recommendations; cf. item 2 in 
> the advantages above for the trade-off between ease of maintenance and

> degree of review.
>
My feeling is that the checklists should be updated periodically to keep
up with current trends on the web. The guidelines can be stable while
the checklists change.

> 2. There could arise a temptation for checklists, as Recommendations 
> in their own right, to be out of line with the guidelines...
>
The WAI will accept/reject what goes into the checklists so they should
never be out of line with the guidelines.

> 3. How to deal with technologies for which checklists wouldn't be 
> issued by the W3C - see earlier discussion in this mailing list 
> thread.
>
The WAI can still make up checklists in consultation with the technology
vendors. If the WAI doesn't do this who will?

> 4. Normative checklists might encourage developers to apply the 
> checklists instead of looking at and applying the guidelines.
>
Yes. The checklists would be clear and simple, easy to understand and
implement. The guidelines are more difficult to understand and apply
because they must be interpreted.

Cheers,
Chris


----- Original Message ----- 
From: "Jason White" <jasonw@ariel.ucs.unimelb.edu.au>
To: "Web Content Accessibility Guidelines" <w3c-wai-gl@w3.org>
Sent: Wednesday, May 12, 2004 12:22 AM
Subject: Re: Normative status of techniques checklists


>
> This is my attempt to compile a list of arguments for and against 
> normative checklists, while the topic is under discussion:
>
> In favour:
> 1. Certainty for developers/implementors: meeting the checklist is 
> indefeasibly tantamount to satisfying the success criteria (at the 
> appropriate level). Thereby, concerns about the generality of the 
> guidelines are overcome - the technology-specifics in the checklist 
> have equal normative status with the guidelines and success criteria.
>
> 2. By proceeding to Recommendation, the checklists could receive a 
> higher degree of scrutiny and review than might otherwise occur. Is 
> this really true?
>
> Any others benefits?
>
> Disadvantages:
>
> 1. W3C notes are easier to modify than Recommendations; cf. item 2 in 
> the advantages above for the trade-off between ease of maintenance and

> degree of review.
>
> 2. There could arise a temptation for checklists, as Recommendations 
> in their own right, to be out of line with the guidelines, i.e., 
> creative interpretations of the guidelines that should more properly 
> be dealt with as errata (this would apply to checklists issued after 
> the guidelines became a Recommendation). With non-normative 
> checklists, the guidelines would be normative and the checklists not; 
> hence there would be no ambiguity as to what was the requirement that 
> had to be met.
>
> 3. How to deal with technologies for which checklists wouldn't be 
> issued by the W3C - see earlier discussion in this mailing list 
> thread.
>
> 4. Normative checklists might encourage developers to apply the 
> checklists instead of looking at and applying the guidelines. This 
> might not be an issue if the checklists were good, that is, if meeting

> the checklist gave true assurance of satisfying the success criteria, 
> which is the essence of the proposal anyway. With a good checklist, a 
> developer shouldn't have to refer to the guidelines except for 
> clarification, examples etc., and likewise for techniques.
>
> Others?
>
> Ultimately it is a question of whether one thinks item 1 in the 
> advantages list outweighs all of the disadvantages, if the latter were

> minimized by designing the checklists appropriately.
>
>

Received on Thursday, 13 May 2004 14:12:27 UTC