Thread Subject: keyboard provision

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: Sean Hayes
Date: Fri, Jun 08 2007 8:45 AM

The wording in the May report for keyboard access seems to have gone awry:

"All functionality of the user interface is operable through a keyboard interface without requiring specific timings for individual keystrokes, except where the underlying function requires input that depends on the path of the user's movement and not just the endpoints.
Note: This exception relates to the underlying function, not the input technique. For example, if using handwriting to enter text, the input technique (handwriting) requires path dependent input but the underlying function (text input) does not.
Note: This does not forbid and should not discourage providing mouse input or other input methods in addition to keyboard operation."


Not sure when it happened, but something has changed here. It should not be "All functionality of the user interface" but " All functionality of the product " or possibly "All functionality of the product operable through the user interface"

The function of the user interface is to provide access to the functions of the product. The idea of the path language was to provide an exception where the product function required a path, not where the interface to the product function requires it.

As it stands the exception would apply to handwriting recognition for inputting text, which Gregg clearly articulated was not an exception.

Sean Hayes
Standards and Policy Team
Corporate Accessibility Group
Microsoft
Phone:
mob +44 7977 455002
office +44 117 9719730

WebAIM is an initiative of:
Center for Persons with Disabilities (CPD) Utah State University