Re: A Proposal To Not Establish "Minimal Requirements"

I think that I agree with virutally all of what Charles has said. I 
certainly agree that the efforts to establish minimal requirements is 
extremely useful. I am merely suggesting how act upon what we are learning.

My point about "padding" is that it is confusing to first say that failure 
to do 1.0 times Z will make access impossible and then come along and 
indicate that we can correct the accessibility gap by doing 0.7 times Z 
(i.e., the minimal requirement). It begs the question: "Why was 1.0 times Z 
required in the first place?"

>From: Charles McCathieNevile <charles@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 01:44:09 -0400 (EDT)
>
>I am sympathetic to Eric's proposal, and in particular agree that where
>possible the checkpoint itself should express the minimum requirement
>clearly. However I disagree about the dfirection in which requirements are
>being padded by establishing minima - what we are saying is that at 
>Priority
>X, this is what need to be done, and in some cases we are providing further
>information about how to solve this problem at priority X+1 or X+2. We 
>could
>try to strip them down into seperate components, but there comes a opoint
>when we have too many checkpoints. Since there is no magically right answer
>to the question "where is that point?" we essentially ahve to make the
>decision based on how easy it is to read the document and nderstand it. My
>experience suggests that shorter is good, since people can remember the
>requirements at the start when they get to the end, although in applying
>those they may have to go into further detail, such as in teh techniques
>document.
>
>SO I think the establishment of minima, where they are not clear from the
>text of the checkpoint, is a valuable exsercise. It is also important as a
>process towards demonstrating verifiability - if we can't dsscribe what 
>does
>or does not meet the requirements, then the checkpoint is probably not, in 
>my
>opinion, easily verified.
>
>cheers
>
>Charles McCN
>
>On Fri, 23 Jun 2000, Eric Hansen wrote:
>
>   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.
>
>   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.
>   2. Feasibility. A checkpoint should be practical from a technical and
>   practical standpoint.
>   3. Verifiability. One should be able to verify conformance.
>   4. Minimalism. The checkpoint itself should express the minimal 
>requirement.
>
>   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. A checkpoint that is already minimalistic is not 
>susceptible
>   to further reduction (unless justified by new information).
>
>   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.
>   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.
>
>   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. 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.
>
>

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

Received on Friday, 23 June 2000 09:12:39 UTC