Thread Subject: Re: keyboard provision

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

Apologies for missing this post prior to submitting our input for the June
30th deadline.

Andi




Gregg
Vanderheiden
< = EMAIL ADDRESS REMOVED = To
u> "'TEITAC Web/Software
Sent by: Subcommittee'"
teitac-websoftwar < = EMAIL ADDRESS REMOVED =
= EMAIL ADDRESS REMOVED = >
itac.org cc

Subject
06/08/2007 10:33 Re: [teitac-websoftware] keyboard
AM provision


Please respond to
TEITAC
Web/Software
Subcommittee
<teitac-websoftwa
= EMAIL ADDRESS REMOVED =
g>






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
-- ------------------------------
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
> Microsoft
> Phone:
> mob +44 7977 455002
> office +44 117 9719730
>
>

• Next message in Thread: None
• Previous message in Thread: Gregg Vanderheiden: "Re: keyboard provision"