Re: CONSENSUS REVISED 9-20-01

At 05:30 AM 2001-09-21 , Jason White wrote:
>How would this tripartite division of the normativity continuum (from
>"must", i.e., normative, at one end, to "may", i.e., non-normative, at
>the other) be reflected in the guidelines? 
[...]
>In essence I am looking for a concrete proposal that the working group
>can discuss.

AG::

OK, here's a blue sky version:

1 * Guidelines go away.  They are replaced by scenarios that construct a
situation as concretely or as abstractly as is convenient to state success
criteria.  Success criteria are stated by sentences which use MUST and SHOULD,
and refined or clarified by sentences that user MAY.   These statements are
made about the things that appear in the scenario.  There can be any number of
success criteria that apply to any given scenario. All of these apply within
the view of Web browsing and serving exposed by one scenario or another.  The
success criteria may be interelated, such as where one says a site MAY meet
the
requirement for equivalents to be available from the same URL by providing
well
oriented and cross-disability accessible hyperlinking back and forth among
pages that work well for one delivery context and those that work well for
another.

2 * Checkpoints go away.  They are replace by the success criteria, which are
stated inline in the prose plus exhibits discussion of the scenarios
without an
intervening document structure level.

3 * Conformance is based on the success criteria, the MUST and SHOULD
statements, that is to say sentences.  Each sentence with a MUST or SHOULD in
it is an entry in the evaluation menu.  This is standard industry practice.

4 * MUST statements must meet a "substantially objective boolean" text. 
SHOULD
statements need  not.  Policy setters will immediately understand that if they
wish to set objective boolean criteria in the areas of SHOULD statements, they
have clear guidance as to the objective of these criteria and no statement
from
W3C as to what the precise boolean cutoff should be.  That is about as usable
as we can make the writing for policy setters.  They eithe pass through the
SHOULD to their implementers, or if the wish to enforce in a more rigorous
fashion they know that the criteria they are enforcing are entirely in line
with what others are pursuing that have adopted these guidelines as guidance.

5 * Prioroties go away.  Policy setters have sources of priorities that we
don't have visibility into.  We should put objective facts before them and let
them implement from what we give them with total Chinese Menu freedom.  Our
leading failure with WCAG 1.0 in the area of "usable by policy setters" was a
simple matter of shooting ourselves in the foot.  We got carried away and put
poison pill language in the document in an attempt to ensure that they could
not "abuse" what we had to offer, and as a result they couldn't use it.

Al

PS:  Baby Steps, that is to say the minimum implementation from the above
dream
scenario, is points 3 and 4.  This is what it takes for the SHOULD option to
get us out of the endless small circles box we have put ourselves in.  The
rest
is gravy if we can do that.

>Al Gilman writes:
> > So far this list only talks about 'normative' as though what we say is
either
> > 'normative' or 'not normative.'
> > 
> > In the IETF they have found it helpful to have three grades of things that
> > they
> > find to say.
> > 
> > These can be summarized by the graded series [MUST, SHOULD, MAY].  There
are
> > other keywords but they equate to these three in terms of their effect on
> > 'normativity.'
>
>How would this tripartite division of the normativity continuum (from
>"must", i.e., normative, at one end, to "may", i.e., non-normative, at
>the other) be reflected in the guidelines? Would it be used in the
>checkpoints themselves, in the success criteria, or elsewhere? How
>would it interact with the priority scheme? Note that in WCAG 1.0,
>checkpoints at all three priority levels are normative; the
>differences between them are based entirely on "impact"--that is, the
>effect of implementing or not implementing the checkpoint upon the
>accessibility of the content to identifiable groups of users.
>
>Thus, on the one hand we have a distinction between normative,
>recommended/advisory and non-normative assertions, and on the other a
>distinction between differing priority levels. If both distinctions
>were to be relied upon in the document, how would you implement them
>and avoid potential confusion?
>
>In essence I am looking for a concrete proposal that the working group
>can discuss.
>

Received on Sunday, 23 September 2001 20:54:53 UTC