User experience design - Navigation
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
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.
Annotate intended keyboard navigation on wireframes.
Resources
- Annotating wireframes and UX designs, BBC
- What are wireframe annotations and why use them?, Balsamiq wireframing academy
Requirements
- 2.1.1 Keyboard, IBM accessibility requirements
Related toolkit topics
- Specify the tab order, this section
- Reduce tabbing by effective grouping of components, this section
- Improve navigation in and around tables, this page
- Follow established keyboard conventions, UX - Keyboard
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.
Provide consistent annotations to show the tab order between interactive components.
Don’t include non-interactive elements as part of the tab order, such as regular text.
Resources
- Annotating wireframes and UX designs, BBC
- How do you present tabbing order, StackExchange
Requirements
- 2.1.1 Keyboard, IBM accessibility requirements
- 2.4.3 Focus Order, IBM accessibility requirements
Related toolkit topics
- Set expectations and note intended keyboard operation in wireframes, this section
- Reduce tabbing by effective grouping of components, this section
- Improve navigation in and around tables, this page
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.
- 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.
- 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.
- 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.
Annotate all mouse-operable components to ensure they are implemented to support keyboard navigation.
Don’t overlook mouse-operable components (such as the Help icon in this example) when annotating tab order.
Resources
- Keyboard compatibility, W3C web accessibility perspectives
- Keyboard-only navigation for improved accessibility, Nielsen Norman Group
- DOM order matters, Google
Requirements
- 2.1.1 Keyboard, IBM accessibility requirements
- 2.4.3 Focus Order, IBM accessibility requirements
Related toolkit topics
- Note intended keyboard navigation in wireframes, this section
- Reduce tabbing by effective grouping of components, this section
- Ensure all pointer interactions have keyboard equivalence, UX - Keyboard
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.
Group components as a single tab stop. The grouped parts can be navigated to by arrow keys.
Resources
- Toolbar, ARIA authoring practices
- Grids: Interactive tabular data and layout containers, ARIA authoring practices
Requirements
- 2.1.1 Keyboard, IBM accessibility requirements
- 2.4.3 Focus Order, IBM accessibility requirements
Related toolkit topics
- Note intended keyboard navigation in wireframes, this section
- Specify the tab order, this section
- Improve navigation in and around tables, this page
Note intended keyboard navigation in wireframes
Specify the tab order
Ensure all mouse-operable components are reachable by keyboard
Reduce tabbing by effective grouping of components
Level 2
Improve navigation in and around tables
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.
Provide pagination and a way to filter through data tables.
Resources
- Pagination usage, Carbon design system
- Filtering, Carbon design system
- Pagination navigation, A11Y style guide
- Accessible pagination, a11ymatters
Related toolkit topics
- Design for keyboard navigation, this page
- Follow established keyboard conventions, UX - keyboard
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.
Reduce keyboard navigation by having one action per row, or consider alternatives.
Avoid making keyboard operation impenetrable by forcing users to tab through many cells per row. Consider a grid with arrow navigation.
Resources
- Grids: Interactive tabular data and layout containers, ARIA authoring practices
- Infinite scroll & accessibility! Is it any good?, Digital a11y
Related toolkit topics
- Design for keyboard navigation, this page
- Follow established keyboard conventions, this page
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.
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
- ARIA9: Using aria-labelledby to concatenate a label from several text nodes, WCAG 2.1 technique
- H65: Using the title attribute to identify form controls when the label element cannot be used, WCAG 2.1 technique
Related toolkit topics
- Flag table headers, Content design – Text meaning
- Understand the requirements for dismissing content that appears on hover, UX - Pointer
Use pagination and filters so users can control the amount of data
Design ways to reduce the keyboard effort, including using grids where appropriate
Consider exposing the cell’s header information to assist users with low vision
Level 3
Provide multiple ways to reach content
What to do
Refer to resources and requirements listed below.
Resources
- G1: Adding a link at the top of each page that goes directly to the main content area, WCAG 2.1 technique
- G123: Adding a link at the beginning of a block of repeated content to go to the end of the block, WCAG 2.1 technique
- G124: Adding links at the top of the page to each area of the content, WCAG 2.1 technique
Requirements
- 2.4.1 Bypass Blocks, IBM accessibility requirements
What to do
Refer to resources and requirements listed below.
Resources
- G64: Providing a Table of Contents, WCAG 2.1 technique
- G63: Providing a site map, WCAG 2.1 technique
Requirements
- 2.4.5 Multiple Ways, IBM accessibility requirements
What to do
Refer to resources and requirements listed below.
Resources
- G125: Providing links to navigate to related Web pages, WCAG 2.1 technique
- G126: Providing a list of links to all other Web pages, WCAG 2.1 technique
- G161: Providing a search function to help users find content, WCAG 2.1 technique
- G185: Linking to all of the pages on the site from the home page, WCAG 2.1 technique
Requirements
- 2.4.5 Multiple Ways, IBM accessibility requirements
Consider links and other mechanisms to bypass blocks of content
Use tables of content and site maps, where appropriate
Provide a search function or other features to improve navigation and findability
Keep navigation predictable
What to do
Refer to resources and requirements listed below.
Resources
- G61: Presenting repeated components in the same relative order each time they appear, WCAG 2.1 technique
Requirements
- 3.2.3 Consistent Navigation, IBM accessibility requirements