Skip to main content

User experience design

One of the best ways to improve accessibility is to design for keyboard, since many users rely on either a keyboard or assistive technologies that depend on keyboard operability. Designers should start by specifying how interactive content is reached using the keyboard. There are other navigation considerations. For users who cannot see or who must use magnification, tables can be challenging to navigate. The same users and others benefit when there are multiple ways to interact with an application.

Level 1

Design for keyboard navigation

    Note intended keyboard navigation in wireframes

  • What to do

    When designers give specific guidance on keyboard navigation, it helps ensure the successful implementation of accessibility. Use a consistent approach to annotate the wireframe using your organization’s tools and best practices. A common convention is to number the tab stops, with a right arrow used to indicate cursor key movement. For a series of similar pages, it is usually only necessary to detail keyboard navigation once. There is normally no need to repeat the same notation for every similar component or page.

    annotations show the keyboard tab stop on the first active tab pane in the group and the arrow keys are used to navigate each tab pane

    Annotate intended keyboard navigation on wireframes.

    Resources

    Requirements

    Related toolkit topics

  • Specify the tab order

  • What to do

    The “tab order” is how a user navigates sequentially through the UI when pressing Tab on the keyboard. Typically, the order will follow the reading order, from upper left to lower right. In the wireframe, specify the order in which the user should encounter the interactive components on the page. (Only rarely would non-interactive elements be put in the tab order.) This will let the developer properly code the navigation. A team should use a consistent approach to annotate the wireframes.

    annotations show keyboard navigation should jump from a link to the button next in the content

    Provide consistent annotations to show the tab order between interactive components.

    incorrect annotations shows keyboard navigation stopping at headings, paragraphs, in addition to correctly stopping at links and buttons

    Don’t include non-interactive elements as part of the tab order, such as regular text.

    Resources

    Requirements

    Related toolkit topics

  • Ensure all mouse-operable components are reachable by keyboard

  • What to do

    Any component that can be operated with a mouse should be reachable and operable by keyboard, or have a keyboard equivalent. UX designers should pay particular attention to three common challenges.

    1. Information that is revealed only on mouse hover. The trigger for the mouse hover may not be a traditional interactive component, so may be missing from the tab order.
    2. Interactive content inside the new hover information itself. Such constructs are often unreachable by keyboard. This is covered in Ensure all pointer interactions have keyboard equivalence.
    3. Information icons and other image buttons, which are often injected through CSS and other presentation technologies. They may not appear in the Document Object Model, and so not be automatically incorporated into the tab order.

    Take a moment to scrutinize wireframes for such interactive components or hover triggers, and ensure the wireframes show they are included in the tab order or are actionable by keyboard in another documented way.

    annotations show keyboard navigation stops on a Help icon in addition to link and button

    Annotate all mouse-operable components to ensure they are implemented to support keyboard navigation.

    incorrect annotations do not show keyboard navigation stopping on a Help icon in addition to link and button

    Don’t overlook mouse-operable components (such as the Help icon in this example) when annotating tab order.

    Resources

    Requirements

    Related toolkit topics

  • Reduce tabbing by effective grouping of components

  • What to do

    Web products lack many of the keyboard features a traditional desktop application gets “for free.” As a result, keyboard users are often reduced to repeatedly pressing the Tab key just to begin a task. Designers can lessen this burden by reducing the number of tab stops. This is achieved by grouping components, and then making each grouping a single tab stop, with arrow key movement offered inside the grouped components.

    Many web implementations of rich components, such as tab panels, toolbars, and grids, already incorporate this practice. Other constructions, such as left navigation menus, have the potential to be more efficient, as do newer module patterns such as cards and tiles. Specify in the wireframe the groups of related components, the intended tab stops, and the keys used for interaction between items in the group (usually the arrows). User testing with keyboard-only users can help guide the design.

    arrow keys are notated between individual components, with the group of components notated as 'single tab stop'

    Group components as a single tab stop. The grouped parts can be navigated to by arrow keys.

    Resources

    Requirements

    Related toolkit topics

Level 2

Improve navigation in and around tables

    Use pagination and filters so users can control the amount of data

  • What to do

    Interactive data tables pose usability problems to keyboard users. If each row has a link, the user has to press Tab over two dozen times just to get past a 25-row table. Where a row contains multiple links or inputs such as radio buttons or checkboxes, the keyboard effort multiplies. You can reduce the amount of data displayed at one time and speed up keyboard navigation using the following:

    • pagination: Instead of displaying the entire table with a scrollbar, use pagination to reduce the number of rows shown. Users can bypass irrelevant data more quickly. Notate the pagination widget as a navigation region in the design. If the pagination controls are after the table, provide a shortcut key or other way to reach the controls without navigating through the table. Properly label the pagination controls.
    • filtering: Include a search or filter mechanism so users can review a smaller data set.
    data table with search bar on top and pagination bar on bottom

    Provide pagination and a way to filter through data tables.

    Resources

    Related toolkit topics

  • Design ways to reduce the keyboard effort, including using grids where appropriate

  • What to do

    In addition to providing pagination and filtering, you can improve table navigation for keyboard users in a number of ways.

    • Design tables so that each row contains only one action.
    • Where multiple cells in any given row accept user input, try a grid pattern rather than a data table. Grids give the user more efficient ways to navigate the data.
    • Provide column sorting so users can reposition a row of interest closer to the top for faster interaction.
    • Avoid infinite scrolling. It is very difficult to make accessible.
    data table with a button in each row

    Reduce keyboard navigation by having one action per row, or consider alternatives.

    data table with a text input field and three buttons in each row

    Avoid making keyboard operation impenetrable by forcing users to tab through many cells per row. Consider a grid with arrow navigation.

    Resources

    Related toolkit topics

  • Consider exposing the cell’s header information to assist users with low vision

  • What to do

    When users rely on magnification to read the screen, they quickly lose the ability to view a cell and its row and column headers at the same time. Consider including in the design the ability for the user to hover over cells to see the header information in a tooltip. The developer can implement this feature by programmatically concatenating the headers for each cell using the title attribute (preferred) or a custom tooltip. This enhancement complements a requirement to expose the table headers accessibly.

    cursor hovering over a numeric cell on a magnified data table with tooltip content 'february sales, bowling shoes'

    Provide a way (such as using a tooltip) for users to discover their context when a cell's header information is not in view.

    Resources

    Related toolkit topics

Level 3

Provide multiple ways to reach content

Keep navigation predictable