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.

View source for Accesskey

← Accesskey

Jump to: navigation, search

You do not have permission to edit this page, for the following reason:

The action you have requested is limited to users in one of the groups: Users, 106, 44061-chairs.

You can view and copy the source of this page.

(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).
==[[Accesskey/Usecases|Use cases and requirements]]==
Summary:
;Use cases
:Webmail interface, Dynamic Game, Corporate Intranet Application, Educational website
;requirements
:Author hints, User control, Discoverability - controls, Discoverable - on/off, Navigate or Activate

See also [[Access/pf_requirements_revision|PFs requirements from 2010]], (also copied into  [https://www.w3.org/Bugs/Public/show_bug.cgi?id=23613 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)

==[https://www.w3.org/Bugs/Public/buglist.cgi?quicksearch=accesskey Outstanding Bugs]==

;[https://www.w3.org/Bugs/Public/show_bug.cgi?id=23616 23616] - clarify how accesskey affects role (duplicated by [https://www.w3.org/Bugs/Public/show_bug.cgi?id=23611 23611])
:Adding accesskey should make something focusable 
;[https://www.w3.org/Bugs/Public/show_bug.cgi?id=23614 23614] - accessKeyLabel can expose user information
:[http://lists.w3.org/Archives/Public/public-privacy/2014OctDec/thread.html#msg45 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
;[https://www.w3.org/Bugs/Public/show_bug.cgi?id=23612 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.
;[https://www.w3.org/Bugs/Public/show_bug.cgi?id=27654 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.
[https://www.w3.org/Bugs/Public/show_bug.cgi?id=13576 13576] - allow words not just single characters - and [https://www.w3.org/Bugs/Public/show_bug.cgi?id=23615 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:
 * [//john.foliot.ca/using-accesskeys-is-it-worth-it/ Using Accesskeys – Is it worth it?]
 * [//john.foliot.ca/more-reasons-why-we-dont-use-accesskeys/ More reasons why we don’t use accesskeys]
 * [//john.foliot.ca/accesskeys-and-reserved-keystroke-combinations/ Accesskeys and Reserved Keystroke Combinations]
 * [//john.foliot.ca/link-relationships-as-an-alternative-to-accesskeys/ Link Relationships as an Alternative to Accesskeys]
 * [//john.foliot.ca/the-future-of-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:

[//www.w3.org/MarkUp/2009/ED-xhtml-access-20090423/ XHTML Access Module]

Return to Accesskey.

Retrieved from "https://www.w3.org/WAI/PF/HTML/wiki/Accesskey"

View source for Accesskey

Navigation menu

Personal tools

Namespaces

Variants

Views

More

Navigation

Tools