Re: A Proposal To Not Establish "Minimal Requirements"

I think that I agree with virtually everything that Ian has said.

I think that the working groups must strike a balance between the various 
characteristics of comprehensibility, feasibility, verifiability, and 
minimalism. That balance will vary from checkpoint to checkpoint. Just as we 
have some checkpoints that are relatively hard to verify, we will also have 
some checkpoints that don't express minimal requirements very well.

The effort to define minimal requirements has been extremely useful. I would 
be in favor of ensuring that our understanding of mimimal requirements is 
reflected in the checkpoint itself, as techniques, or as notes, but not as a 
new category of normative requirement.

>From: Ian Jacobs <ij@w3.org>
>To: Eric Hansen <ehansen7@hotmail.com>
>CC: w3c-wai-ua@w3.org, ehansen@ets.org
>Subject: Re: A Proposal To Not Establish "Minimal Requirements"
>Date: Fri, 23 Jun 2000 04:24:54 -0400
>
>Eric Hansen wrote:
> >
> > Version: 23 June 2000, 01:03 hrs
> > To: UA List (w3c-wai-ua@w3.org)
> > From: Eric Hansen
> > Re: A Proposal To Not Establish "Minimal Requirements"
> >
> > I like the way the Ian has organized the document "Determining 
>Conformance
> > to the User Agent Guidelines" [1]. It helps show why further 
>clarification
> > of certain checkpoints may not be necessary and helps focus our 
>attention on
> > a certain checkpoints for which further work may be needed.
> >
> > Proposal
> >
> > I propose we do NOT establish "minimal requirements." This may seem like 
>a
> > radical proposal, but I will explain why I take this position. This memo
> > provides a rationale for this proposal and suggests other ways to 
>resolve
> > the reviewer's concerns. The memo also provides examples of the proposed
> > resolution; I would like to get feedback on this proposal before trying 
>to
> > "fix" more checkpoints.
>
>For the most part, I agree with Eric's proposal (and in fact,
>our changes in the last two versions of the document have gone
>in this direction). However, while there are "obvious" cases
>such as the examples Eric provides below, I think there are difficult
>where we might not be able to capture the abstract requirement and
>the minimal requirement in a compact and effective form. One risk
>of pruning checkpoints as one would trees is that the forest may
>disappear. Yes, the checkpoints should be as precise as possible,
>and verifiable, but if the expression of the requirement is lost,
>I might prefer abstracting slightly and expressing a "clear idea"
>of what's expected. Maintaining a degree of abstraction affords us
>some flexibility in interpretation, which is both a blessing and
>a curse.
>
>Also, I think there are some checkpoints where we cannot
>enumerate all the possibilities (e.g., configuration of
>keyboard input) and therefore must settle for a forest-like
>approach.
>
>Recall how we modified the structural navigation checkpoint, from
>"Allow the user to navigate according  to structure" to a form
>that reflects the author's need more clearly: "Allow the user
>to navigate efficiently to and among important structural
>elements identified by the author." It might be beneficial
>to refine it further as the minimal requirements, something
>similar to:
>
>    "For markup languages with known semantics, allow the
>     user to navigate forward sequentially through important
>     structural elements. For other languages, allow forward
>     sequential navigation through the document object."
>
>However, I think there are some checkpoints where we cannot
>enumerate all the possibilities (e.g., configuration of
>keyboard input) and therefore must settle for a forest-like
>approach.
>
>I look forward to reactions from others in the Working Group.
>I've sprinkled a few more comments below.
>
>   - Ian
>
> > Characteristics of a Good Checkpoint
> >
> > I think that the checkpoints in the WAI guidelines documents should meet
> > several characteristics. The first three points have been discussed 
>before.
> > I'd like to propose a fourth point.
> >
> > 1. Comprehensibility. The meaning of the checkpoint should be clear.
>
>Yes.
>
> > 2. Feasibility. A checkpoint should be practical from a technical and
> > practical standpoint.
>
>Yes.
>
> > 3. Verifiability. One should be able to verify conformance.
>
>Yes, except sometimes this is hard, even when the requirement of
>the checkpoint is clear.
>
> > 4. Minimalism. The checkpoint itself should express the minimal 
>requirement.
>
>Yes.
>
> > I think that these characteristics are related and somewhat dependent on
> > each other. We might think of these four characteristics as different 
>facets
> > of a unitary concept that we might call "validity" of the checkpoints. 
>(A
> > unitary concept of "validity" is also found in the area of educational
> > testing.)
> >
> > Minimalism
> >
> > If the working group succeeds in clearly expressing minimum requirements
> > within the checkpoint itself, then there is no need for separate minimal
> > requirements.
>
>I agree. And I would note that some of our efforts to establish minimal
>requirements have, thus far, led to modifications that have shrunk
>the scope of the checkpoints to minimal requirements.
>
>In some cases, however, I haven't seen a way to express some
>abstractions
>AND have that phrasing capture minimal requirements.
>
> > A checkpoint that is already minimalistic is not susceptible
> > to further reduction (unless justified by new information).
>
>I don't agree. For instance, it would not be possible, nor
>desirable, to list all the possible keyboard configurations that must
>be available to the user. Therefore, we say "allow the user to
>configure the keyboard configuration." That's the minimal form
>that meets our needs.
>
> > Pitfalls of Establishing Separate Minimums
> >
> > There would be several negative consequences to establishing minimal
> > requirements that are separate from the checkpoint statements 
>themselves.
> >
> > 1. Indication of Padding. To establish a minimal requirement that is
> > separate from the checkpoint statement itself may be seen as an 
>indication
> > that we have "padded" the checkpoints, i.e., made requirements that go
> > beyond what is justified by their actual impact on people with 
>disabilities.
>
>I agree that we must be cautious here.
>
> > 2. Confusion About the Number of  Priority Levels. To divide or parse a
> > checkpoint (especially a Priority 1 checkpoint) into a "minimal" portion 
>and
> > "beyond minimal" portion would, in effect, add a new level of priority,
> > perhaps one that we might call Priority 0 (zero). By having separate 
>minimal
> > requirements, we would be saying, in effect: "Even though we rate this
> > checkpoint at Priority 1 (meaning that some disability group would find 
>it
> > "impossible" to access content if this were not followed), there is yet
> > another level of priority -- Priority 0, for which failure to conform 
>would
> > make content "REALLY impossible" to access." The non-sensical nature of 
>such
> > an implication would add confusion about the meaning of the priority 
>levels.
>
>
> > 3. Indication of Failure to Make Checkpoints Comprehensible, Feasible, 
>or
> > Verifiable. I think that since the four facets of comprehensibility,
> > feasibility, verifiability, and minimalism are related to each other, 
>then
> > failure to ensure that checkpoints statement themselves are minimalist 
>may
> > indicate that there are problems in the other characteristics as well.
> >
> > In summary, I think that, to the extent possible, we should make the 
>minimal
> > requirements obvious in the checkpoints themselves, at least to the 
>extend
> > possible, given the necessity for comprehensibility, feasibility, and
> > verifiability.
>
>Yes, I agree with that.
>
> > Solution
> >
> > I think that the solution is to simply clarify the checkpoints 
>themselves as
> > necessary but not go down the slippery slope of providing minimal
> > requirements.
>
>I agree, but haven't found it "possible" in some cases to state the
>requirement and the minimum in a compact or useful form.
>
> >  If we want to add clarifications, advice, guidance, or other
> > information beyond the checkpoint itself, that can be put in a note or 
>in
> > the techniques. In some cases, new checkpoints might need to be added. I
> > think that the "expected solutions" need to be treated this way as well.
> >
> > Examples
> >
> > Checkpoint 2.2:
> >
> > <OLD, 10 June 2000 UAAG as cited in 20 June Determining Conformance
> > document>
> > "Checkpoint 2.2 For presentations that require user input within a 
>specified
> > time interval, allow the user to configure the time interval (e.g., to
> > extend it or to cause the user agent to pause the presentation 
>automatically
> > and await user input before proceeding). Minimum: Pause.
> > </OLD>
> >
> > <NEW>
> > Checkpoint 2.2 For presentations that require user input within a 
>specified
> > time interval, allow the user to configure to cause the user agent to 
>pause
> > the presentation automatically and await user input before proceeding.
> >
> > [If the working group wishes have the user be able to "extend" the "time
> > interval", then that should be expressed either in a technique, a note, 
>or a
> > new lower-priority checkpoint.]
> > <NEW>
> >
> > ====
> >
> > Checkpoint 4.16:
> >
> > <OLD, 10 June 2000 UAAG as cited in 20 June Determining Conformance
> > document>
> > Checkpoint 4.16 Allow the user to configure the user agent to limit the
> > number of open viewports. Minimum: One.
> > </OLD>
> >
> > <NEW>
> > Checkpoint 4.16 Allow the user to configure the user agent to limit the
> > number of open viewports to as few as one viewport.
> > <NEW>
> >
> > [1] http://www.w3.org/WAI/UA/2000/05/ua-minreqs
> >
> > ________________________________________________________________________
> > Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com
>
>--
>Ian Jacobs (jacobs@w3.org)   http://www.w3.org/People/Jacobs
>Tel:                         +1 831 457-2842
>Cell:                        +1 917 450-8783

________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com

Received on Friday, 23 June 2000 09:26:47 UTC