Re: Conformance Level

The definitions of priority and conformance lelvels are inextricably
connected. One way of eliminating priorities would be to specify, in the
conformance statement, exactly which checkpoints had to be satisfied at
each level of conformance. There are several reasons why such a solution
would be a retrograde move and why it should not be supported. First, by
eliminating the priorities from the document, one would thereby remove a
very convenient and practical indication, associated with each checkpoint,
of the level of conformance to which it pertains (priority 1 checkpoints
relate to level A only, priority 1 and 2 checkpoints relate to levels A
and double-A; priority 3 checkpoints relate to all three conformance
levels). Thus, if you want to satisfy the guidelines at a double-a level,
you can simply work through the list, ignoring priority 3 checkpoints.
This makes it very easy to connect the intended level of conformance to
the task at hand, its being recognised that level A compliance is an
important short-term goal, whereas tripple-A compliance could be regarded
as a medium-term objective from the standpoint of an organisation or web
site maintainer.

If the priorities were removed, then in order to implement a specific
priority level one would need a list of which checkpoints pertained to
which level of conformance; and a user of the document would have to
cross-reference each checkpoint against the relevant list. For me at
least, and I suspect for many others as well, this would be impractical,
and would probably act as a disinsentive that would discourage adoption of
the guidelines.

A second shortcoming of such a proposal is that the conformance statement
would then become very lengthy and complex, as it would have to specify
all of the individual checkpoints that related to each conformance level.

A system in which, instead of a priority, each checkpoint was labeled with
the names of the conformance levels to which it pertained (E.G. a priority
2 checkpoint would carry the designation, "A and double-A") is also
problematic due to the existence of so-called "split priorities" in the
document, which it has not been possible to eliminate. Their existence is
a reflection of the observation that the importance of satisfying
particular requirements can vary depending on the nature of the document
as a whole. For example, language identification is more important in
multilingual texts than in unilingual documents, owing to the difficulty
of identifying language switches automatically based on textual analysis;
whereas in the case of a monolingual text the language can more easily be
identified, or at least it would be more reasonable to expect the reader
to identify the language and set a software option. Other examples of
split priority in the guidelines result from the differing importance that
certain information can have in the context of a variety of documents.

I would also dispute the assertion that the existing scheme of priorities
is complex or difficult to understand. If it is well explained (and the
definitions are clear and accurate), then it should not create any
substantial obstacle to the application of the guidelines. Education in
the use of the WCAG is undoubtedly needed; especially at a priority 2
level and above, it fundamentally challenges the approach to web site
development to which many authors have grown accustomed. This educative
role is being most capably exercised by the Education and Outreach Working
Group, as I understand the present circumstances.

The basic point of the present contribution, however, is to argue that the
existing priority and conformance definitions are better than the simpler
alternatives which I have considered. The only prospect of simplifying the
system appears to reside in the possibility of attempting to eliminate
split priorities; but these were arrived at after much thought and
discussion, and I doubt that they could be readily removed without
undermining the integrity of the document, though this issue clearly
deserves further consideration when and if the guidelines are redesigned.

Received on Tuesday, 6 July 1999 04:46:45 UTC