W3C home > Mailing lists > Public > w3c-wai-gl@w3.org > April to June 2004

Re: Normative status of techniques checklists

From: Chris Ridpath <chris.ridpath@utoronto.ca>
Date: Thu, 13 May 2004 09:54:52 -0400
Message-ID: <05a701c438f1$ddd7fcd0$b040968e@WILDDOG>
To: "Web Content Accessibility Guidelines" <w3c-wai-gl@w3.org>

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 09:55:46 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:47:30 GMT