Accesskey/Usecases

Use cases and derived requirements for "accesskey" (or whatever replaces it).

Use cases

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.

Normally today the mechanism for doing this is to use javascript, and listen for various events including mouse, pointer, key and touch events. This is neither simple nor robust. The most common problems are

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 interface

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.

Dynamic Game

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 website

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 widget

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.

Requirements

Author hints

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.

Navigate or Activate

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