Cascading input device key-binding

Problem statement / use Cases

Users with disabilities

Creating desktop-like web applications

Objectives for key binding

These objectives are drawn from the DroppedAttributeAccesskey#head-38496546a85f60478aa3ac529ebb1fbda04397d0: rationales for dropping the accesskey attribute:

1. a key binding mechanism should provide an approach for user discovery of bindings in a device independent and accessible manner.
2. a key binding mechanism should include specific targets and actions indicating what node is targeted by the key and precisely which action to invoke on the target (actions such as focus(), activate(), click(), nextFocus(), previousFocus(), etc.). The action focus() could be the default action with the UA navigating through multiple targets by giving each one focus, in turn, with each key invocation. If not target element is specified, then the the currently focussed entity would receive the action call: whether that is the document, or a specific element. In this way the tabindex implementation would simply be an implementation of the key binding index where the QName 'tab' is mapped to the action nextFocus(). Likewise, the QName 'shift-tab' might be mapped to previousFocus().
3. a key binding mechanism should take a value of QName rather than a single character to allow greater device independence and essentially an infinity of possible keys. To meet this objective QNames could be defined in terms of: 1) keys on a specific device (102 key keyboard, 12 key phone keypad, keys on a 18 key numeric keypad); 2) including modifier keys and modifier key combinations such as 'shift', 'control-shift', etc.; 3) keys shared across devices (such as 0 – 9, '*' '/' '+' '-', '.', '=' all shared across numeric and alphanumeric input devices) 4) special keys used in defined in an environment specific way ('cut', 'copy', 'undo', 'redo', 'bold', 'selectall', 'nextfocus', 'prevfocus', 'close', 'find', 'preferences' etc.). 4) also modifier keys and modifier key combinations defined in an environment/OS such as modifierA, modifierB, etc. where modifierA might map to the command/apple key on Mac OS and the control key on Windows. The modifierA might be the defualt value for the @modifierkey attribute.
4. a key binding mechanism should specify UA norms for handling key binding precedence. For example: "A user agent must treat key bindings from HTML documents as primary over other key bindings while the HTML document remains key. User agents may, at user option, reverse these priorities." Some steps and research may be needed to ensure some global and UA-wide key bindings remain available to the user at all times (including them as specific key QNames and including them as !important in the UA key binding). Focussing on the last category of QNames would be best practice (those mapped to environment/OS specific functions such as 'close'). UAs could even inform a user everytime a document wanted to establish its own key bindings and offer to bring the user to a key binding discovery/edit panel. Without any need for explicit key binding declarations, UAs should automatically map keys — either through environmental/OS convention or user-defined — to each standardized role in a document. CSS-like cascade could also be followed — taking into account specificity and location (UA, author, user) — to determine what a particular key QName selector won out. Specificity would be determined in order: 1) special environment independent key QNames (like 'close' or 'keybindingpreferences' and 'modifierA' over 'control' for modifier keys) and environment modifier keys (e.g., 'modifierA'); 2) keys specific to a device (e.g., Pzero over zero; 'enter' over 'return-enter'); 3) finally keys shared across devices (e.g., 'asterisk'). User agents would be responsible for entering all key bindings in the user agent definitions with an !important value set to take precedence over any author defined key binding.
5. a key binding mechanism should provide an approach for using QNames instead of characters to indicate key bindings. For example, the character '*' (U+002A) could map to the QName 'asterisk'. This would be the asterisk key on devices independent of their location. However other more specific asterisk keys might also be specified such as Aasterisk for the alphanumeric keyboard asterisk key, Nasterisk for the numeric keypad asterisk key, or Pasterisk for a phone-pad asterisk key. The current character values could be mapped to QNames one-to-one for keys shared across several key input devices. For example, characters could map to Qnames such as 'a' => 'a' or '1' => 'one' or '/' => 'solidus'. This approach conforms to the common practice in HTML/XHTML to use ASCII-compatible NCNames. The 'a' QName would be well-defined by the specification and would typically correspond to the key used for inputting the 'a' character in one particular locale (such as the US). This could cause confusion for authors in other locales, so any specification should clearly show mapping of keys to QNames for any targeted key input device (e.g., 102 key keyboard, numeric keypad, phone keypad). Other keys might suggest obvious QNames such as 'F1' – 'F15' or 'escape'. Best practice would be the use of input device independent QNames such as 'close', 'nextFocus').

Proposed solutions

While the XHTML2 access module is an improvement over HTML 4.01, it still has many of the limitations listed here. By using characters, it tries to use a particular configuration dependent character/key-mapping to designate the key. Instead, a QName approach would allow authors to specify key bindings in a much more device independent and internationally appropriate way. Also QNames allow an abstraction away from actual device keys so the meaning of a 'modifierA' access key would be environment dependent. Or by selecting the 'copy' key binding, a key the user already expect to perform a copy would add something to the clipboard (or perform something analogous). Authors would still be able to specify focus changes for specific keys, but they could do so in a more structured environment. Adding several attributes to the XHTML2 ACCESS element would facilitate these objectives: 1) changing @key to accept a QName; 2) adding a @modifierkey attribute to specify a modifier key QName (these would inlcude things like modifierD that could indicate multiple modifier keys — such as 'shift-control'— and would be an environment-specific mapping) 3) an @action attribute indicating an action to send to the targeted element ('focus()' could be the default for an unspecified value); 4) an @important boolean attribute to indicate a higher priority in the cascade. Finally, setting the @xml:lang and @media attributes on the ACCESS element could allow multiple duplicate ACCESS elements (only differing in the @xml:lang and/or @media value) each mapped from different keys in a language or media dependent manner. This involves QNames for @targetrole, @modifierkey and @key. These Names may even be quite similar. For example a nextFocus key NCName would indicate the key conventionally (or by user override) used for setting focus to the next view. While nextFocus() would be an action performed by a handler for an element. A navMenu could be either a Name for a role, or it could be the name for an environment/OS conventional key to set focus to the next navigation menu.

Adding the several attributes to the following elements would allow authors, UAs and users to specify rich key binding behavior for web documents: especially application documents:

• The li element within menu elements
• The option and optgroup elements within select elements
• The command element
• The input element

New attributes:

<access
src='URL'
important='BOOL'
targetrole='QName'
targetid='IDREF' 
action='DOMAPICall' 
key='QName' 
modifierkeys='QName'
media='MediaTypes'
xml:lang='LanguageCodes'
/>

• For cascading
  • src='URL' A URL to link an access element to an external key binding document.
  • important='BOOL' A boolean indicating this key binding to this target action is important in the determining the cascade.
• Targets
  • targetrole='QName' A role QName indicating the action should be sent to the next element playing the designated role. When both target role and targetid are omitted, the target is the element with the current focus.
    • targetid='IDREF' An IDREF indicating a specific element to send the action to. When both target role and targetid are omitted, the target is the element with the current focus.
• Action
  • action='DOMAPICall' Optional DOM API action to invoke on the targeted node. The default is focus()
• Keys
  • key='QName' A key to use to invoke the command.
  • modifierkeys='QName' A list of modifier keys to invoke the command.
• Other attributes to reduce the scope of the keyboard binding
  • media='MediaTypes' A list of media types the key applies to.
  • xml:lang='LanguageCodes' A list of languages the key applies to.
  • title="STRING" A title for use in menus and for discovery.
  • description='STRING' A description for use in menus and for discovery.

It may be useful to break-out some of these attributes into other elements. In particular separate descendant elements for key, modifierkeys, title, and parentmenu might enable simpler localization of these properties while maintaining the non-localized portions of the key binding target action properties within the parent element.

Furthering this CSS analogy, the ACCESS element could be thought of (or even made) a separate specification. Then the ACCESS element would be just like the STYLE element where it embeds key binding data in the documents HEAD rather than style sheet data. This suggests, that it may also be useful to include a @src='URL' attribute on the ACCESS element to allow it to similarly point to a linked document containing only key binding data. This could address the concerns that key binding should be on a separate plane from semantic document markup. Key bindings would also be reusable across documents for authors using the same IDs or @role values in an author custom vocabulary. While authors, users and UAs would still have many key binding issues to deal with, this approach would simplify the handling of those issues and permit management of that complexity more easily.

A final suggestion on this possible key binding mechanism. The title attribute or a new menutitle attribute could be introduced to support adding these keybindings to menus: creating menu commands. In this way a UA might make all of the commands available in a convenient menu so that even the commands whose keybindings lost in the cascade, would still be available to the user in a convenient menu. Introducing a new menutitle attribute would allow a new menutitle value syntax where a hyphen-minus or solidus could delimit precise menu hierarchies. So the two items, "style-numbered" and "style-bulleted" would both appear in a style menu in the UA. One other useful attribute, might indicate the ordering of these items within a menu. This would give authors significant control over UI features usually reserved for desktop applications.

Discussion and evaluation

Research

• Accesskeys and Reserved Keystroke Combinations [1]

Policies, Guidelines, and Law

• WCAG 1.0 sets requirements including that interactive content itself present an accessible interface, links to ATAG and UAAG
• UAAG 1.0 sets requirements including device-independent actuation of event handlers and discovery of keyboardable actions

Related References

• WAI/DI briefing to Backplane Workshop
• Intent-Based Events topic in Ubiquitous Web Applications charter
• XHTML access module
• Access + Key Still Equals Accesskey - The XHTML2 proposal for the ACCESS element includes (included?) the attribute of @key. My opinion is that allowing content authors to specifically map a modifier key (using @key) will continue to perpetuate the problems inherent with @accesskey.
• User-Defined Access Keys
• Greasemonkey User Script to Manage Access Keys

Advice From Authorities

• Protocols and Formats WG: Outside of ARIAIntegration: ARIA we would like HTML 5 to support the XHTML access element. The access element supports badly needed semantics for access key navigation but without the need for device dependency restrictions. Additionally, if accessibility features are being removed from HTML 4.01, such as longdesc or alt text, we need to make sure that the base markup supports the appropriate equivalent functionality in terms of interoperability with assistive technologies. (Source: Al Gilman, chair of PFWG, post to public-html)

The rationales listed for not including the @accesskey attribute list several problems with the specification and implementation of @accesskey. It is worth considering the alternative to removing the feature: that of addressing those problems. One way to deal with the issue is to provide a richer replacement for accesskey, like that proposed for XHTML2. However, there are other issues that the XHTML2 access module does not address that HTML 5 could address.

Email

WG members should post feedback and other discussion to the WG’s list serve Search on this email subject.

(the URI for the links below provides date information)

• [ initial message]

July 2007

Thread: Opening Thoughts on Integrating ARIA into HTML5

• Al Gilman, post to public-html (18 July 2007)

See also