Re: 4.1 revised

Here is a suggestion that may, or may not, prove useful. I haven't
thought through its consequences in detail. Instead of having an
"additional ideas" section after the success criteria, we could
integrate the non-testable items into the success criteria themselves
as sub-points (itemized lists) under the review requirements. Items
that are truly additional advice (useful suggestions but need not be
included in a qualitative review) could still be noted separately from
the success criteria. This suggestion has implications for checkpoint
4.1, which would then serve as a model that could subsequently be
applied to some of our other checkpoints where corresponding issues
emerge.

To be more specific, if this idea were carried forward the checkpoint
4.1 success criteria would be largely as Avi and Lisa have proposed,
but with a slight adjustment, as outlined presently.

Level 1
You will have successfully met checkpoint 4.1 at the minimum level if

The content has been reviewed and is believed to have as many of the
following characteristics as possible, taking into account its purpose
and subject matter (better wording could be used here):

[Avi's list of level 1 characteristics belongs here, with a different
numbering scheme - perhaps letters or Roman numerals, or perhaps as an
"unordered list" (e.g., XHTML UL element)]

Level 2
Same format as above.

Level 3
You will have successfully met checkpoint 4.1 at level 3 if
1. New material is tested with potential users for ease of
accessibility.
2. A controlled language is used.
3. Support for conversion into symbolic languages has been given.


Note that my purpose here is not to express any opinion as to the
items that Avi and Lisa have included in their list, but merely to
suggest a way in which the success criteria can be reworked so that
the non-testable items are actually included, but without reducing the
requirement for testability as such by specifying review and assurance
requirements as success criteria, in accordance with decisions that
the working group has already taken.

The main elements of this proposal already have precedence in our
guidelines. Some individual success criteria already contain lists of
items (typically unordered lists). We have already decided, though it
has not been implemented in a draft yet, that to satisfy a review
requirement an implementor must take into consideration the various
non-testable factors that the guidelines specify (presently in
"additional ideas" sections). Given that these items must be taken
into account in conducting to review, there seems little reason why
they shouldn't be listed as items under the review requirements
themselves, in the "success criteria" section of each checkpoint,
except, as already noted, for those items that  truly belong as additional
suggestions.

This proposal therefore makes no substantive change to what is
normative or to any of the working group's decisions regarding
testability. It also ensures that the non-testable items, which would
be listed under review requirements, become part of the "success
themselves and cannot be so easily overlooked or omitted from
checklists.

As a corollary, we can establish several rules for checklist
generation (this brings us to the other item on tomorrow's meeting agenda:

1. A checklist must list all of the guidelines and checkpoints in WCAG
   2.0.

2. If the checklist relates to a particular format, API, protocol
   etc., or to a combination thereof, and there are no relevant
   techniques for a particular checkpoint, this must be stated
   explicitly following the text of the checkpoint itself.

3. If there are relevant techniques for a particular checkpoint
   included in the checklist, then they must be listed under the
   relevant success criteria. Furthermore, all success criteria for
   the checkpoint must appear in the checklist, even if the techniques
   only address a subset of them.

Precise details of format could be worked out later.

Received on Thursday, 24 October 2002 01:59:21 UTC