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: Andi Snow-Weaver
Date: Tue, Jul 10 2007 8:20 AM
- Return to this mailing list's archives
- View all messages in this thread
- Next message in thread: None
- Previous message in thread: Gregg Vanderheiden: "Re: keyboard provision"
- Messages sorted by: Author | Thread | Date
I think the change happened in one of the meetings. The original wording
was "functionality of the content" and we came up with "functionality of
the user interface" in the meeting.
I think the edit below is exactly what we really meant. Since there have
been no objections raised to this proposal, I will ask the EWG to make the
Apologies for missing this post prior to submitting our input for the June
< = EMAIL ADDRESS REMOVED = To
u> "'TEITAC Web/Software
Sent by: Subcommittee'"
teitac-websoftwar < = EMAIL ADDRESS REMOVED =
= EMAIL ADDRESS REMOVED = >
06/08/2007 10:33 Re: [teitac-websoftware] keyboard
Please respond to
= EMAIL ADDRESS REMOVED =
Very good catch Sean.
I have been looking at the end of the sentence and didn't notice that
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
- Next message in Thread: None
- Previous message in Thread: Gregg Vanderheiden: "Re: keyboard provision"