Thread Subject: FW: Keyboard operability proposal (Forwardednote from Randy Marsden)

Return to this mailing list's archives

From: Mike Paciello
Date: Tue, May 15 2007 1:35 PM
Subject: FW: Keyboard operability proposal (Forwardednote from Randy Marsden)

Dave/Gregg/Andi -

Here is a repost of Randy Marsden's note, based on Dave's request.

- Mike


Mike Paciello
Cell: +1.603.566.7713

-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Randy
Marsden
Sent: Monday, May 14, 2007 2:25 AM
To: TEITAC Web/Software Subcommittee
Subject: Re: [teitac-websoftware] Keyboard operability proposal

Just a reminder here that being able to control an application from the
keyboard is important to some people with disabilities - in particular,
people who are blind. But many people with mobility impairments who can't
use a keyboard also need to be able to control the application via mouse
control only, or simple switch input.

Having keyboard equivalents for all of the application's functions is very
helpful, even in the second case where a keyboard is not being used, since
it gives AT software a "channel" through which it can issue commands to the
target application. In other words, special on-screen keyboards can execute
the command by simulating keyboard strokes.

But using keyboard equivalents in solutions related to mobility impairments
is really a work-around. Better would be for the target application to
expose its functionality via API's, and then allow AT to issue those
commands via other API's.

In light of all this, I strongly support Gregg's suggestion to put the
clarification from the WCAG, stating:

* Note: This does not forbid and should not discourage
providing mouse input or other input methods in addition to
keyboard operation.

Keyboard-based operation is where we're at today. But (I hope), the future
holds promise for AT to interoperate with IT in more sophisticated and
flexible ways.

-Randy
------------------------------------------------
Randy Marsden, P.Eng.
President & CEO, Madentec Limited
ATIA Global Policy Chair

780-450-8926 ext. 223
= EMAIL ADDRESS REMOVED =


> From: "David Poehlman" < = EMAIL ADDRESS REMOVED = >
> Organization: hottech
> Reply-To: TEITAC Web/Software Subcommittee
> < = EMAIL ADDRESS REMOVED = >
> Date: Sat, 12 May 2007 14:13:03 -0400
> To: "TEITAC Web/Software Subcommittee"
< = EMAIL ADDRESS REMOVED = >
> Subject: Re: [teitac-websoftware] Keyboard operability proposal
>
> Hi Greg,
>
> I am understanding correctly then and to this I would say we should not
> limit the future.
>
> ----- Original Message -----
> From: "Gregg Vanderheiden" < = EMAIL ADDRESS REMOVED = >
> To: "'TEITAC Web/Software Subcommittee'"
> < = EMAIL ADDRESS REMOVED = >
> Sent: Saturday, May 12, 2007 11:21 AM
> Subject: Re: [teitac-websoftware] Keyboard operability proposal
>
>
> Oh
>
> That means things like
> - freehand drawing
> - doing your signature
>
> Anything where it is important to TO THE UNDERLYING FUNCTION YOU ARE DOING
> to note the PATH that you took from the beginning to the end of the input.
>
>
> Basically - it just removes things that you can't do from your keyboard
> anyway. (at least in any reasonable manner. I guess you could move a
pixel
> at a time and sign your name or draw the outline of your dog (if you can
> draw) but I would hate to see what it would look like.)
>
>
> Gregg
> -- ------------------------------
> Gregg C Vanderheiden Ph.D.
>
>
>
>> -----Original Message-----
>> From: = EMAIL ADDRESS REMOVED =
>> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf
>> Of David Poehlman
>> Sent: Saturday, May 12, 2007 10:12 AM
>> To: TEITAC Web/Software Subcommittee
>> Subject: Re: [teitac-websoftware] Keyboard operability proposal
>>
>> Hi Greg,
>>
>> I think you are answering my question, but incase it's not
>> clear, here's the bit I either do not understand or have an
>> issue with if I do under stand it.
>> "except where the underlying function requires input that
>> depends on the path of the user's movement and not just the endpoints.
>> What does this limitation mean? Is it locking out anything
>> and if so what?
>>
>> Thanks!
>>
>>
>> ----- Original Message -----
>> From: "Gregg Vanderheiden" < = EMAIL ADDRESS REMOVED = >
>> To: "'TEITAC Web/Software Subcommittee'"
>> < = EMAIL ADDRESS REMOVED = >
>> Sent: Saturday, May 12, 2007 10:55 AM
>> Subject: Re: [teitac-websoftware] Keyboard operability proposal
>>
>>
>> Explain more.
>>
>> Requiring that everything be operable from a keyboard shouldn't limit
>> keyboard accessibility.
>>
>> Did you mean limit this TO keyboard accessibility? If so
>> then we should
>> be sure to include the sentence that is included in WCAG to
>> be sure this is
>> not misunderstood. That sentence is included in the
>> suggested text below
>> (scroll down). I'll include it here for convenience
>>
>>>>> * Note: This does not forbid and should not discourage
>>>>> providing mouse input or other input methods in addition to
>>>>> keyboard operation.
>>
>> If you meant something else - please go on. Maybe an example?
>>
>> Thanks
>>
>>
>> Gregg
>> -- ------------------------------
>> Gregg C Vanderheiden Ph.D.
>>
>>
>>
>>> -----Original Message-----
>>> From: = EMAIL ADDRESS REMOVED =
>>> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf
>>> Of David Poehlman
>>> Sent: Saturday, May 12, 2007 8:22 AM
>>> To: TEITAC Web/Software Subcommittee
>>> Subject: Re: [teitac-websoftware] Keyboard operability proposal
>>>
>>> I guess what I want to know is how does this limit keyboard
>>> accessability?
>>> it sounds like there is a limitation.
>>>
>>> ----- Original Message -----
>>> From: "Gregg Vanderheiden" < = EMAIL ADDRESS REMOVED = >
>>> To: "'TEITAC Web/Software Subcommittee'"
>>> < = EMAIL ADDRESS REMOVED = >
>>> Sent: Friday, May 11, 2007 3:51 PM
>>> Subject: Re: [teitac-websoftware] Keyboard operability proposal
>>>
>>>
>>> Don't understand the question David. But I'll take a shot at
>>> providing info
>>> that might help.
>>>
>>> The provision doesn't apply to people using a stylus. Just
>>> to software
>>> that accepts stylus input in that it would require that it
>> also allow
>>> keyboard input to things that can be done from a keyboard
>>> (e.g. entering
>>> text etc but not freehand drawing or things where path of
>>> input is important
>>> to underlying function).
>>>
>>> But it doesn't bar having stylus input or put any limitations
>>> on stylus
>>> input.
>>>
>>> Oh, and 'works well for both' meant both 'software' and 'web
>>> content'.
>>>
>>> Doest this help or address question?
>>>
>>>
>>> Gregg
>>> -- ------------------------------
>>> Gregg C Vanderheiden Ph.D.
>>>
>>>
>>>
>>>> -----Original Message-----
>>>> From: = EMAIL ADDRESS REMOVED =
>>>> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf
>>>> Of David Poehlman
>>>> Sent: Friday, May 11, 2007 7:54 AM
>>>> To: TEITAC Web/Software Subcommittee
>>>> Subject: Re: [teitac-websoftware] Keyboard operability proposal
>>>>
>>>> so if using a stylus I gotta be fast?
>>>>
>>>> ----- Original Message -----
>>>> From: "Gregg Vanderheiden" < = EMAIL ADDRESS REMOVED = >
>>>> To: "'TEITAC Web/Software Subcommittee'"
>>>> < = EMAIL ADDRESS REMOVED = >
>>>> Sent: Thursday, May 10, 2007 9:16 PM
>>>> Subject: Re: [teitac-websoftware] Keyboard operability proposal
>>>>
>>>>
>>>> That works well for both.
>>>>
>>>>
>>>> Gregg
>>>> -- ------------------------------
>>>> Gregg C Vanderheiden Ph.D.
>>>>
>>>>
>>>>
>>>>> -----Original Message-----
>>>>> From: = EMAIL ADDRESS REMOVED =
>>>>> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf
>>>>> Of Barrett, Don
>>>>> Sent: Thursday, May 10, 2007 3:14 PM
>>>>> To: TEITAC Web/Software Subcommittee
>>>>> Subject: Re: [teitac-websoftware] Keyboard operability proposal
>>>>>
>>>>> Couldn't we just substitute "user interface" for content:
>>>>>
>>>>> 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.
>>>>>
>>>>>
>>>>>
>>>>> Don Barrett
>>>>> Section 508 Coordinator
>>>>> U.S. Department of Education
>>>>> (202)-205-8245
>>>>> = EMAIL ADDRESS REMOVED =
>>>>>
>>>>> -----Original Message-----
>>>>> From: = EMAIL ADDRESS REMOVED =
>>>>> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf
>>>>> Of Andi Snow-Weaver
>>>>> Sent: Wednesday, May 09, 2007 3:06 PM
>>>>> To: = EMAIL ADDRESS REMOVED =
>>>>> Subject: [teitac-websoftware] Keyboard operability proposal
>>>>>
>>>>>
>>>>> Here is the latest keyboard operability provision from WCAG
>>>>> 2.0. We discussed this briefly in the subcommittee meeting
>>>>> today and there were no objections. Please review. If there
>>>>> are no objections on the mailing list, we will insert this
>>>>> into our 3rd draft submission as a recommended wording change
>>>>> for 1194.21 (a) and as a new provision for 1194.22.
>>>>>
>>>>> All functionality of the content 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.
>>>>>
>>>>> Andi
>>>>>
>>>>>

From: Mike Paciello
Date: Tue, May 15 2007 1:40 PM
Subject: FW: Keyboard operability proposal (from TomBrett)

Dave P -

I believe the following note from Tom Brett involving the revision was what
you agreed to...



Mike Paciello
Cell: +1.603.566.7713

-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of David
Poehlman
Sent: Saturday, May 12, 2007 11:14 AM
To: TEITAC Web/Software Subcommittee
Subject: Re: [teitac-websoftware] Keyboard operability proposal

This feels better to me.

Thanks tom!

----- Original Message -----
From: "Tom Brett" < = EMAIL ADDRESS REMOVED = >
To: "'TEITAC Web/Software Subcommittee'"
< = EMAIL ADDRESS REMOVED = >
Sent: Saturday, May 12, 2007 9:45 AM
Subject: Re: [teitac-websoftware] Keyboard operability proposal


What is really being talked about in this provision is the input device...

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

I would recommend that the provision be reworded:

The functionality of the user input device shall be operable through a
keyboard interface without requiring specific timings for individual
keystrokes. Where the underlying functionality of the input depends on the
path of the user's movement specific timings may be allowed but an
alternative method for this type of input must be provided.

Tom Brett


-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of David
Poehlman
Sent: Saturday, May 12, 2007 9:22 AM
To: TEITAC Web/Software Subcommittee
Subject: Re: [teitac-websoftware] Keyboard operability proposal

I guess what I want to know is how does this limit keyboard accessability?
it sounds like there is a limitation.

----- Original Message -----
From: "Gregg Vanderheiden" < = EMAIL ADDRESS REMOVED =
To: "'TEITAC Web/Software Subcommittee'"
< = EMAIL ADDRESS REMOVED =
Sent: Friday, May 11, 2007 3:51 PM
Subject: Re: [teitac-websoftware] Keyboard operability proposal


Don't understand the question David. But I'll take a shot at providing info
that might help.

The provision doesn't apply to people using a stylus. Just to software
that accepts stylus input in that it would require that it also allow
keyboard input to things that can be done from a keyboard (e.g. entering
text etc but not freehand drawing or things where path of input is important
to underlying function).

But it doesn't bar having stylus input or put any limitations on stylus
input.

Oh, and 'works well for both' meant both 'software' and 'web content'.

Doest this help or address question?


Gregg
-- ------------------------------
Gregg C Vanderheiden Ph.D.



-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf
Of David Poehlman
Sent: Friday, May 11, 2007 7:54 AM
To: TEITAC Web/Software Subcommittee
Subject: Re: [teitac-websoftware] Keyboard operability proposal

so if using a stylus I gotta be fast?

----- Original Message -----
From: "Gregg Vanderheiden" < = EMAIL ADDRESS REMOVED =
To: "'TEITAC Web/Software Subcommittee'"
< = EMAIL ADDRESS REMOVED =
Sent: Thursday, May 10, 2007 9:16 PM
Subject: Re: [teitac-websoftware] Keyboard operability proposal


That works well for both.


Gregg
-- ------------------------------
Gregg C Vanderheiden Ph.D.



-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf
Of Barrett, Don
Sent: Thursday, May 10, 2007 3:14 PM
To: TEITAC Web/Software Subcommittee
Subject: Re: [teitac-websoftware] Keyboard operability proposal

Couldn't we just substitute "user interface" for content:

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.



Don Barrett
Section 508 Coordinator
U.S. Department of Education
(202)-205-8245
= EMAIL ADDRESS REMOVED =

-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf
Of Andi Snow-Weaver
Sent: Wednesday, May 09, 2007 3:06 PM
To: = EMAIL ADDRESS REMOVED =
Subject: [teitac-websoftware] Keyboard operability proposal


Here is the latest keyboard operability provision from WCAG
2.0. We discussed this briefly in the subcommittee meeting
today and there were no objections. Please review. If there
are no objections on the mailing list, we will insert this
into our 3rd draft submission as a recommended wording change
for 1194.21 (a) and as a new provision for 1194.22.

All functionality of the content 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.

Andi

From: David Poehlman
Date: Tue, May 15 2007 1:45 PM
Subject: Re: FW: Keyboard operability proposal (fromTomBrett)

Yes, this is what comes closest in my mind to something workable.

We now have a lot of notes here so hopefully we won't leave anything out
that has been added since tom provided this.

Thanks!

----- Original Message -----
From: "Mike Paciello" < = EMAIL ADDRESS REMOVED = >
To: "'TEITAC Web/Software Subcommittee'"
< = EMAIL ADDRESS REMOVED = >
Sent: Tuesday, May 15, 2007 3:35 PM
Subject: [teitac-websoftware] FW: Keyboard operability proposal (from
TomBrett)


Dave P -

I believe the following note from Tom Brett involving the revision was what
you agreed to...



Mike Paciello
Cell: +1.603.566.7713

-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of David
Poehlman
Sent: Saturday, May 12, 2007 11:14 AM
To: TEITAC Web/Software Subcommittee
Subject: Re: [teitac-websoftware] Keyboard operability proposal

This feels better to me.

Thanks tom!

----- Original Message -----
From: "Tom Brett" < = EMAIL ADDRESS REMOVED = >
To: "'TEITAC Web/Software Subcommittee'"
< = EMAIL ADDRESS REMOVED = >
Sent: Saturday, May 12, 2007 9:45 AM
Subject: Re: [teitac-websoftware] Keyboard operability proposal


What is really being talked about in this provision is the input device...

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

I would recommend that the provision be reworded:

The functionality of the user input device shall be operable through a
keyboard interface without requiring specific timings for individual
keystrokes. Where the underlying functionality of the input depends on the
path of the user's movement specific timings may be allowed but an
alternative method for this type of input must be provided.

Tom Brett


-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of David
Poehlman
Sent: Saturday, May 12, 2007 9:22 AM
To: TEITAC Web/Software Subcommittee
Subject: Re: [teitac-websoftware] Keyboard operability proposal

I guess what I want to know is how does this limit keyboard accessability?
it sounds like there is a limitation.

----- Original Message -----
From: "Gregg Vanderheiden" < = EMAIL ADDRESS REMOVED =
To: "'TEITAC Web/Software Subcommittee'"
< = EMAIL ADDRESS REMOVED =
Sent: Friday, May 11, 2007 3:51 PM
Subject: Re: [teitac-websoftware] Keyboard operability proposal


Don't understand the question David. But I'll take a shot at providing info
that might help.

The provision doesn't apply to people using a stylus. Just to software
that accepts stylus input in that it would require that it also allow
keyboard input to things that can be done from a keyboard (e.g. entering
text etc but not freehand drawing or things where path of input is important
to underlying function).

But it doesn't bar having stylus input or put any limitations on stylus
input.

Oh, and 'works well for both' meant both 'software' and 'web content'.

Doest this help or address question?


Gregg
-- ------------------------------
Gregg C Vanderheiden Ph.D.



-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf
Of David Poehlman
Sent: Friday, May 11, 2007 7:54 AM
To: TEITAC Web/Software Subcommittee
Subject: Re: [teitac-websoftware] Keyboard operability proposal

so if using a stylus I gotta be fast?

----- Original Message -----
From: "Gregg Vanderheiden" < = EMAIL ADDRESS REMOVED =
To: "'TEITAC Web/Software Subcommittee'"
< = EMAIL ADDRESS REMOVED =
Sent: Thursday, May 10, 2007 9:16 PM
Subject: Re: [teitac-websoftware] Keyboard operability proposal


That works well for both.


Gregg
-- ------------------------------
Gregg C Vanderheiden Ph.D.



-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf
Of Barrett, Don
Sent: Thursday, May 10, 2007 3:14 PM
To: TEITAC Web/Software Subcommittee
Subject: Re: [teitac-websoftware] Keyboard operability proposal

Couldn't we just substitute "user interface" for content:

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.



Don Barrett
Section 508 Coordinator
U.S. Department of Education
(202)-205-8245
= EMAIL ADDRESS REMOVED =

-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf
Of Andi Snow-Weaver
Sent: Wednesday, May 09, 2007 3:06 PM
To: = EMAIL ADDRESS REMOVED =
Subject: [teitac-websoftware] Keyboard operability proposal


Here is the latest keyboard operability provision from WCAG
2.0. We discussed this briefly in the subcommittee meeting
today and there were no objections. Please review. If there
are no objections on the mailing list, we will insert this
into our 3rd draft submission as a recommended wording change
for 1194.21 (a) and as a new provision for 1194.22.

All functionality of the content 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.

Andi

From: David Poehlman
Date: Tue, May 15 2007 1:50 PM
Subject: Re: FW: Keyboard operability proposal(Forwardednote from Randy Marsden)

Indeed, the below is what I was looking for here from Randy but he seems to
indicate that greg has covered it.

Keyboard-based operation is where we're at today. But (I hope), the future
holds promise for AT to interoperate with IT in more sophisticated and
flexible ways.


----- Original Message -----
From: "Mike Paciello" < = EMAIL ADDRESS REMOVED = >
To: "'TEITAC Web/Software Subcommittee'"
< = EMAIL ADDRESS REMOVED = >
Sent: Tuesday, May 15, 2007 3:32 PM
Subject: [teitac-websoftware] FW: Keyboard operability proposal
(Forwardednote from Randy Marsden)


Dave/Gregg/Andi -

Here is a repost of Randy Marsden's note, based on Dave's request.

- Mike


Mike Paciello
Cell: +1.603.566.7713

-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Randy
Marsden
Sent: Monday, May 14, 2007 2:25 AM
To: TEITAC Web/Software Subcommittee
Subject: Re: [teitac-websoftware] Keyboard operability proposal

Just a reminder here that being able to control an application from the
keyboard is important to some people with disabilities - in particular,
people who are blind. But many people with mobility impairments who can't
use a keyboard also need to be able to control the application via mouse
control only, or simple switch input.

Having keyboard equivalents for all of the application's functions is very
helpful, even in the second case where a keyboard is not being used, since
it gives AT software a "channel" through which it can issue commands to the
target application. In other words, special on-screen keyboards can execute
the command by simulating keyboard strokes.

But using keyboard equivalents in solutions related to mobility impairments
is really a work-around. Better would be for the target application to
expose its functionality via API's, and then allow AT to issue those
commands via other API's.

In light of all this, I strongly support Gregg's suggestion to put the
clarification from the WCAG, stating:

* Note: This does not forbid and should not discourage
providing mouse input or other input methods in addition to
keyboard operation.

Keyboard-based operation is where we're at today. But (I hope), the future
holds promise for AT to interoperate with IT in more sophisticated and
flexible ways.

-Randy
------------------------------------------------
Randy Marsden, P.Eng.
President & CEO, Madentec Limited
ATIA Global Policy Chair

780-450-8926 ext. 223
= EMAIL ADDRESS REMOVED =


> From: "David Poehlman" < = EMAIL ADDRESS REMOVED = >
> Organization: hottech
> Reply-To: TEITAC Web/Software Subcommittee
> < = EMAIL ADDRESS REMOVED = >
> Date: Sat, 12 May 2007 14:13:03 -0400
> To: "TEITAC Web/Software Subcommittee"
< = EMAIL ADDRESS REMOVED = >
> Subject: Re: [teitac-websoftware] Keyboard operability proposal
>
> Hi Greg,
>
> I am understanding correctly then and to this I would say we should not
> limit the future.
>
> ----- Original Message -----
> From: "Gregg Vanderheiden" < = EMAIL ADDRESS REMOVED = >
> To: "'TEITAC Web/Software Subcommittee'"
> < = EMAIL ADDRESS REMOVED = >
> Sent: Saturday, May 12, 2007 11:21 AM
> Subject: Re: [teitac-websoftware] Keyboard operability proposal
>
>
> Oh
>
> That means things like
> - freehand drawing
> - doing your signature
>
> Anything where it is important to TO THE UNDERLYING FUNCTION YOU ARE DOING
> to note the PATH that you took from the beginning to the end of the input.
>
>
> Basically - it just removes things that you can't do from your keyboard
> anyway. (at least in any reasonable manner. I guess you could move a
pixel
> at a time and sign your name or draw the outline of your dog (if you can
> draw) but I would hate to see what it would look like.)
>
>
> Gregg
> -- ------------------------------
> Gregg C Vanderheiden Ph.D.
>
>
>
>> -----Original Message-----
>> From: = EMAIL ADDRESS REMOVED =
>> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf
>> Of David Poehlman
>> Sent: Saturday, May 12, 2007 10:12 AM
>> To: TEITAC Web/Software Subcommittee
>> Subject: Re: [teitac-websoftware] Keyboard operability proposal
>>
>> Hi Greg,
>>
>> I think you are answering my question, but incase it's not
>> clear, here's the bit I either do not understand or have an
>> issue with if I do under stand it.
>> "except where the underlying function requires input that
>> depends on the path of the user's movement and not just the endpoints.
>> What does this limitation mean? Is it locking out anything
>> and if so what?
>>
>> Thanks!
>>
>>
>> ----- Original Message -----
>> From: "Gregg Vanderheiden" < = EMAIL ADDRESS REMOVED = >
>> To: "'TEITAC Web/Software Subcommittee'"
>> < = EMAIL ADDRESS REMOVED = >
>> Sent: Saturday, May 12, 2007 10:55 AM
>> Subject: Re: [teitac-websoftware] Keyboard operability proposal
>>
>>
>> Explain more.
>>
>> Requiring that everything be operable from a keyboard shouldn't limit
>> keyboard accessibility.
>>
>> Did you mean limit this TO keyboard accessibility? If so
>> then we should
>> be sure to include the sentence that is included in WCAG to
>> be sure this is
>> not misunderstood. That sentence is included in the
>> suggested text below
>> (scroll down). I'll include it here for convenience
>>
>>>>> * Note: This does not forbid and should not discourage
>>>>> providing mouse input or other input methods in addition to
>>>>> keyboard operation.
>>
>> If you meant something else - please go on. Maybe an example?
>>
>> Thanks
>>
>>
>> Gregg
>> -- ------------------------------
>> Gregg C Vanderheiden Ph.D.
>>
>>
>>
>>> -----Original Message-----
>>> From: = EMAIL ADDRESS REMOVED =
>>> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf
>>> Of David Poehlman
>>> Sent: Saturday, May 12, 2007 8:22 AM
>>> To: TEITAC Web/Software Subcommittee
>>> Subject: Re: [teitac-websoftware] Keyboard operability proposal
>>>
>>> I guess what I want to know is how does this limit keyboard
>>> accessability?
>>> it sounds like there is a limitation.
>>>
>>> ----- Original Message -----
>>> From: "Gregg Vanderheiden" < = EMAIL ADDRESS REMOVED = >
>>> To: "'TEITAC Web/Software Subcommittee'"
>>> < = EMAIL ADDRESS REMOVED = >
>>> Sent: Friday, May 11, 2007 3:51 PM
>>> Subject: Re: [teitac-websoftware] Keyboard operability proposal
>>>
>>>
>>> Don't understand the question David. But I'll take a shot at
>>> providing info
>>> that might help.
>>>
>>> The provision doesn't apply to people using a stylus. Just
>>> to software
>>> that accepts stylus input in that it would require that it
>> also allow
>>> keyboard input to things that can be done from a keyboard
>>> (e.g. entering
>>> text etc but not freehand drawing or things where path of
>>> input is important
>>> to underlying function).
>>>
>>> But it doesn't bar having stylus input or put any limitations
>>> on stylus
>>> input.
>>>
>>> Oh, and 'works well for both' meant both 'software' and 'web
>>> content'.
>>>
>>> Doest this help or address question?
>>>
>>>
>>> Gregg
>>> -- ------------------------------
>>> Gregg C Vanderheiden Ph.D.
>>>
>>>
>>>
>>>> -----Original Message-----
>>>> From: = EMAIL ADDRESS REMOVED =
>>>> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf
>>>> Of David Poehlman
>>>> Sent: Friday, May 11, 2007 7:54 AM
>>>> To: TEITAC Web/Software Subcommittee
>>>> Subject: Re: [teitac-websoftware] Keyboard operability proposal
>>>>
>>>> so if using a stylus I gotta be fast?
>>>>
>>>> ----- Original Message -----
>>>> From: "Gregg Vanderheiden" < = EMAIL ADDRESS REMOVED = >
>>>> To: "'TEITAC Web/Software Subcommittee'"
>>>> < = EMAIL ADDRESS REMOVED = >
>>>> Sent: Thursday, May 10, 2007 9:16 PM
>>>> Subject: Re: [teitac-websoftware] Keyboard operability proposal
>>>>
>>>>
>>>> That works well for both.
>>>>
>>>>
>>>> Gregg
>>>> -- ------------------------------
>>>> Gregg C Vanderheiden Ph.D.
>>>>
>>>>
>>>>
>>>>> -----Original Message-----
>>>>> From: = EMAIL ADDRESS REMOVED =
>>>>> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf
>>>>> Of Barrett, Don
>>>>> Sent: Thursday, May 10, 2007 3:14 PM
>>>>> To: TEITAC Web/Software Subcommittee
>>>>> Subject: Re: [teitac-websoftware] Keyboard operability proposal
>>>>>
>>>>> Couldn't we just substitute "user interface" for content:
>>>>>
>>>>> 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.
>>>>>
>>>>>
>>>>>
>>>>> Don Barrett
>>>>> Section 508 Coordinator
>>>>> U.S. Department of Education
>>>>> (202)-205-8245
>>>>> = EMAIL ADDRESS REMOVED =
>>>>>
>>>>> -----Original Message-----
>>>>> From: = EMAIL ADDRESS REMOVED =
>>>>> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf
>>>>> Of Andi Snow-Weaver
>>>>> Sent: Wednesday, May 09, 2007 3:06 PM
>>>>> To: = EMAIL ADDRESS REMOVED =
>>>>> Subject: [teitac-websoftware] Keyboard operability proposal
>>>>>
>>>>>
>>>>> Here is the latest keyboard operability provision from WCAG
>>>>> 2.0. We discussed this briefly in the subcommittee meeting
>>>>> today and there were no objections. Please review. If there
>>>>> are no objections on the mailing list, we will insert this
>>>>> into our 3rd draft submission as a recommended wording change
>>>>> for 1194.21 (a) and as a new provision for 1194.22.
>>>>>
>>>>> All functionality of the content 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.
>>>>>
>>>>> Andi
>>>>>
>>>>>

From: Barrett, Don
Date: Tue, May 15 2007 1:55 PM
Subject: Re: FW: Keyboard operability proposal (fromTomBrett)

"an alternative method for this type of input must be provided."

That may be setting the bar way too high; if a path is required, and
the task cannot be done from the keyboard, what, besides the mouse,
could possibly serve as an alternate input? If we just mean the mouse,
then we are stating the obvious.

From: Gregg Vanderheiden
Date: Tue, May 15 2007 2:00 PM
Subject: Re: FW: Keyboard operability proposal(fromTomBrett)

Don't understand "an alternative method for this type of input must be
provided."


Regarding your other question. - cameras are not being used for gesture
input and we will see much more of that in the future. Also accelerometers
on hand held devices.


Gregg
-- ------------------------------
Gregg C Vanderheiden Ph.D.



> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf
> Of Barrett, Don
> Sent: Tuesday, May 15, 2007 2:48 PM
> To: = EMAIL ADDRESS REMOVED = ; TEITAC Web/Software Subcommittee
> Subject: Re: [teitac-websoftware] FW: Keyboard operability
> proposal (fromTomBrett)
>
> "an alternative method for this type of input must be provided."
>
> That may be setting the bar way too high; if a path is
> required, and the task cannot be done from the keyboard,
> what, besides the mouse, could possibly serve as an alternate
> input? If we just mean the mouse, then we are stating the obvious.
>

From: Tom Brett
Date: Tue, May 15 2007 2:15 PM
Subject: Re: FW: Keyboard operability proposal(fromTomBrett)

I would envision blow tubes, head mouse, touchpad, cameras, speech to text
would be alternative means of providing input.

Tom Brett


-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Barrett,
Don
Sent: Tuesday, May 15, 2007 3:48 PM
To: = EMAIL ADDRESS REMOVED = ; TEITAC Web/Software Subcommittee
Subject: Re: [teitac-websoftware] FW: Keyboard operability proposal
(fromTomBrett)

"an alternative method for this type of input must be provided."

That may be setting the bar way too high; if a path is required, and
the task cannot be done from the keyboard, what, besides the mouse,
could possibly serve as an alternate input? If we just mean the mouse,
then we are stating the obvious.

From: David Poehlman
Date: Tue, May 15 2007 2:16 PM
Subject: Re: FW: Keyboard operability proposal(fromTomBrett)

I think this means that there needs to be another way to achieve the same
thing throuh the keyboard or some future device.

----- Original Message -----
From: "Barrett, Don" < = EMAIL ADDRESS REMOVED = >
To: < = EMAIL ADDRESS REMOVED = >; "TEITAC Web/Software Subcommittee"
< = EMAIL ADDRESS REMOVED = >
Sent: Tuesday, May 15, 2007 3:48 PM
Subject: Re: [teitac-websoftware] FW: Keyboard operability proposal
(fromTomBrett)


"an alternative method for this type of input must be provided."

That may be setting the bar way too high; if a path is required, and
the task cannot be done from the keyboard, what, besides the mouse,
could possibly serve as an alternate input? If we just mean the mouse,
then we are stating the obvious.