- From: Slatin, John M <john_slatin@austin.utexas.edu>
- Date: Mon, 19 Mar 2007 10:46:00 -0500
- To: "Bailey, Bruce" <Bruce.Bailey@ed.gov>, "Sean Hayes" <Sean.Hayes@microsoft.com>, "Gregg Vanderheiden" <gv@trace.wisc.edu>
- Cc: <w3c-wai-gl@w3.org>
<current> All functionality of the content is operable through a keyboard interface without requiring specific timings for individual keystrokes, except where the underlying task requires time-dependent analog input. </current> If (as Bruce notes below) the problem is about how long an individual keystroke lasts, how about something like this? <proposed> All functionality of the content is operable through a keyboard interface without requiring a specific duration for any individual keystroke, except where the underlying task requires time-dependent analog input. </proposed> John "Good design is accessible design." Dr. John M. Slatin, Director Accessibility Institute University of Texas at Austin FAC 248C 1 University Station G9600 Austin, TX 78712 ph 512-495-4288, fax 512-495-4524 email john_slatin@austin.utexas.edu Web http://www.utexas.edu/research/accessibility -----Original Message----- From: w3c-wai-gl-request@w3.org [mailto:w3c-wai-gl-request@w3.org] On Behalf Of Bailey, Bruce Sent: Monday, March 19, 2007 7:39 AM To: Sean Hayes; Gregg Vanderheiden Cc: w3c-wai-gl@w3.org Subject: RE: Not described in words <current> All functionality of the content is operable through a keyboard interface without requiring specific timings for individual keystrokes, except where the underlying task requires time-dependent analog input. </current> > 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". It is subtle, but from my recent conversation with Gregg I understand that "specific timing for individual keystrokes" is about *how* the keys are pressed and not *when* the keys are pressed. I used Frogger to illustrate the difference, but Morse code could work as an example if it uses two keys (one for each tone). > SH: 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]" I think this is good, but it is almost recursive in how it excludes a built-in Mouse-Keys-Like feature. [And yes, I do believe that such a possibility must be considered. I have had more than one developer cite Mouse Keys (at the OS level) as satisfying 508 1194.21(a)!] I also think the current wording is okay, but ambiguous on the timing aspect, and I am at a loss to provide a suggestion for improving it. Is the How to Meet the place to explain that games that use timing as play element do not automatically fail 2.1.1? I would like to see the examples for illustrating "time-dependant analog input" to be less exotic. (Maybe Paint and Mine Sweeper, instead of Water Coloring and Helicopter Simulator?) Of course, I still feel "not textually discernable" is easier to parse than "time-dependant analog input" so perhaps my judgment is suspect...
Received on Monday, 19 March 2007 15:46:13 UTC