The problem of verification in WCAG 2.0

The problem which has beset certain checkpoints in the Web Content
guidelines has sometimes been misleadingly characterized in terms of a
distinction between "subjective" and "objective" requirements. I would
suggest that such terminology is quite unhelpful as an explanatory
framework in which to understand the nature of the guidelines and the
extent of their verifiability. Instead of developing a detailed critique
of what I regard as a dubious distinction, I shall instead turn to the
core of the problem.

The main difficulty with certain checkpoints (e.g., provide consistency of
presentation, use the clearest and simplest language appropriate to the
content, etc.), is one of vagueness: it is unclear under what
circumstances such checkpoints apply, and what should be taken as
satisfying them. If criteria of conformance could be given that would
allow most informed judges of compliance to agree, in the overwhelming
majority of cases, upon whether the requirements had been met or not, this
should provide a sufficient operational basis for the guidelines. That is
to say, if most people who understand the guidelines and apply them in
good faith, would agree, in most cases, as to whether a checkpoint had
been satisfied, then this is a sufficient degree of definiteness to permit
the making of credible conformance assertions. To achieve this degree of
precision in the formulation of the guidelines, I would suggest that the
following strategies are available:

1. For those checkpoints which are deemed hard to verify, for example the
two cited above, write "specific checkpoints" that would clarify the
requirements in their application to different types of circumstances.
These "specific checkpoints" (what Gregg terms "checkpoint solutions")
need not be dependent upon any single technology, but would instead be
analogous to the WCAG 1.0 "core techniques". Terminologically, this would
yield a division of the guidelines into "general checkpoints" and
"specific checkpoints", with some, but not all, of the latter being
specific to particular technologies, whereas others would operate more as
elaborations of general requirements, though without being limited to any
one technology (for example, checkpoints elaborating the requirement to
introduce a text equivalent, or explaining how to determine whether the
clearest/simplest language has been employed in a given context).

2. Alternatively, or in addition to item (1), abstract the requirements
which have been deemed "hard to verify" into a separate guideline or
checkpoints, but instead of treating them as individual requirements which
must be implemented and assessed independently, regard them as a set of
factors which enhance the accessibility of content. In the priority
scheme, place a high priority on the implementation of the group as a
whole, but give each of the individual requirements a low priority (in
other words, observance of these factors, taken collectively, can have a
significant impact upon accessibility, and thus it is important to apply
as many of them as are relevant under the circumstances of the web site or
content in question, but the individual requirements in this category will
each have a low priority). This would direct attention to the set of
design requirements as a whole, rather than to each of its individual
components--strive for a design which meets as many of these as
practicable, but non-observance of any single factor will have a
comparatively limited effect on over-all accessibility.

3. The other alternative, of course, is simply to delete from the
guidelines any checkpoints for which there are no clearly definable and
applicable conformance criteria. This option runs the risk of omitting
from the WCAG significant areas of access concern, especially in the
cognitive area.

Received on Wednesday, 11 April 2001 21:53:01 UTC