This Wiki page is edited by participants of the HTML Accessibility Task Force. It does not necessarily represent consensus and it may have incorrect information or information that is not supported by other Task Force participants, WAI, or W3C. It may also have some very useful information.


From HTML accessibility task force Wiki
Jump to: navigation, search

(Feel free to edit) This is part of Keyboard access There are various other issues - tabindex, focus management (including ARIA, SVG and Shadow Dom focus management).

Use cases and requirements


Use cases
Webmail interface, Dynamic Game, Corporate Intranet Application, Educational website
Author hints, User control, Discoverability - controls, Discoverable - on/off, Navigate or Activate

See also PFs requirements from 2010, (also copied into Bug 23613 - Access Command Requirements for HTML5)

Implicit Use Cases from XHTML Access Module

The XHTML Access Module does not have an explicit set of requirements / use cases within it, but the implied requirements are:

  • Ability to declare a mapping that applies to multiple targets
  • Ability to declare navigation order of items
  • Ability to navigate within the 'group' of related items (e.g., chapter to chapter, image to image, advertisement to advertisement)
  • Ability to ensure that access 'keys' are mapped to specific media
  • Ability to declare whether changing focus to an item automatically activates that item or not
  • Ability to create a 'group' of related items with explicit or implicit navigation order but with no explicit 'key' mapping (so that the user agent can offer to create such a mapping if the user wants one)

Outstanding Bugs

23616 - clarify how accesskey affects role (duplicated by 23611)
Adding accesskey should make something focusable
23614 - accessKeyLabel can expose user information
Discussion in the Privacy Interest Group - it could increase the accuracy of "fingerprinting", which should probably be noted. There are mitigation strategies possible but they seem more complex than the problem they aim to solve.
It is not clear that the use case for accesskeyLabel (enabling a web page to identify the activation mechanism) remains valid
23612 - problems with button example for accesskey
The example script attempts to provide the information on what the user agent has assigned as an accesskey. That's ridiculous - user agent behaviour should be communicated by the user agent.
27654 - Algorithm for selecting accesskey doesn't mention user preference
This should be fixed - at minimum the "fallback" option should be given higher priority than the selection algorithm. But in addition, user preferences should be clearly mentioned as being important in a user agent implementation.

Note that much of the following is Chaals' opinion based on 15 years of discussions, arguments, and working directly on several implementations of accesskey in browsers.

Bad advice from HTML4

The idea that accesskeys would use the same activation as other functionalities led to damaging implementations. Those should be changed - it should be very clear that accesskeys should not over-ride the standard functionality of a browser or assistive technology.

Incidentally the same should be the case for anyone who makes the understandable mistake of trapping keys with javascript. Twitter is a prime example of a page that hijacks my UI, which is very frustrating.

Accesskey is only a hint

Users (or their browsers) need the ability to change the accesskey assigned.

Browser responsibility

Since authors don't know how activation is done, they should not be trying to explain it.

Accesskey is a fallback

Use role/rel/... where feasible. accesskey should be reserved for things that don't have a standard activation behaviour.

Accesskey: more than one character?

Currently it is a space-separated list of single characters reflecting author preferences for an activation behaviour that will be memorable. There is no reason that a value should not be a word, and for example in providing voice controls this may be helpful. Similarly, it may be reasonable to allow for the attribute with no specified value, and ask user agents to assign one. 13576 - allow words not just single characters - and 23615 gestures too…

Internationalization, keyboard mapping, and the use of mnemonic hints for key assignments

Mostly related to author advice, any solution must address the possible conflicts imposed when using non-latin keyboards, as well as discussing the problems of author-assigned key-bindings based upon perceived mnemonic patterns (e.g. [modifier + S] = Search)

Historical Research and data

Approximately 10 years ago (2004), Derek Featherstone and John Foliot (as posted a series of articles related to the problems with accesskey. While now significantly dated, those posts can be found at:

* Using Accesskeys – Is it worth it?
* More reasons why we don’t use accesskeys
* Accesskeys and Reserved Keystroke Combinations
* Link Relationships as an Alternative to Accesskeys
* The Future of Accesskeys

The XHTML Working Group did some work on creating a more abstract way of declaring access 'key' information and linking it to roles:

XHTML Access Module