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 11:15 AM


Hi Gregg, Judy,

One more suggestion... The Note text, taken from illustrative comments
between Judy and I, makes the assumption that the read is familiar with
keyboard commands common on the Windows and UNIX/GNOME platforms. The
ALT-TAB and Ctrl-Arrow conventions are not universal. While it is an
advisory/informative comment, I am nonetheless uncomfortable with the
implied assumption that the user is using a specific desktop system.

I would prefer us to either make the assumption explicit, or to find
some other way of stating it. Below is a suggested update to the Note:

"Note: This includes commands such as those used to active a menu item
or button (e.g. the "S" of a "Save File" menu item), but does not
include commands that are system-wide or common conventions for using an
item (e.g. a command to switch windows such as ALT-TAB, or a command to
advance the caret in text such as Ctrl-Arrow)."


Thanks,

Peter Korn
Accessibility Architect,
Sun Microsystems, Inc.


> OK that makes it
>
>
>
> Visual Indication of Keyboard Shortcuts:
>
> All keyboard commands associated directly with user interface
>
> controls MUST be visible within ANY DISPLAY BASED user interface in at
>
> least one mode, and available programmatically to AT ON PRODUCTS THAT
> SUPPORT AT INTEROPERABILITY.
>
> 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.
>
>
>
>
>
>
> Gregg
> -- ------------------------------
> Gregg C Vanderheiden Ph.D.
>
>
>
>
>
> ------------------------------------------------------------------------
>
> *From:* = EMAIL ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS REMOVED = ] *On Behalf Of
> *Schomburg, Paul
> *Sent:* Tuesday, February 12, 2008 11:01 AM
> *To:* TEITAC Committee
> *Cc:* Schomburg, Paul
> *Subject:* Re: [teitac-committee] Proposals regarding keyboard
> shortcuts
>
> Thanks Greg. I also think you need to exclude products without a
> visual interface.
>
>
>
> Thanks, Paul
>
>
>
> ------------------------------------------------------------------------
>
> *From:* = EMAIL ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS REMOVED = ] *On Behalf Of
> *Gregg Vanderheiden
> *Sent:* Tuesday, February 12, 2008 11:49 AM
> *To:* 'TEITAC Committee'; 'Peter Korn'
> *Subject:* Re: [teitac-committee] Proposals regarding keyboard
> shortcuts
>
>
>
> Interesting.
>
>
>
> 1) Can we fix that with "on products that support AT
> interoperability".
>
> (I included interoperability since a headstick, or prosthetic is
> AT". )
>
>
>
> 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 ON PRODUCTS
> THAT SUPPORT AT INTEROPERABILITY.
>
> 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.
>
>
>
>
>
> 2) Also this should be MUST right? If it is SHOULD then it goes
> down with advisory items.
>
>
>
>
>
>
>
>
>
> 3) I note that there is a MUST and a SHOULD in the second
> provision too. Is that intentional? The SHOULD should go into a
> note if it is a SHOULD.
>
>
>
>
>
>
>
> Gregg
>
> -- ------------------------------
>
> Gregg C Vanderheiden Ph.D.
>
>
>
>
>
> > -----Original Message-----
>
> > From: = EMAIL ADDRESS REMOVED =
> [mailto:teitac-committee-
>
> > = EMAIL ADDRESS REMOVED = ] On Behalf Of Schomburg, Paul
>
> > Sent: Tuesday, February 12, 2008 10:18 AM
>
> > To: TEITAC Committee; Peter Korn
>
> > Cc: Schomburg, Paul
>
> > Subject: Re: [teitac-committee] Proposals regarding keyboard
> shortcuts
>
> >
>
> > 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