DRAFT position on hotkey requirements

<note class="concurrence process">

The draft position below has gained a rough consensus in the PF
Working Group. We are seeking feedback from the guidelines
groups (User Agent, Web Content, Authoring Tools)
before representing this as a WAI position.

Here's a copy of the draft as it stands for consideration by the
User Agent Working Group.

Thank you for your attention to this.

Al

</note>

<position class="DRAFT senseOfTheWAI">

Topic:

Features in XHTML 2.0 and future Web formats in the area of
functionality around the 'accesskey' attribute in HTML 4.

Requirements:

1. The association of specific user input events the activation of
accelerators must be configurable on the client side, under user
control.

2. This ability to control, including alter, the binding of UI events
to accelerators must be available through APIs so that assistive
technology can exercise this control.

3. Given that these two are satisfied, it is not appropriate to limit
accelerators to those defined on the client side by the OS, browser,
AT and user. The capability should be maintained for there to be
author-defined nominations of mnemonic hotkeys [or other
author-identified default trigger-event bindings] for accelerators
specific to the current context in a web application.

Rationale:

1. UAAG Guideline 1
http://www.w3.org/TR/UAAG10/guidelines.html#gl-device-independence

Note:  The language about user review and adjustment of input
event bindings that is found in an informative passage in the XForms
recommendation at

<quote
cite=" http://www.w3.org/TR/xforms/slice8.html#id2625797 ">
The user agent must provide a means of identifying the accesskeys
that can be used in a presentation. This may be accomplished in
different ways by different implementations, for example through
direct interaction with the application or via the user's
guide. The accesskey requested by the author might not be made
available by the player (for example it may not exist on the
device used, or it may be used by the player itself). Therefore
the user agent should make the specified key available, but may
map the accesskey to a different interaction behavior.
</quote>

... would be part of the SMIL 2.0 Recommendation save for an editing error.

2. UAAG Guideline 6
http://www.w3.org/TR/UAAG10/guidelines.html#gl-accessible-interface

3. User-defined accelerators work with the user's recall vocabulary.
Author-defined accelerators work with the user's recognition
vocabulary. It is well known that the recognition vocabulary is much
larger than the recall vocabulary. Allowing author-initiative
accelerators greatly increases the number of accelerators available
and used.

People with motor impairments need accelerators because of a high
cost of input action.

People with sensory impairments need accelerators because of a high
cost in time spent in non-visual display modalities.

While people with visual impairments are less able to capitalize on
accelerators that operate by recognition than are people with motor
impairments, the best compromise capability for both groups is to
allow both and allow the user with impaired accelerator-recognition
cycle to configure their UI to build on their strengths.

</position>

Received on Friday, 29 July 2005 21:04:00 UTC