Contradictory/confusing requirements wording

Hello all.

I have a problem with our wording on 1.1 and 1.2. 
Here's a conversation I had with Ian, that I think this list should be involved in.

Aaron writes:

> 1.1 Ensure that the user can operate the user agent fully through 
> keyboard input alone, pointing device input alone, and voice input 
> alone. 

> Maybe it's just me, but this seems to contradict the note 
> below it, which says you don't need to satisfy the pointing device and 
> voice portions of the checkpoint. Shouldn't a "Note" be informational, 
> and shouldn't the checkpoint be a complete, clear statement of the 

> requirement*?


Ian writes:
So this requires a bit of explanation. The conformance model works
as follows: You have to do everything by default (this is called
unconditional conformance). This means implementing all media types
and satisfying all checkpoints for all three input types. 

You can claim conformance for less, and not claim conformance for
voice. But you have to say so in your claim. Similarly, you can
not support speech output (there are three checkpoints for speech
output requirements) and still conform, but you have to say you
don't do them in your claim.

So the question is how do you say "You have to support voice
input unless you say you don't in your conformanc claim"? The
solution we've adopted is to not make this type of statement
in the checkpoint itself. Therefore, by default you do exactly
what the checkpoint says. In the section on conformance the
reader finds the information about certain exemptions they may
claim. 

The Note may seem contraditory, but it's just an attempt to
alleviate the terror of reading the requirements of the first
checkpoint. 

None of the other checkpoints say "you have to do this for
images/animations/video/audio/speech...unless of course you
don't do images/animations/video/audio/speech." 
 
Aaron writes:

I understand your reasoning, but that doesn't change the fact that you don't > know about the conformance stuff yet if you read this document in the normal > order, from front to back.
Ian writes:
Agreed

Aaron writes:

I really think people are only going to read the conformance stuff once they >feel they've gotten close to conforming. Until then, they are going to read >this as a list of requirements. Personally, I wouldn't mind if it said "For >each input technique that you support directly (keyboard, speech, pointing >devices), ensure that all of the functionality in your software is available >through that technique". That way when a product manager picks this up to see >what he's supposed to do, it's all clear.
Ian writes:

I agree that not scaring product managers is a good thing.

If we say something like this:

 1.1 Ensure that the user can operate the user agent fully 
     through keyboard input alone. Ensure that the user
     can also operate the user agent fully through pointing 
     device  input alone and voice input alone as well (unless
     a conformance claim states that the user agent doesn't
     conform for voice or pointing device input).

Then we should say this as well:

 4.11 Allow configuration and control of the synthesized 
      speech playback rate, according to the full range
      offered by the speech synthesizer (unless a conformance
      claim states that the UA doesn't conform for speech output).

So, your point is well-taken, and I thought it would be
sufficient to say "except if you don't conform to these things"
in the Note. The Note is informational: it doesn't change what
the conformance requirements are.

Aaron wrote:

  "For each input technique/device that the user agent supports
   directly..."

Ian writes:
The reason we didn't say that is that the UA can support the mouse
for some functionalities, but the developer might not 
want to claim conformance for the the mouse 
(because the UA doesn't support it for all functionalities). Therefore,
you end up saying something like "For each supported input device
for which there is a conformance claim..." But that introduces
conformance language in the checkpoint, and none of the other
checkpoints
have such language.

I am not disputing that having a "gentler" first checkpoint would
be better, but I have been unable to come up with something
better than the current 1.1. And at least the form is consistent
with the other content type checkpoints.

I'll keep thinking about it, and I welcome other suggestions.

Aaron writes:

> > I would lean toward trying to make the checkpoints able to stand on their >own,

> > so that a short list of just the checkpoints is still useful. 


Ian writes:
Agreed.

Aaron writes:


> > I'm afraid >that people might skip some portions of the document, and completely miss the >meanings of things. I know that sounds bad, but usually the first read people >will give this is a quick skim. They might not realize that every sentence >could crucially change the meaning of some other sentence in a completely >different part of the document.


Ian writes:
Yes, that's a risk. Some checkpoints govern others. For instance,
1.1 covers everything, so we don't have to say in each checkpoint:

 "Allow configuration (through keyboard, voice, and pointing device)
..."

etc.


What do people on the list think? I think a new reader who visits the document, even if they read it thoroughly, will be confused by 1.1, and possibly come away thinking they have to support speech input.

I think consistency is important, but clarity is most important. If we're slightly redundant in our wording, that's okay, as long as people "get it".

Aaron