Re: What determines what goes in level 1, 2, 3 etc as success criteria

I think Gregg's summary is an accurate description of how we have made
decisions in the past, and how they should be made in the future.

I still think, after we have agreed on these (or similar) principles,
we should write them up and include a summary in the guidelines
document itself so that readers can gain a greater understanding of
what success criteria are, and how the conformance levels are defined.
By doing so, we reduce (but, realistically, cannot eliminate) the risk
that the docment will be inadvertently misused by those who are
unaware of the rationale underlying the definitions of success
criteria and conformance levels. That is, the guidelines document
should be clear in itself as to how the success criteria and
conformance levels are defined; a reader should not have to search for
our requirements document to obtain this degree of insight (though
naturally, the requirements document will elaborate our thinking to a
far greater extent than any rationale set forth in the guidelines).

Instead of a "level 4", we could simply head the level "advice", as
that is what it is. In that case, we could easily refer to it in
success criteria, as in:

The content has been reviewed, taking into account the advice under
this checkpoint, and is believed to be...
where "advice" is a link to the corresponding advice section for the
particular checkpoint.

which is what we originally intended to provide for in our assurance
requirements (see my earlier message on the subject).

As Gregg pointed out, the "advice" then becomes part of the
requirement in as much as it has to be taken into consideration in
conducting the review required by the level 2 success criteria. As
Gregg also said, with this approach, the advice can't easily be
omitted from checklists.

Thus my proposal is:
Call the "advisory" section "advice"; explain its purpose in the
introduction. Explain, in the introduction or an appendix, the
rationale behind the success criteria and conformance levels.

One more proposal and I shall finish for the night: for the purpose of
facilitating transitions, we should document precisely what
conformance claims under WCAG 2.0 can be made in respect of content
that meets levels A, double-A and tripple-A of WCAG 1.0, including the
"required" technologies/features list as per checkpoint 5.2. This
should make it easy for developers who have already conformed to WCAG
1.0 at some level, to make a corresponding claim on WCAG 2.0, and to
know which additional requirements they will have to meet in order to
conform to WCAG 2.0 at a higher level.

Received on Wednesday, 7 August 2002 07:16:45 UTC