A Proposal To Not Establish "Minimal Requirements"

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.

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.

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

Received on Friday, 23 June 2000 01:22:28 UTC