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.
Use cases and derived requirements for "accesskey" (or whatever replaces it).
- 1 Use cases
- 2 Requirements
Generally, the idea of "accesskey.next" is to provide a simple, robust way for an application to identify that it is important for some object (navigation landmark, or application control) to have "immediate" "random access", as opposed to only being able to navigate to or activate the control through sequential selection like tabbing links and form controls.
For well-defined objects (form submission buttons, nav or main elements) this is unnecessary.
- relying on events that a particular user cannot generate
- for example assuming a mouse cursor breaks down for many touch interfaces and keyboard interfaces,
- conflicting with the user environment
- listening for key events in particular can cause this, as the key event may normally have a function in the interface of the user agent - especially assistive technologies which commonly extend the interface using keyboard shortcuts.
- Key events that are expected may also fail to match the user's keyboard - there is an enormous variety of them
Webmail interfaces have a number of controls typically implemented as buttons, such as Compose a new message, Mark as Spam, Label as Read, Forward Message, Reply, …
They have a number of navigation points - a set of folders or filters, some of which are common and some of which are specific to a user.
They allow navigating messages individually, but they may have a dynamic thread navigator, allow navigation of archives by time, e.g. weeks or months.
Many interactive games require continuous input, most typically managed from a keyboard or mouse although touch interfaces are common and gesture-based interfaces are becoming more common.
Corporate Intranet Application
Like webmail, there are a number of applications that people can be expected to use very regularly, for functions like recording time worked, planning applications and the like.
Educational websites can have a variety of interactive components meant to demonstrate different concepts.
These components can have a widely variable range of functionality - for example the controls for analytic chemistry simulators are likely to be very different depending on the particular analytic techniques being demonstrated.
Media player interfaces
Media players have a number of controls, typically buttons and sliders, for standard actions like Play, Pause, Volume up/down, Captions and so forth. Often a media player is the primary artefact within an interface that contains other content, YouTube or Vimeo for example.
Composite widgets that represent complex structures may use aria-activedescendant to manage focus. In such cases there may be situations where it is helpful to move directly to the active descendant, for example to a menuitem within a menubar or the current date within a datepicker.
The author is the only party with a priori knowledge of the specific function of the control. The author should be able to propose useful mnemonics for the control.
User Control of behaviour mapping
The user (or their user agent) must be able to determine which particular behaviours will be mapped to "accesskey" triggers.
Discoverability - on/off
The user must be able to discover that a page has assigned "accesskey" triggers.
Discoverability - controls
The user must be able to discover what controls are mapped to which objects in the page.
In some cases the most appropriate behaviour is to navigate to a control, in others to activate it directly. While authors are likely to have a sense of the most useful default, different users have different requirements. Determining this choice should allow for an author hint and must allow for user control