Skip to main content

User experience design

UX designers play a key role in ensuring everything can be done by keyboard. Information conveyed in wireframes helps developers implement all keyboard interactions. Since many users rely on a keyboard or assistive technologies that depend on keyboard operability, this is one of the best ways to improve accessibility.

Level 1

Follow established keyboard conventions

  • What to do

    Keyboard annotations should not overwhelm wireframes, but you should also avoid making assumptions about keyboard implementations. It may be necessary to include separate notes covering keyboard equivalents for mouse-operable controls. These annotations often emphasize navigation as much as operation. In both scenarios, you should use a consistent approach to annotate the wireframe using your organization’s tools and best practices.

    The core goal of wireframe specs about keyboard operation is to make it easier for developers to consistently implement the intended interaction. Consider establishing a keyboard authority, such as the Accessible Rich Internet Applications (ARIA) authoring practices or a framework’s own documentation. If you can agree on expected behavior with the development team, then as a designer you may only need to specify deviations from the keyboard authority in your wireframes. A reference table of component keyboard operation may be valuable to further reduce wireframe effort. Where notations are necessary, detail them on the first occurrence of a component. There is no need to repeat the same notation for every similar component.

    accordion with annotations 'Enter or Space bar expands or collapses accordion' and 'up and down arrows move focus between headers

    Annotate intended keyboard operation on wireframes.

    Resources

    Requirements

    Related toolkit topics

  • What to do

    Standard HTML elements provide all keyboard interaction “for free” and they are familiar to keyboard users. UX designers should learn this ‘default’ behavior. If a standard HTML element supplies the function required, advocate for its use rather than a custom component.

    Developers can alter the appearance of standard elements to match a desired design, while retaining the underlying functionality and programmatic ‘hooks.’ Mature frameworks may offer functionality that is fully equivalent to the HTML elements, but they should be checked for accessibility carefully.

    Browser support for standard HTML elements provides the following functionality without further development effort:

    1. Maintaining visible focus, predictable focus movement, and distinguishing between keyboard focus and the selected state
    2. Managing movement of keyboard focus between components, such as how the focus moves when Tab or Shift+Tab are pressed
    3. Managing movement of keyboard focus inside components that contain multiple focusable elements (typically using arrow keys), such as radio button groups and list boxes (select elements)
    4. Determining when to make disabled interactive elements focusable
    5. Assigning keyboard shortcuts and avoiding problematic conflicts with keyboard commands of assistive technologies, browsers, and operating systems
    dropdown select element with annotations 'Enter or Space bar opens or closes list', 'up and down arrows move focus between options and Space bar selects an option', and 'typing letters also navigates between options, but depending on browser, typing I then O may take you to idaho then iowa or idaho then ohio'

    Using standard HTML elements (such as this select element) rather than custom components reduces development effort

    Resources

    Requirements

    Related toolkit topics

  • What to do

    An accessible framework library can set up a team for success. A library (or design system) that is only partially accessible adds a lot of effort. Confirm if the framework’s accessibility was validated as part of planning exercises for a project. If not, question the owners of the framework library on how keyboard conventions are supported. Confirm the component library specifies, as much as possible, standard expected keyboard behaviors. Check if custom components from the design system follow the latest ARIA authoring practices. Perform manual confirmation of keyboard interaction.

    Resources

    Requirements

    Related toolkit topics

  • What to do

    Keyboard interaction is based on decades of desktop and HTML conventions. The ARIA authoring practices follow these conventions for established HTML patterns such as buttons and checkboxes, as well as providing consistent guidance for complex components which lack an HTML equivalent. By following the detailed keyboard interaction for each pattern, teams can ensure their custom components meet expected keyboard behavior. In conjunction with assigning the correct role to components, this keyboard behaviour makes custom components fully accessible to users through browsers and assistive technologies.

    Resources

    Requirements

    Related toolkit topics

  • What to do

    Standard HTML elements will rarely need any keyboard instructions within the UI. However, complex or custom components, where the interaction is less familiar to many users, may benefit from visible instructions. Hovering should not be the only way to surface such instructions, since a keyboard-only user won’t discover them. The best location for the instructions is directly in the UI or offered via a keyboard-accessible information icon. One option is to provide a visible instruction for a keyboard help shortcut, such as “Press Alt+0 for keyboard help.” Discuss keyboard instructions with content designers, to get their input and ensure keyboard behaviour can be included in accessibility documentation.

    drag and drop component with focus and a tooltip saying 'press alt+0 for keyboard help'

    Provide keyboard instructions in the UI for components where keyboard operation is less familiar. For this drag and drop component, the instructions appear on keyboard focus.

    Requirements

    Related toolkit topics

Ensure all pointer interactions have keyboard equivalence

  • What to do

    Most drag and drop interactions can be made keyboard accessible. Ensure the drag source and drop target are both selectable via the keyboard and in the focus order.

    Your design should specify three fundamental functions:

    1. How to select the item (drag source)
    2. How to move the item
    3. Where to drop the item (drop target)

    An implementation to drag a card to a new location in a set might be:

    • A sighted mouse user selects the card to move (with a mouse button click) and drags the card (click and hold) to a new list then releases the mouse button to drop.
    • A blind keyboard user navigates to the card to be moved (using Tab and Shift+Tab, or the arrow keys), activates the card’s Move button (with Space bar) which opens a menu of available targets. The user arrows down to select a target item and presses Enter or Space bar to drop the card on that target.
    Play

    This custom component provides keyboard equivalents for drag and drop.

    Resources

    Requirements

    Related toolkit topics

  • What to do

    Some components have multiple actions. For example, activating an employee icon launches a profile page for that employee, but hovering over the icon displays a small card with links to the employee’s e-mail and Slack name. Similarly, on a page with a set of card containers, any of the cards can be selected but each card also has actionable items inside it.

    In both cases, designers must consider how keyboard users achieve the same result. In the first example, if the links from the overlay are also exposed on the employee profile page, no hover equivalent may be necessary. In the second example, designers may decide that a user traverses cards with arrow keys, then presses Enter to ‘open’ a card and move between items inside with the Tab key. The user presses Esc to collapse the card.

    Whatever the solution, designers need to notate the keyboard equivalents in the wireframes so that developers do not miss implementing. Ensure that the multiple keyboard-equivalent operations do not conflict with standard ways the focus can be moved to and away from that component.

    two rows of tiles with a button in each and annotations saying 'Enter opens card for user interaction and Esc moves out of card' and 'up, down, left, and right arrows move focus between cards'

    Annotate the keyboard equivalent for components (such as these tiles) that have multiple mouse operations.

    Resources

    Requirements

    Related toolkit topics

  • What to do

    Keyboard users can get stuck in a UI, unable to proceed and (in the worst cases) unable to go back. The existence of the WCAG guideline “No keyboard trap” is meant to highlight this danger. One of the easiest ways to reduce keyboard traps is to ensure the Escape key always performs the same functionality as Cancel or Close mouse actions. Allow users to press Esc to exit from any dialog or activated component.

    modal dialog with annotations saying 'Esc also activates the close button'

    Ensure the Escape key triggers the same function as Cancel or Close buttons.

    Resources

    Requirements

    Related toolkit topics

Level 2

Audio, video, and auto-updating content can be manipulated

  • What to do

    Video players are frequently overlooked for accessibility. If the product will contain video, UX designers can check the player for accessibility and call attention to issues found. For any media player, check the following:

    • The keyboard focus indicator is visible when navigating and operating the media player controls.
    • All controls are accessible, using either Tab or arrow key navigation.
    • All settings are adjustable via the keyboard, including volume, closed captions, and playback location (slider).
    • The user can navigate to the elements before and after the media player (using Tab and Shift+Tab) without getting stuck.
    • If users can view videos in full-screen, a user can activate and escape from full-screen using the keyboard (usually the Escape key) and continue to navigate the page without getting stuck.
    video player with focus indicator on closed caption button

    The keyboard must be able to navigate and operate media player controls.

    Resources

    Requirements

    Related toolkit topics

  • What to do

    Auto-playing content can distract all users, and for some users with disabilities can affect their ability to complete a task, or even trigger debilitating physical reactions. As discussed in Visual design, it is best to avoid content that starts playing without user initiation. The problems are not restricted to the visual effects of videos and animations. For users who are blind, audio on the page competes with their screen reader’s audio, making it difficult or impossible to find and turn off the disruptive sound.

    Examples of auto-playing content are carousels, videos, animations, and background music. If it is necessary to auto-play such content for more than a few seconds, you must provide a keyboard-accessible method to pause that content. One method is to stop automatically when the element receives keyboard focus. Alternatively, provide a mute or pause control for auto-playing audio and a pause or close control for the visual content.

    annotated wireframe of carousel saying tab key can focus on and exit carousel animation and carousel should stop when focused on

    The wireframe annotations show the carousel stops auto-playing when it receives focus.

    Resources

    Requirements

    Related toolkit topics

Level 3

Updates to screen content are predictable

Character key shortcuts do not disrupt the user