Re: A Proposal To Not Establish "Minimal Requirements"

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.

Received on Friday, 23 June 2000 01:44:12 UTC