Thread Subject: Re: Keyboard operability proposal

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: Randy Marsden
Date: Mon, May 14 2007 12:30 AM

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

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