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