W3C home > Mailing lists > Public > w3c-wai-gl@w3.org > January to March 2007

RE: Not described in words

From: Bailey, Bruce <Bruce.Bailey@ed.gov>
Date: Tue, 13 Mar 2007 10:04:37 -0400
Message-ID: <CCDBDCBFA650F74AA88830D4BACDBAB5130FA84D@wdcrobe2m02.ed.gov>
To: "Gregg Vanderheiden" <gv@trace.wisc.edu>
Cc: <w3c-wai-gl@w3.org>

> Thanks for banging on this.

I am sorry I didn't think about it harder sooner.  Until relatively recently, I had no problems with "time-dependent analog input".

> We need to check it out.


> Couple things
> 1) draw a stick figure is not the command you give the 
> computer...
> 2) ditto for 'hit the ball'.  That is the task of the user, 
> not a command anywhere in the program.

Okay, how about:

1) Use the pencil tool turns any white pixel you like to black.
2) Move the on-screen paddle left and right.

I don't think "described in a simple sentence" has much at all to do with the conundrum -- hence the subject line I picked for this particular thread!

> RE textually discernable:
> If 'described in a simple sentence" fails, how does textually 
> discernable address the problem since it is unbounded text 
> and sentences?
> Am I missing something?

To me, discern textually means something quite different than describing in words.  It is about something being recognizable *as* text.  It is about characters truly representing a function.  A slider might have a value between zero and 100 percent, so numbers can work too.

> PS  'textually discernable' fails our "use simple language 
> when you can" dictum and I think it is also hard to translate.

I can appreciate the translation problem -- especially since the concept is difficult to convey in English!

Loretta wrote earlier:
<q>Bruce, we would need to think this through more carefully, since
removing the reference to timing means that keyboard operations that
depend upon the amount of time that a key is held down would be
permitted, and we know that this introduces accessibility problems for
some people.</q>

@@without requiring specific timings for individual keystrokes@@

This is the third time I am asking:  Can someone please provide some examples of why this is necessary to stipulate?  The ones that come to my mind are all gaming related.  Or maybe an application that ignores/defeats Sticky-Keys.  Is this SC really trying to address that potential problem?

[I also have a question about what we mean by *competitive* gaming in the exception example for 2.2.1 (timing, not keyboard-accessibility), but I think I will wait on that one.]

I am now wondering if the problem might be with interpreting "time-dependant" term too strictly.

Do we really mean a softer concept like "where timing is a factor" or "time influenced"?

That is, input *is* dependent on timing, even if the task does not have time limits associated with it.  Might it be the case that the confusion is merely that our illustrative examples are too exotic?  Can we list "Paint" and "Pong" along "watercolor program" and "real-time helicopter flight simulator"?
Received on Tuesday, 13 March 2007 14:04:49 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 16 January 2018 15:34:02 UTC