User experience design - Navigation

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.

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.

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.

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.

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.

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:

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

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.

Refer to resources and requirements listed below.

Refer to resources and requirements listed below.

Refer to resources and requirements listed below.

Refer to resources and requirements listed below.