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.
Keyboard
Keyboard-only control is an important use case. For some people this is due to constraints on their ability to use other interfaces, for others it is a question of efficiency and comfort. But it is important that keyboard control is compatible with other approaches, and the current situation of the Web doesn't always make this happen.
In addition, there are specific current problems with keyboards, such as arise when trying to implement Accesskey|shortcut behaviours]] for keyboard users.
Focus management
The HTML5 specification assumes that browsers manage the focusable objets on a page, and offers a list of things that should ordinarily be focusable:
- links
- form controls and their labels
- Elements with an Accesskey
- Elements with appropriate tabindex values
- Image maps (and the images for which they are maps?)
- Things that are contenteditable
- Javascript-based interactions that don't have an onscreen representation
It doesn't clearly specify how focus navigation takes place. The most common assumption is that users move from item to item by repeatedly pressing the tab key.
This assumption is a problem because
- It is terribly inefficient
- it is wrong - browsers, extensions, and assistive technologies offer users more efficient navigation paths of various kinds.
Feedback
Focus rings are considered helpful for keyboard interaction, but apparently not so much for touch or mouse users.
Brian Kardell (and others?) are working on an input-modality property to allow authors to adapt the presentation depending on how the user arrived at a given item
Chaals has a dissenting opinion, finding both the effect of enlarging the clicked area to check the target, and having a focus ring that can be moved around that, a useful thing for user agents to do, and hoping that authors won't just take thing away from me. Also, wondering how it works on something like a surface, where I use keyboard and a pointer according to particular characteristics of the page or part i want.
Custom elements
Complex ARIA controls that are not generally available in "pure" HTML tend to include statements suggesting specific interaction behaviours, and examples generally provide a mess of javascript in order to implement them.
Shadow DOM / Web Components don't seem to have a good story for this at all yet, but Takayoshi Kochi is working on a proposal, in webapps / Bugzilla.
Activation
Assuming you can get to the controls, and there is a way of knowing what they are, you have a primary activation (click) an perhaps a menu of additional options.
This can be complicated by the fact that some controls are designed for the input of text, and typically capture most of the keyboard for this functionality.