Hi Everyone,
Sorry for the length of this text, but this has been a bit of a hard concept
to express.
Tom
---
This is a proposal developed by Tom Croucher and Michael Cooper to provide a
normative mechanism for ensuring compliance with the WCAG without a
requirement for us to provide normative techniques documents. We suggest
instead a normative process for verifying techniques that have been applied.
The problem we face is that the ability to claim conformance to the WCAG
will be important to many consumers. Since WCAG 2 is technology-agnostic,
there is no direct way for many of the guidelines that one can achieve
conformance except via implementation in a specific technology. This has
raised the issue that particular technology implementation techniques for
WCAG need to be considered sufficient for conformance. One mechanism that
has been proposed is that Checklists of technology-specific techniques be
normative.
In discussion with the Techniques Task Force, we consider normative
checklists highly undesirable. The checklists are closely tied to the
techniques themselves. The techniques should not be normative for a few
reasons:
* we would require authors to apply only the techniques we happen to have
considered and could preclude other viable ways of conforming to WCAG;
* we would have to go through a more stringent process to update techniques,
dramatically increasing the likelihood that the techniques will fall behind
the level of current technology, which is one of the things the
technology-agnostic structure of WCAG was designed to avoid;
* we would preclude WCAG conformance for any technology for which we have
not provided techniques, whether as a result of lack of resources or because
the technology is not an open standard.
However, we are aware that the techniques as currently conceived are
intended to fulfill some normative requirements of WCAG. For instance, the
determination of the testability of a guideline is likely to be made through
our ability to create techniques for the guideline, and test files for the
techniques against which demonstrations of our testability requirements can
be made (including an acceptable degree of inter-rater reliability). We
intend that the techniques we create will fulfill these requirements (in
spite of not being normative). The challenge is to provide a way to ensure
that people using techniques not created by us will have the same assurance
of WCAG conformance.
The proposal is to make a normative conformance requirement that web sites
use only techniques that have demonstrable proof that they have followed a
sufficiently rigorous QA process to ensure that they do, in fact, meet the
WCAG requirement. This is, in practice, asking web sites to show that they
can prove all the techniques used for the accessibility of their content
have been tested with due diligence. This, of course, does not preclude
checking that all content can be proved to be accessible under the success
criteria of the main set of guidelines, it merely adds a more manageable
approach to checking conformance.
This proposal would require the guidelines to provide a skeleton model of a
QA process for technique development. This would likely be drawn from the
methods already in use for validating the techniques and techniques
documents. This skeleton model would then be used as a basis for QA
methodologies used to validate techniques used in conformance claims. Sites
claiming WCAG conformance would be expected to be able to prove on demand
that their techniques have been tested and determined to meet our
inter-rater reliability requirements. This process would not impose any
specific additional requirements on the nature of conforming content and we
do not propose to require there be a statement on the site indicating they
have followed this process. But if the site claims WCAG conformance and that
is challenged, documentation of the testing process would need to be
provided. Of course, sites that choose simply to use our own techniques
could simply refer to documentation we would provide as part of our
techniques development process.
This proposal is certainly not complete, and there are known challenges (#1:
is it really ok to make a normative requirement for a process, not a
state?). But it does seem that it provides a way out of the extremely
undesirable alternative of making techniques and checklists normative.