- From: David Poehlman <David.Poehlman@usmint.treas.gov>
- Date: Fri, 23 Jun 2000 09:14:10 -0400
- To: "'Eric Hansen'" <ehansen7@hotmail.com>, w3c-wai-ua@w3.org
- Cc: ehansen@ets.org
Hi Eric and All, I have a few comments marked with dp in your message below: 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. dp in your fourth item above, thia could make the checkpoint too long and to further add to this, the reason over all for identifying minimal requirements is to assist in determining what direction the guidelines should take in that it is s self evaluation tool of which we actually need more not less. 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). dp we are not reducing checkpoints. We are expressing a minimum ground for implementation of the checkpoints. I agree though that in some cases, this might be difficult to define but that should be expressed in the minimal statement and that at times, the checkpoint is a minimum in and of its self. 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. dp the intent to do just the opposite can be stated clearly at the front of the minimum req document. 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. dp Just the opposite. The checkpoints stand alone. developpers have asked us for adocument that clearly states how the checkpoints can be implemented. Nowhere in the minimum req document or in the language do we suggest that this a new priority. the document further expresses but perhaps not clearly enough that the minimum req is over arching and not necessarily all inclusive of meeting the checkpoint. think of it as a guide to the techniques document if you wish. 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. dp This seems a valid statement on its face however, checkpoints should describe a broad goal for achieving accessability and any enhancement or explanation needed should be provided in appropriate ways. The checkpoints are and should be simple declarative directives which by their highly complex implementive nature need as much support as they can get. We are after all mostly aiming at developpers and thos who manage development and need to provide appropriate documentation to that end. in another way with the checkpoints being as simple and directive as possible, we can almost turn them in to a feature list or set of feature lists for cunsumers to use when shopping for a ua or for standards bodies to use <heaven forbit> when writing standards for procurement guidance. do we have any procurement specialists on our group? should we scare up one or two? 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. dp the slippery slope we were headed down was heretofore not having a process in place for evaluating the checkpoints. This process has led to some positive changes and a better understanding of what the checkpoints represent and how they apply. 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> dp either way, the same intent is expressed and if a new proposal is made it will be considered. this is not a technique however, it is part of the requirement. ==== 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 09:11:30 UTC