RE: Not described in words

Not sure what your intent is here but a couple of points:

GV "The first is the requirement that keyboard input not have timing requirements on it.  That is you can require the person to tap out Morse code on a key and call that keyboard access".

You can't use a single key to produce Morse code without timing, otherwise how would you distinguish between long and short pulses?

In fact Morse is quite a good example of where an input may be time dependant, but not analog (although actually true Morse code is analog and each operator develops a 'signature' which is easily recognised by other operators).

GV "The second part has to do with 'analog time dependent' input.  If analog
input is required then one could just enter digits from the keyboard to
represent each analog position....
So the time factor on "time-dependent analog" I needed."

I don't think this is a serious argument; by the same token I could type in the times at which the analog inputs should be sampled. I don't think anyone would seriously call it an effective alternative to type thousands, hundreds of thousands or even millions of analog numbers to process a digital photograph.

Both time dependant and non-time dependant analog inputs need to be covered. What I am looking for is a testable way to state that the keyboard alternative is an effective replacement.

Maybe something like:

"All functionality is operable through a keyboard interface, except where the command or outcome cannot be reproduced by [a small set of strokes]"

[a small set of strokes] means on the order of 10, where strokes are defined as the separate key presses required to initiate the function (ignoring presses required to included named variables such as filenames, but including key modifiers such as ctrl)


-----Original Message-----
From: w3c-wai-gl-request@w3.org [mailto:w3c-wai-gl-request@w3.org] On Behalf Of Gregg Vanderheiden
Sent: 12 March 2007 03:33
To: w3c-wai-gl@w3.org
Subject: FW: Not described in words



Oops my last message was sent before completed.    Let me try again.

We DO need to work on this one (2.1.1) so let me walk this to see if it
helps identify where we need to do something.  I don't have the answer right
now.  But I may have a proposal.  Not sure.

NOTE: I am talking about two different provisions below that differ by one
number.   2.2.1 is our provision about time-limits.   2.1.1 is about
keyboard control.  I will put a (time-limits) or (Keyboard access) after
each to make it easier to keep them straight.    Oh, 2.2.4 is also about
time limits.


2.2.1 (time-limits) DOES allow games and other things that have time limits
that are necessary (like for competition). Otherwise 2.2.1 (time-limits)says
they can't have time limits and still be called accessible.
NOTE: 2.2.4 (time-limits at L3) goes further and says "no time limits other
than media and real-time (which have natural limits set by the nature of
reality).


Time appears in 2.1.1 (Keyboard access) in two places.

The first is the requirement that keyboard input not have timing
requirements on it.  That is you can require the person to tap out Morse
code on a key and call that keyboard access.  Keyboard access must be free
of time constraints to call it keyboard access.  This is not the same as
time constraints of the process. This is the part that probably needs to be
looked at to be sure we don't accidentally imply limitations stricter than
2.2.1 (time-limits) for process.

The second part has to do with 'analog time dependent' input.  If analog
input is required then one could just enter digits from the keyboard to
represent each analog position.  Analog motion ( a path) could be specified
as a sequence of these as long as there are no time dependencies. Hence any
analog input requirements could be met by typing on a keyboard.  Even a
watercolor painting could be if done on a computer.  But where time is a
factor, such as controlling a real paint brush (where water soaks in) or a
plane, then time is a factor.  So a clause saying that keyboard input is not
required in those situations is necessary or else we would have forbidden
time constraints for real-time events in 2.1.1 (keyboard access) when we
don't in 2.2.1 (time limits).

So the time factor on "time-dependent analog" I needed.

However,  "time-dependent analog" input would still require that the
watercolor painting program be keyboard operable which we don't want.  It is
theoretically possible to do that from the keyboard but not practical and
there is no need to require it.

So that leaves us with some language that doesn't subvert 2.2.1 (time
limits) but still is not good enough to do what we want with 2.1.1 (keyboard
access).

The "command or outcome can be described in words" almost works except that
you can also describe the water color painting strokes with enough words.

What we want is "where the command or outcome can be described in xxx
words".  But xxxx gets to be a problem.   (e.g what number to use for xxx
and where did it come from.)

Maybe "described in a simple sentence"  ?

This goes back to the approach first conceived by Doug Wakefield and Judy
Dixon,  with the 'simple sentence' modifier.    There were people who had
trouble with this because they thought it implied that they needed to have
natural language control added.  Hence the attempts to find other
definitions.   But our other attempts have failed to draw the line where we
would like.  The DO separate things that are keyboard controllable from
those that are not -- but they unfortunately include things that are
keyboard controllable with an extremely large number of keystrokes.   We are
looking for things that are reasonably controllable from the keyboard.  The
best I can see right now is

" Except where the command or outcome cannot be described in a simple
sentence, all functionality is operable through a keyboard interface without
requiring specific timings for individual keystrokes."

Hmmmm.



Gregg
 -- ------------------------------
Gregg C Vanderheiden Ph.D.


-----Original Message-----
From: w3c-wai-gl-request@w3.org [mailto:w3c-wai-gl-request@w3.org] On Behalf
Of Gregg Vanderheiden
Sent: Saturday, March 10, 2007 7:18 PM
To: 'Bailey, Bruce'; 'Slatin, John M'
Cc: 'WCAG'
Subject: RE: Not described in words


Well I think we are getting things confused a bit.

2.2 does allow games and other things that have time limits that are
necessary for like competition. Else they can't have time limits and still
be called accessible.


The time 2.1 is not about game time requirements so much as a LIMITATION on
what has to be keyboard accessible.    Competitive games

Gregg
 -- ------------------------------
Gregg C Vanderheiden Ph.D.



> -----Original Message-----
> From: w3c-wai-gl-request@w3.org
> [mailto:w3c-wai-gl-request@w3.org] On Behalf Of Bailey, Bruce
> Sent: Thursday, March 08, 2007 12:40 PM
> To: Slatin, John M
> Cc: WCAG
> Subject: RE: Not described in words
>
>
> > About putting all the timing issues under 2.2
>
> I am not sure 2.2 needs additional timing related SC.  But let me
> repeat my other concern with the current wording of SC
> 2.1.1 (and 2.1.2):
>
> <q>All functionality of the content is operable in a
> non-time-dependent manner through a keyboard interface</q>
>
> >> seems to exclude *all* keyboard accessible games that have
> timing as
> >> [a] play element
>
> It is possible for games like Pong or Frogger to satisfy SC 2.2.1 if:
> <q>the user is allowed to adjust the time-out over a wide range that
> is at least ten times the length of the default setting</q>
>
> But this does not help with SC 2.1.1 (and 2.1.2) and
> *recreational* games because, even if all functionality is operable
> via a keyboard interface, the functionality is *not* operable in a
> "non-time-dependent manner".
>
>

Received on Monday, 19 March 2007 11:27:46 UTC