Thread Subject: FW: Keyboard operability proposal (from TomBrett)

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: Mike Paciello
Date: Tue, May 15 2007 1:40 PM


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


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