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-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.
The HTML5 specification assumes that browsers manage the focusable objets on a page, and offers a list of things that should ordinarily be focusable:
- 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
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.
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.
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.