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: Peter Korn
Date: Tue, Feb 12 2008 9:55 AM

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