Warning:
This wiki has been archived and is now read-only.

DroppedAttributeAccesskey

From HTML WG Wiki
Jump to: navigation, search

Dropped Attribute: accesskey

Issue: Justification for the current dropped status of the "accesskey" attribute defined for the A, AREA, BUTTON, INPUT, LABEL, LEGEND and TEXTAREA elements in HTML 4.01.

Quick Links: DroppedAttributeAccesskey#head-61c16b9d16f811aba1b3cf32250d72a1a80b0179: Details | DroppedAttributeAccesskey#head-22efce57efc348efacfea2261f305615a5882d12: Solutions for Reforming and Retaining Accesskey | DroppedAttributeAccesskey#head-cd3a883d7cc21ec28b484e90da29a52cd6e4af3b: Use Cases | DroppedAttributeAccesskey#head-487a1cbfaf76a97aa0e5a750102937af3b3f1f20: Advice from Authorities | DroppedAttributeAccesskey#head-ce0c9bc89ede2a2ba87f8d69b402c109b41bb393: Examples | DroppedAttributeAccesskey#head-7303f68cdcc041b334fc065da25b759826c7918b: Implementations | DroppedAttributeAccesskey#head-7efc161929e3e0580af7691ba33ad263452684f6: Research | DroppedAttributeAccesskey#head-585f7af7ea2f825d4e5a2ac44978fa11effd6d94: Policies & Law | DroppedAttributeAccesskey#head-4cc71400c96c49f5a8f48ca6179e63f66a34f920: References | DroppedAttributeAccesskey#head-1fb0f5bea0362a299d20c823bf82832f2e1c0e01: Email

Details

Rationale: Why the "accesskey" Attribute Should Not be Included

  1. The definition of "accesskey" is ambiguous. Users do not know:
    • how is the accesskey to be invoked? Is there a limit to moderator keys?
    • what is the expected action upon invoking an accesskey -- move focus to element for which the accesskey has been defined, or activate the element for which the accesskey is defined
  2. There are a finite number of keys available for use as accesskeys;
  3. Accesskey implementations can "steal" hotkeys from the UA's chrome; likewise, an accesskey defined by an author can be interpreted by the user agent as input directed to the chrome; for an example of this, visit the list archives for public-html; once one chooses a time frame, one can ostensively use accesskeys to switch views from date (accesskey = d), author (accesskey = a) and thread (accesskey = t), but if one is using a user agent that uses the ALT key as the accesskey's modifier key, invoking ALT+A to select the view by author can lead, instead, to a menu item whose accelerator key is also A
  4. Accesskeys may be defined for characters that comprise the document's natural language, but that language's character set may not be supported by the user agent or operating system.
  5. An alternate, superior mechanism can be found in the XHTML access module, which supports essential semantics for accesskey navigation, but without the device dependency restrictions of accesskey as defined in HTML 4.01.
  6. Applicable Design Principles (proposed)
    • Accessibility
    • Device Independence
    • Internationalization
    • Interoperability

Rationale: Why the "accesskey" Attribute Should be Included

  1. The ambiguity of the definition of accesskey in HTML 4.01 allows for more user control over the action and invoking of an accesskey. User agents can offer end users the option of picking the accelerator/modifier key that triggers a user defined event: move focus to element for which the accesskey has been defined or move focus to and activate the element for which the accesskey has been defined.
  2. The alternate equivalent/superior mechanism may be predicated on the adaptation into HTML5 of the XHTML access module, which supports essential semantics for accesskey navigation, but without the device dependency restrictions of accesskey as defined in HTML 4.01.
  3. Applicable Design Principles (proposed)
    • Accessibility
    • Device Independence
    • Internationalization
    • Interoperability

Considering solutions other than removing the attribute

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.

  1. The definition of "accesskey" is ambiguous. Users do not know:
    • how is the accesskey to be invoked? Is there a limit to moderator keys?
       objective a key binding mechanism should provide an approach for user discovery of bindings in a device independent and accessible manner.
  • what is the expected action upon invoking an accesskey -- move focus to element for which the accesskey has been defined, or activate the element for which the accesskey is defined
       objective 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().
  1. There are a finite number of keys available for use as accesskeys;
       objective 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.
  1. Accesskey implementations can "steal" hotkeys from the UA's chrome; likewise, an accesskey defined by an author can be interpreted by the user agent as input directed to the chrome; for an example of this, visit the list archives for public-html; once one chooses a time frame, one can ostensively use accesskeys to switch views from date (accesskey = d), author (accesskey = a) and thread (accesskey = t), but if one is using a user agent that uses the ALT key as the accesskey's modifier key, invoking ALT+A to select the view by author can lead, instead, to a menu item whose accelerator key is also A
       objective 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.
  1. Accesskeys may be defined for characters that comprise the document's natural language, but that language's character set may not be supported by the user agent or operating system. [More importantly, the character may not map to a key on any connected input device (even if it is a supported character for rendering, text storage, and text manipulation)]
       objective 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').
  1. An alternate, superior mechanism can be found in the XHTML access module, which supports essential semantics for accesskey navigation, but without the device dependency restrictions of accesskey as defined in HTML 4.01.
       Note 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.

       Note 2 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.

       Note 3A 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.

Use Cases

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)

Examples

Implementations (listed alphabetically by product name)

  • FireFox uses ALT+SHIFT as modifier keys to invoke accesskey
  • Microsoft's Internet Explorer uses the ALT key as the modifier key to invoke accesskey
  • Linux Operating System/Galeon/Mozilla uses the ALT key as the modifier key to invoke accesskey
  • Linux Operating System/Konqueror uses the Ctrl key as the modifier key to invoke accesskey
  • Opera allows for exposition of all accesskeys defined for a document instance, and allows the user to choose the modifier key

Research

  • Accesskeys and Reserved Keystroke Combinations [1]

Policies, Guidelines, and Law

Related References

Related E-mail

July 2007

Thread: Opening Thoughts on Integrating ARIA into HTML5


Retrieved from "https://www.w3.org/html/wg/wiki/index.php?title=DroppedAttributeAccesskey&oldid=1516"