Re: Issue #10

Since several participants in this working group have expressed
support for the kind of conformance scheme that I suggested last week,
I shall here provide a more concrete, and indeed simpler, version.

Disclaimer: I am not necessarily advocating this as a solution.
Instead, I am trying to transform various suggestions which have been
raised on this mailing list, into a specific proposal, 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 (defined in cooperation with ER WG).

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

Note: if it is possible to combine the RDF with an XHTML page
specifying the conformance claim, so that both machine-readable and
human-readable versions are given, an example of this should be
provided.

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: this is where it starts to break down; any checkpoint under
guideline 2, if not satisfied, will arguably make the content
inaccessible to somebody.

Conformance class 3, Comprehension:

Essential: checkpoints 3.3, 3.4 and 3.5.

Recommended: checkpoints 3.1 and 3.2.

Note: the same qualification applies as in the case of guideline 2.
Also, there is bound to be a debate concerning whether checkpoint 3.3
should be in the "essential" or "recommended" category (it is time to
put on the flame-resistant attire).

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).

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.

2. Drop the distinction between "essential" and "inessential", 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).

Received on Sunday, 26 August 2001 04:40:19 UTC