Skip to main content

Coding interactions

As detailed on the user experience design keyboard topic, keyboard interaction may be the most critical step to increase the accessibility of a product. Every action a mouse user can do should have a keyboard equivalent. As more designers capture keyboard interaction in wireframes, developers can expect more explicit keyboard guidance. But developers must themselves become more familiar with conventional keyboard interaction. Most wireframing tools capable of outputting functional prototypes emphasize pointer interaction. Developers are usually the first team members who can experience how a design feels to a keyboard user. This is the reason keyboard testing is emphasized in unit testing.

Level 1

Properly code the navigation order

Implement established keyboard conventions

    Use standard HTML elements where possible, using CSS to alter appearance not behavior

  • What to do

    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.

    <!DOCTYPE html>
    input[type=text] {
    width: 100%;
    padding: 12px 18px;
    margin: 8px 0;
    box-sizing: border-box;
    Requirements and resources
    Related toolkit topics
  • Be familiar with established keyboard conventions

  • What to do

    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.

    Requirements and resources
    Related toolkit topics
  • Implement keyboard operation for custom elements

  • What to do

    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.

    Requirements and resources
    Related toolkit topics

Level 2

Ensure keyboard access to complex interactions

Level 3

Code screen updates predictably