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.
(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).
- 1 Use cases and requirements
- 2 Outstanding Bugs
- 3 Bad advice from HTML4
- 4 Accesskey is only a hint
- 5 Browser responsibility
- 6 Accesskey is a fallback
- 7 Accesskey: more than one character?
- 8 Internationalization, keyboard mapping, and the use of mnemonic hints for key assignments
- 9 Historical Research and data
- Use cases
- Webmail interface, Dynamic Game, Corporate Intranet Application, Educational website
- Author hints, User control, Discoverability - controls, Discoverable - on/off, Navigate or Activate
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)
- 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.
Accesskey is only a hint
Users (or their browsers) need the ability to change the accesskey assigned.
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 WATS.ca) 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: