'access' attribute in XHTML 2.0

In draft of new language:
http://www.w3.org/TR/xhtml2/mod-hyperAttributes.html#adef_hyperAttributes_access

Existing HTML 4.01 capability:
http://www.w3.org/TR/html401/interact/forms.html#adef-accesskey

Discussion on reform requirements:
http://www.w3.org/Search/Mail/Public/search?keywords=accesskey+&hdr-1-name=subject&hdr-1-query=&index-grp=Public__FULL&index-type=t&type-index=wai-xtech

* Summary:

It is not clear that this attribute is needed or desirable.

Custom hotkeys might be better handled as an application of the XML
Events capability in XHTML 2.0, with some sort of a label for the
action included in the event declaration and keybindings nominated
via XBL in a style rule.

http://lists.w3.org/Archives/Public/wai-xtech/2004Aug/0011.html

We might want to go so far as to define content markup (XHTML 2)
along the lines of [workalike syntax, not literal syntax proposal...]

<event>
<label>Nex<key>t</key> message in Thread</label> ...
</event>

This would give a clear indication of which instance of the letter
't' in the label content should (unless the stylesheet is overruled
in the client processing) be the one styled in a distinguished way to
convey the hotkey code to the visual user.

For standard intrapage navigation actions such as "jump to main
content" an input symbol binding set by the browser is preferable to
one set by the author. The identification of where these intrapage
jumps would go could be handled by 'role' or 'class' markup without
having to invent an 'access' attribute which imparts view-specific,
not document-generic information.

Specific points:

It is not enough to say "this behavior may be adjusted by the User Agent."

In the spirit of the UAAG 1.0 Guideline 5 we need to say "the user
agent must [should?] afford the user a configuration control to
require that the following hazardous actions will not be done
immediately unless the element being activated had focus at the time
of the user event leading to the activation.

- open new window
- load new document in current window
- change state of form instance variable

http://www.w3.org/TR/UAAG10/guidelines.html#gl-user-control-ui

This configuration option should be programmatically settable by AT
as well as interactively settable by the user adressing the
view-control dialogs of the browser chrome.  This requirement should
be set out in the XHTML 2.0 specification.

For actions that activate a hyperlink, i.e. recover a representation
of a URI in an HREF and open the recovered document in the same or a
new window, if there is a hyperlink in the current document that
performs this same action, then focusing that element as an
alternative to activating it is an acceptable behavior modification
(under this configuration setting).

We may need to review the situation regarding automatic recomputation
of related form fields (city, state computed from Zip, e.g.) as
regards the UI behavior that would work under eyes-free conditions.
In this case a simple replacement of 'activate' with 'focus' may not
suffice.

* Discussion:

We need to divide the application space up and make sure that we have
solutions for the several sub-cases. But the solutions may differ.

Differences that matter include:

- Outcomes that replace the document context the user is in, vs.
navigation actions that sustain the overall context so that 'top of
page' will yield the same 'start over' capability as before the
shortcut action.

- links that directly and uniquely implement functions that the user
will recall (will likely have memorized) such as 'home' or 'site map'
vs. shortcuts that optimize user input streams accelerating access to
a link or control or otherwise active widget that the user has
recognized in the visual display.

Example pair of applications that
a) differ in both these aspects and
b) might both be implemented by ACCESSKEY in HTML 4.01
are:

- custom keys to access an application-specific function such as reviewCart
or checkOut, vs.
- standard intrapage navigation such as mainContent or leftNavBar.

Please consider these issues in your work on how we replace 'accesskey'
from HTML 4.01.

Al

Received on Friday, 27 August 2004 18:48:40 UTC