Thread Subject: Re: keyboard provision
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: Fri, Jun 08 2007 9:35 AM
- Return to this mailing list's archives
- View all messages in this thread
- Next message in thread: Andi Snow-Weaver: "Re: keyboard provision"
- Previous message in thread: Sean Hayes: "keyboard provision"
- Messages sorted by: Author | Thread | Date
Very good catch Sean.
I have been looking at the end of the sentence and didn't notice that morph.
Suggest we go with your second suggested repair.
"All functionality of the product operable through the user interface ...."
Gregg C Vanderheiden Ph.D.
> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf
> Of Sean Hayes
> Sent: Friday, June 08, 2007 9:43 AM
> To: TEITAC Web/Software Subcommittee
> Subject: [teitac-websoftware] keyboard provision
> 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
> mob +44 7977 455002
> office +44 117 9719730