RE: Normative status of technology specific checklists

A TALE OF TWO  GROUPs

The important thing here is to remember that the checklist is the meeting
place of Content and User agents (including AT) for many of the guidelines /
success criteria. 

In fact we should note that the success criteria fall into two categories

1)  - those that use techniques that depend on special features of User
Agents (incl AT). 
            - these are usually not visible in the default presentation of
most browsers
	  -  examples - ALT Text,  anything markup based, closed captions
etc

2)  - those that are not dependent on special features of User Agents or AT
	- these are all visible to all users - as part of default
presentation of mainstream
	  browser
	- examples - adding structure, placement of navigation, high
contrast, and 
	  Open captions (where the captions are indelibly part of the image
and always 
	  show)

We might in fact think about whether we need to divide our techniques /
checklists into these two categories.

The reason I say this is that  group 1 items above, are the type that are
only useful if both the author and the user agent support them.  In fact,
the user agents must support them first -  or they do not in fact result in
any increase in accessibility.

Each time we change the checklist for Group 1 items - it requires all of
user agents and/or AT to support this new technique.   Changing the Group 1
checklists often is hell on the user agents and AT.  It basically keeps
changing the rules of the game on them.   (and again - if user agents don't
keep changing to match - then the people using those agents or AT will get
no benefit from the new technique -  AND in fact the content would become
less accessible since authors can now use the new (unsupported) technique
instead of the older techniques that were supported.  
(NOTE: This is based on the assumption that the success criteria could be
met with older techniques - and that the new techniques are alternatives to
what did suffice before).

This would seem to indicate that changes to group 1 items in a checklist
should only be done after thought and careful vetting with all groups to
ensure that unsupported techniques are not added in continual flow -- and so
that User Agents and AT have stable rules with which to conform.   This
speaks to normative checklist items.

For the Group 2 checklist items we see the opposite.   Here, any new
technique makes pages more accessible immediately.   Since support of
special features by User Agents or AT are not required for these to be
effective group 2 checklist items could be added weekly with no ill effect
(although users might need to get used to some of them - and that should be
considered).     

For Group 2 checklist items there seems to be no similar reason to hold
these to the same stability as Group 1.    It looks like these would not
need to be normative - -and in fact making them normative would inhibit
their creation and movement into practice.   We DO need to be sure that
alternate strategies are effective and as good as what has been there - but
may be able to be done without the rigor of normative review.  

How we address this dichotomy is an interesting question.    Rapid normative
docs would help.   Splitting the checklists into two categories might be an
approach though I don't quite see how yet.

And that still leaves the question of whether a normative doc can point to a
non-normative doc for conformance.   Only if the success criteria are
concrete enough to be judged reliably without the checklist - can the
checklists not be normative.   We'll have to see if we can do that or not.  

 
Gregg

 -- ------------------------------ 
Gregg C Vanderheiden Ph.D. 
Professor - Ind. Engr. & BioMed Engr.
Director - Trace R & D Center 
University of Wisconsin-Madison 

-----Original Message-----
From: w3c-wai-gl-request@w3.org [mailto:w3c-wai-gl-request@w3.org] On Behalf
Of Jason White
Sent: Tuesday, May 11, 2004 11:23 PM
To: Web Content Accessibility Guidelines
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 Wednesday, 12 May 2004 15:51:18 UTC