Develop - keyboard

For users to be able to interact using a keyboard, components must be included in the tab order (so that they take focus when a user navigates a page with the Tab key). Wireframes should indicate to developers both what elements take focus, and in what order. They may also indicate interaction when navigation takes place within a complex widget (usually using arrow keys). Where wireframes do not provide clarity on keyboard navigation, discuss with the design team.

The code techniques for including elements in the tab order vary depending on the source of the component:

Correctly ordering content in the Document Object Model (DOM) is the preferred way to achieve a focus order. The order can also be adjusted programmatically, but there are accessibility considerations with most of the techniques.

When dynamic content is inserted, you must take care to insert the content in the correct place in the DOM to maintain a logical tab order.

Ensure that when a dialog appears because of a user action, focus is set on an interactive element within it. When the dialog is dismissed, return the focus to a logical place, typically the element that caused the dialog to appear. Consult with the UX designer to ensure smooth transitions of focus.

Use caution setting the tabindex attribute on elements to a number greater than zero, which causes them to receive focus before focusable elements that lack tabindex or have tabindex="0". After all the elements with a tabindex greater than zero have received focus, the rest of the elements receive focus in the order they appear in the DOM.

When an object takes keyboard focus, it must visually display a focus indicator. By default, interactive HTML elements will receive a focus indicator from the browser. Any time the design calls for an override of the default focus indicator, implement a replacement focus indicator that is highly visible, as per the design.

The following practices remove the focus indicator and need remediation or a replacement focus indicator controlled by scripting:

The following resolves a missing focus indicator by using the CSS property outline (here adding a really obvious thick, dotted red line!), and also adds some space between the elements and indicator with use of the CSS property outline-offset.

Standard HTML elements are built with full keyboard operability. The keys used to operate HTML elements are predictable, and consistent with keys used to operate native operating system elements of the same type. Use of HTML elements reduces the work for a developer because the browser handles the keyboard functionality for the element.

If the design shows a certain visual treatment for an HTML element, override the default browser styling and use CSS to change its appearance.

Standard HTML elements already have well thought out keyboard functionality built in. The keyboard operation closely models what works for similar components in desktop operating systems, making navigation and usage predictable for the user.

However, there are many operating system components that don’t exist natively in HTML, such as menus and sliders. Accessible Rich Internet Application (ARIA) markup was created so developers can build custom components that consistently work with assistive technologies. Implement keyboard handlers using established conventions to give full keyboard access to the functionality of the component. For predictable usage via a keyboard, it is best to implement keyboard access consistent with the patterns found in the ARIA authoring practices.

Be cautious when using a code framework or design system with custom-built components and patterns. Many frameworks were not built or maintained with accessibility in mind. Check the documentation and verify keyboard operability of all functionality. Any time the keyboard operation of a custom component departs from convention, discuss the reasons and risks with design.

Once the keyboard operation is fully defined, use ARIA techniques to implement any custom components. When using a UI component library, use only components that have a full implementation of keyboard access. For all other components, use the ARIA authoring practices and examples to guide keyboard implementation. Remember that although you can assign roles through ARIA, you still need to implement all keyboard interaction using events like onkeydown.

Wireframes may specify where navigation has been improved by grouping controls to reduce tabbing. This is most common in composite components, such as navigation trees and toolbars where the tabindex attribute and aria-activedecendent property can be used to manage navigation within a component. The ARIA authoring practices provide keyboard operation guidance, as well as working examples where you can examine coding techniques.

People who are blind do not use a mouse to interact with media players, which means all of the player’s features must be keyboard accessible. If the content designer obtains a video for use with a specific embedded player, the keyboard accessibility should have already been verified and you won’t need to do anything other than embed the multimedia.

If you create your own media player using the HTML media API, the design should provide the keyboard shortcuts. Implement full keyboard operability of the applicable features of the player:

Be sure to unit test your implementation to ensure all functions are keyboard operable and the visual focus indicator is visible for all of the player’s controls.

Keyboard operation can be affected if items that take focus are not visible in the viewport. Temporary or secondary information such as banners, overlays, and pop-ups should be implemented so they do not potentially obscure items receiving keyboard focus.

When users move keyboard focus to an element, they don’t expect major content updates to occur or forms to be submitted. For someone who cannot see, such unexpected events can be especially disorienting. Context changes such as this should be triggered through an activate event rather than a focus event.

Changing the context or focus when a user makes a selection or types input in a field is unexpected behavior and disorients users. This is especially true when the user has a vision disability, and cannot see what happened. You can update content of other elements on the page based on a user’s selection, but avoid automatically changing focus at the same time. One way to do this is to use an onchange event to trigger updating content based on the user’s action, such as making a selection. Another way is to incorporate a Submit button that provides an overt action where the user would expect a focus change.