Re: Contradictory/confusing requirements wording

There is substantive reasoning for emphasizing that a parallel
approach to the document is best and justifyiable.  A table of
contents is provided and on the web, it is linked such that it would
be fairly simple to jump between portions of the document.  The
abstract is clear in that there is a conformance model and each
checkpoint has a priority assigned to it which is listed in the
checkpoint.  We have a document glossary and many other tools within
the document that substantiate and embellish the document.  Stating
clearly that certain things must be taken into account in addition to
the checkpoints even going so far as putting the techniques in that
list of things might help drive home this point.

----- Original Message -----
From: "Hansen, Eric" <ehansen@ets.org>
To: <aaronl@netscape.com>; <w3c-wai-ua@w3.org>
Sent: Saturday, March 10, 2001 4:23 PM
Subject: RE: Contradictory/confusing requirements wording


Maybe there is a way to have a summary of the that key conformance bit
early
(and perhaps even repeated) in order to address the issue that Aaron
has
pointed out. Maybe even go through an example, something like pieces
of the
conversation that Ian and Aaron have had. I am not excited about bring
the
whole conformance section up to the beginning of the document but
perhaps
some explanation could be put early.

-----Original Message-----
From: aaronl@netscape.com [mailto:aaronl@netscape.com]
Sent: Friday, March 09, 2001 7:30 PM
To: w3c-wai-ua@w3.org
Subject: 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 cha!

nge 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.

A!

aron 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

Received on Saturday, 10 March 2001 16:43:10 UTC