Thread Subject: Keyboard proposal
Note
This archival content is maintained by WebAIM and NCDAE on behalf of TEITAC and the U.S. Access Board . Additional details on the updates to section 508 and section 255 can be found at the Access Board web site.
From: Gregg Vanderheiden
Date: Wed, Sep 12 2007 9:35 AM
- Return to this mailing list's archives
- View all messages in this thread
- Next message in thread: David Poehlman: "Re: Keyboard proposal"
- Previous message in thread: None
- Messages sorted by: Author | Thread | Date
On the keyboard provision
We need to limit it to devices that have a Keyboard or keyboard interface.
We need to allow that some functions may be from other mechanical buttons.
Needs to say Keyboard or keyboard interface so that we don't require
addition of an interface.
How about
Where products have a keyboard or keyboard interface , all functionality of
the product operable through the user interface must be operable through the
keyboard or keyboard interface or other mechanical buttons without requiring
specific timings for individual keystrokes. The only exception is where the
underlying function requires input that depends on the path of the user's
movement and not just the endpoints.
NOTE: A software product that accepts text input would have a "keyboard
interface".
This puts the condition up front so it is easy to see (and discard provision
if not true)
Meets the needs stated above
Gregg
------------------------
Gregg C Vanderheiden Ph.D.
Professor - Depts of Ind. Engr. & BioMed Engr.
Director - Trace R & D Center
University of Wisconsin-Madison
< <http://trace.wisc.edu/> http://trace.wisc.edu/> FAX 608/262-8848
DSS Player at http://tinyurl.com/dho6b
If Attachement is a mail.dat try <http://www.kopf.com.br/winmail/>
http://www.kopf.com.br/winmail/
<http://trace.wisc.edu:8080/mailman/listinfo/>
- Next message in Thread: David Poehlman: "Re: Keyboard proposal"
- Previous message in Thread: None
WebAIM is an initiative of:
