RE: 4.1 revised

we had similar wording originally but changed it to require review of  each
instance that the author dose not conform
the concern behind the change was a practical one. We wanted to avoid people
just taking a quick look at the content and  saying "oh yeah this content is
as clear as appropriate"

It seems more rigors to require review of each instance were the author dose
not conform - less easy to justified passing content as conformant without
an in-depth review.

All the best,

Lisa Seeman

UnBounded Access

Widen the World Web


lisa@ubaccess.com <mailto:lisa@ubaccess.com>
www.ubaccess.com <http://www.ubaccess.com/>
Tel: +972 (2) 675-1233
Fax: +972 (2) 675-1195



-----Original Message-----
From: w3c-wai-gl-request@w3.org [mailto:w3c-wai-gl-request@w3.org]On
Behalf Of Jason White
Sent: Wednesday, October 23, 2002 10:59 PM
To: Web Content Guidelines
Subject: 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 12:10:01 UTC