Thread Subject: Re: Proposals regarding keyboard shortcuts

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: Gregg Vanderheiden
Date: Tue, Feb 12 2008 10:50 AM

Yes - I'm not sure there are any SHORTCUTS on a remote control are there?
(pressing two buttons simultaneously? - since that is already barred? Or
actually only barred as ONLY way to do something)




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



> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf
> Of Peter Korn
> Sent: Tuesday, February 12, 2008 10:48 AM
> To: Schomburg, Paul
> Cc: TEITAC Committee
> Subject: Re: [teitac-committee] Proposals regarding keyboard shortcuts
>
> Hi Paul, Andrew,
>
> The concept we were trying to capture is that for those
> keyboard shortcuts that are associated with user interface
> elements directly (e.g. ENTER for the default button in a
> dialog box, ALT-P for the Print button in a dialog box), such
> shortcuts must be visually discernible (e.g. the thick border
> around the default button, the underline under the letter P
> in Print), and the information about those shortcuts must be
> available programmatically via the Accessibility Services (or
> some other means - see provision 3-U) to AT.
>
> If we have decided for whatever reason that 3-U doesn't apply
> to a class of device (e.g. a TV or phone), then I think
> likewise this portion of the draft provision should likewise
> not apply. Note that on many phones, there are "softkeys"
> much like function keys, and what they activate is indicated
> by the item being directly above the softkey on the LCD
> screen of the phone, thereby satisfying the visually
> discernible requirement. Likewise on a TV, there are
> oftentimes commands in the TV GUI that are directly mapped to
> the TV remote buttons (e.g. on my Dish DVR device, there are
> always less than 10 options/buttons on a screen, and the
> numbers 0-9 are labeling each one).
>
> This is distinct from keyboard commands that are application
> or system wide and not bound to any specific user interface
> element (e.g. ALT-TAB to switch between applications).
> Perhaps the term "keyboard convention"
> is poor for this, but that is the concept we are trying to
> get to. We don't know how to visually indicate such things,
> nor how to convey them to AT yet via a set of Accessibility
> Services, so we shouldn't write draft regulation that
> requires the same.
>
>
> Regards,
>
> Peter Korn
> Accessibility Architect,
> Sun Microsystems, Inc.
>
> > Judy, Peter: The definition for Keyboard includes phone
> keypads and
> > TV remote controls. Would the requirement for keyboard
> shortcuts to
> > be "available programmatically to AT" mean that every TV and every
> > phone would have to provide an open programmable operating system
> > (like Windows or Java)?
> >
> > Thanks, Paul
> >
> > -----Original Message-----
> > From: = EMAIL ADDRESS REMOVED =
> > [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Judy
> > Brewer
> > Sent: Tuesday, February 12, 2008 12:11 AM
> > To: TEITAC Committee; Peter Korn
> > Subject: [teitac-committee] Proposals regarding keyboard shortcuts
> >
> > Following is a two-part proposal to address documentation and
> > visibility of keyboard shortcuts, based on discussion between Peter
> > Korn and myself over the past several weeks.
> >
> > We reached rough agreement on the first part of the
> proposal, but had
> > not completed addressing each other's concerns about the
> alternatives
> > in the second part of the proposal.
> >
> > We're forwarding this at the Chairs' request so as to be
> available for
> > discussion on the list and during the related agenda item
> for the Feb
> > 12 TEITAC teleconference.
> >
> > Regards,
> >
> > - Judy
> >
> > 1. Draft new provision to go in section 3 "User Interface and
> > Electronic Content Provisions", with suggested placement following
> > current 3-S, "Keyboard Operation":
> > ------------------------------------
> > Visual Indication of Keyboard Shortcuts:
> > All keyboard commands associated directly with user interface
> > controls should be visible within the visual user interface in at
> > least one mode, and available programmatically to AT.
> > Note: This includes commands such as those used to
> activate a menu
> > or button, but not non-visible conventions such as ALT-TAB or
> > Ctrl-Arrow.
> >
> > Rationale for proposing this addition: We added the visibility
> > clause noting that this is a specific problem for several
> classes of
> > users. Note that there are a variety of ways of achieving "at least
> > one mode," including a global system setting, pressing a key to
> > highlight the shortcuts, etc. We recommend placing this
> new clause,
> > and the programmatic availability to AT, here rather than in
> > documentation because it is about what the product must do,
> not what
> > the documentation about the product must do.
> >
> > --------------------
> >
> > 2. Draft new 1.1-B (two alternative versions):
> > ---------version (1)------------
> > Information about keyboard shortcuts - including
> keyboard commands
> > and keyboard navigation mechanisms - must be documented in
> at least
> > one of the following places:
> > a. integrated help system / context-sensitive help
> > b. centralized on-line documentation
> > c. printed user documentation
> > When the documentation lists specific pointing-device
> based actions
> > that are unique to the product or content, the keyboard
> commands must
> > also be listed. Wherever commercially reasonable and logically
> > practicable, all keyboard shortcuts, commands, and
> navigation should
> > be documented in at least one centralized location.
> >
> > ----------version (2)----------------
> > Information about keyboard shortcuts - including
> available keyboard
> > commands and keyboard navigation mechanisms - must be listed in
> > centrally located user documentation, and available in
> > context-sensitive help.
> >
> > ###
> >
> > --
> > Judy Brewer +1.617.258.9741 http://www.w3.org/WAI
> > Director, Web Accessibility Initiative (WAI), World Wide Web
> > Consortium
> > (W3C)
> > MIT/CSAIL Building 32-G526
> > 32 Vassar Street
> > Cambridge, MA, 02139, USA
> >
> >
> >

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