Proposals: Priority and Conformance schemes

This is essentially a re-post of a proposal which I submitted last
week. I have however taken the opportunity to edit it slightly. Gregg
and Wendy asked me to re-post these proposals for ease of future
reference and to facilitate discussion.

This is not a single proposal, but rather a set of related proposals.
I first present the idea in its most complex form, then suggest
various possible simplifications.

Disclaimer: I am not necessarily advocating these solution. Instead, I
am trying to transform various suggestions which have been raised on
this mailing list, into specific proposals, the merits of which can
then be debated more easily.

General structure of the conformance scheme:

Three conformance classes are proposed. A conformance claim can be
made in respect of one, two or all three conformance classes, and must
include:

a. Identification of the web content (page, site, etc.) to which it
pertains.

b. The version of the guidelines to which conformance is claimed.

c. The date on which the conformance claim was made.

Any method of expressing a conformance claim is acceptable so long as
it includes all of the needed information and can be accessed (with or
without suitable software tools, e.g., RDF processing applications) by
users of the web site and/or search tools. To facilitate the making of
conformance claims, the working group provides:

1. An RDF schema (that is, ERL, as defined by the ER and AU working groups).

2. An icon and associated text equivalent, which can serve as a link
   to a page that provides details of the conformance claim.

Note: The RDF metadata and the web page which gives a textual
exposition of the conformance claim, should be linked.

Next come the definitions of the conformance classes. For each
conformance class, the conformance claim must name the class and list
the checkpoints which are claimed to have been met. This list must
include all "essential" checkpoints in the particular class (see
below); otherwise the conformance claim is invalid (this can be
checked automatically). The checkpoints in each class are divided into
two categories, "essential" and "recommended". These take the place of
the WCAG 1.0 priority scheme. A checkpoint within a particular class
is essential if failure to satisfy it will render the content
inaccessible to identifiable groups of users whose needs are addressed
by the checkpoint.

Conformance class 1, Device and modality independence:

Essential: checkpoints 1.1, 1.2, 1.5 and 4.1.

Recommended: checkpoints 1.3, 1.4, 4.2, 4.3 and 4.4.

Conformance class 2, Interaction and navigation:

Essential: Checkpoints 2.3, 2.4, 2.5, 2.6 and 2.7.

Recommended: checkpoints 2.1 and 2.2.

Note: It has sometimes been stated, though never demonstrated in
detail, that every checkpoint under guideline 2 is "essential", in
that failure to satisfy it will make the content inaccessible to an
identifiable groups of users. If such an argument could be borne out,
it would undermine the distinction proposed here between "essential"
and "recommended" checkpoints, at least so far as guidelines 2 and 3
are concerned.

Conformance class 3, Comprehension:

Essential: checkpoints 3.3, 3.4 and 3.5.

Recommended: checkpoints 3.1 and 3.2.

As noted above, the distinction between "essential" and "recommended"
checkpoints, as it applies to guideline 3, may be problematic; but no
one has so far proposed sustained arguments to demonstrate that every
checkpoint under guideline 3 is inherently capable of making the
crucial difference between accessibility (i.e., comprehension) and
lack thereof, for an identifiable category of readers.

Note: If some such conformance system were adopted, then I would recommend,
by default or as an optional view, ordering the checkpoints under each
guideline by listing the "essential" checkpoints first, followed by
the "recommended" checkpoints. It would also be helpful to choose
better terms than "essential" and "recommended" (the latter in
particular may be confusing, given that the entire document is
referred to as a W3C Recommendation; but "optional", or "inessential"
or even "suggested" give the wrong impression. Recommended checkpoints
are just that--very important but not so indispensable that failure to
satisfy them renders the content absolutely inaccessible to
identifiable groups).

Possible simplifications:

Here is a non-exhaustive list of variations on the above proposal:

1. Combine interaction/navigation and comprehension into a single
   class, thereby defining two conformance classes, viz., (1) device
   and modality independence; and (2) comprehension, interaction and navigation.

2. Drop the distinction between "essential" and "recommended", either
   completely, or in such a way as to retain it in the "device and
   modality-independence" class, where the issues seem to be more
   clear-cut. In the latter case, the notion of
   "essential/recommended" would be dropped and one would simply
   define the "device and modality independence" class as:

All checkpoints in guidelines 1 and 4, but must include checkpoints
   1.1, 1.2, 1.5 and 4.1.

3. Drop the "conformance classes" as defined above, and simply require
   that a conformance claim list the checkpoints which have been met.
   This version of the conformance scheme could be implemented with or
   without the notion of "essential checkpoints" (see proposal 2,
   above).

Note that the proposed distinction between "essential" and
"recommended" checkpoints is, in effect, a two-tiered priority scheme,
which may be contrasted with the three-tiered system defined in WCAG
1.0. The inclusion of such a scheme in the above proposal may be
supported on the following grounds:

1. Simplicity.

2. Given the division of the guidelines in to (two or three)
   conformance classes, a two-level priority system seems sufficient,
   especially in view of the relatively small number of checkpoints in
   each class.

3. Given the greater generality of the checkpoints in WCAG 2.0 by
   comparison with those of WCAG 1.0, it is harder to make
   fine-grained priority decisions (that is, to classify the
   checkpoints according to a three-level hierarchy). The two-level
   hierarchy makes prioritisation easier in this respect.

Received on Friday, 7 September 2001 02:58:55 UTC