[techs] coordination of DRAFT position on hotkey requirements

<note class="concurrence process">

The basic ideas presented in the draft below have gained a rough
consensus in the PF Working Group.

PFWG is seeking feedback from the guidelines
groups (User Agent, Web Content, Authoring Tools)
before representing this as a WAI position.

The draft has been edited with the benefit of some friendly
amendments from the User Agent Working Group who were also in
general agreement.

Also some "authors and authoring" issues have been appended where
your topic is involved and your feedback is desired.

Please put this up for consideration [in the Techniques Task Force?] and
let me know when it will be on the agenda for a telecon if it will be discussed
in real time in that way.

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 similar to the 'accesskey' functionality in HTML 4.

Requirements:

1. The user must be able to request and be told what hotkeys have
been enabled by the web page or application through a Browser
function. The user must be able to re-bind outcomes that are
accelerated in this way to be triggered by alternate user input
gestures. The user does not have to be able to substitute arbitrary
UI events. But the substitution ability must be rich enough to work
around collisions between web-defined hotkeys and the system and
browser environment, and to work around non-usability of a particular
UI event by a particular person or their client device. The user must
be able to replace aggressive outcomes (at least 'activate' actions)
to more step-by-step procedures (by substituting a 'focus' event
targeted to the same object).

2. This ability to review and 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>

<issues>

There will be a temptation for authors to use more low-level means,
specifically binding a hotkey to an event defined by element ID and
event type, as opposed to identifying this action by binding the
accelerator to some widely-recognized role that this element fits.
Sample roles would be "search: search the site or sub-site where this
page is found," "home: go to the home page for the site where this
page is found," etc.

The low-level definition of the accelerator is bad for users who are
better prepared to take advantage of accelerators associated with
concepts that they recall rather than concepts the only recognize in
the display of the content. In particular this makes it bad for
screen reader users and superusers. On the other hand, using the more
conceptual markup is not a detriment for the visual user, just more
of a cognitive burden on the author (that we will want to ease by
author tools).

In terms of achieving recommendable web-markup practices while the
author has the ability to create a hotkey with either more-conceptual
or less-conceptual markup, there will be a burden that falls on the
author advice (WCAG guidelines and techniques) and tools (ATAG
techniques) to get authors to use the more-universal, more-conceptual
markup features *where they apply.*

[why no free lunch] If we try to force everyone to use access by role
rather than access by targetEvent, people will pollute the role
vocabulary with roles that are tantamount to specific target events
after the manner that 'class' has been used as a synonym, not
rationale, for presentation effects. And if we try to force the use of
only standard roles, we cut off the ability to create application-specific
accelerators.

To get out of this bind, we pretty much need the WCAG techniques
to both say and demonstrate the advice "mark your [page parts and]
hotkey target elements with well-known 'role' values wherever they
fit.  And target your hotkeys in the most generic terms that get the
right thing to happen (e.g. if there is only one 'search' tool on the
page, or if a user might want to step through them if multiple, target
a key to the 'search' role rather than to a particular element which is
a container of the search tool).

The ATAG techniques will need to promote author prompts that let the
author just recognize the applicability of standard roles to their
hotkey targets, rather than waiting for the author to volunteer that
this target is actually performing some generic role. In other words
the author should confirm, deny, or pick among a short list of
heuristic-selected candidate roles and not have to enter a role name
in a text box.  The author tools should also prioritize hotkey targets
for 'role' definition.  There are lots of elements in a page that don't
play a role we need to articulate.  But not too many hotkey destinations
that don't.

Does the WCAG Techniques Task Force feel that, with that sort of
support from authoring tools, authors in significant numbers would
accept and follow access-positive practices in defining hotkeys for
Web Applications?  Is it worth taking the risk of relying on good usage
here?  Is the game worth the candle?

Closer to home, should we just leave it to the separate working
groups' Techniques documents to get out the word on this, or should
we be thinking of this as a WG or CG Note to pull together the team
of techniques that if all are used in their respective segments of
the Web system, together create a service delivery pipeline that
works. [This issue will naturally go back to WAI CG but your input
would be helpful]

</issues>

Received on Friday, 12 August 2005 18:36:15 UTC