It is completed in Mar 2021. I was assigned the task to create keyboard navigation rules for all Interact products.
Background
It is first initiated by the designer from Interact City. Because users would like to control the tables by keyboard in the product. In Interact City, users could manage millions of streetlights in a table. It is critical that they could do it by a keyboard.
The designer reached the design system team, asking whether we have had guidelines to follow. As a member of the design system team, I took over the task.
Desk research and interview
I did 3 things during the research phase.
- I navigated the famous websites in different industries via a keyboard, observing how the keyboard behavior was settled.
- Keyboard navigation is also part of the accessibility topic. I checked the relevant articles and principles from W3C school.
- I interviewed the people around who are big fans of keyboard navigation. A few developers are among them. After the guidelines were created, I also got feedbacks from them.
The scope and architecture of the document were also defined afterward. To be clarified, keyboard shortcut is not within this topic, and below is the final document.
Summary
There are 3 parts.
- Reachable, operable and visible elements: component level details
- Rules and best practices: organism level (components combinations), and page level examples from current Interact products
- Skip to main content, accessibility guide and feedback: general points in keyboard navigation
Below is the spec.
Keyboard navigation
This page defines detailed keyboard navigation behavior in Interact products.
Keep in mind that many users aren’t able to use a mouse for different reasons. Therefore, at least, it should be possible to reach all functionalities with a standard keyboard.
Reachable, operable, and visible elements
Reachable
Make sure all interactive elements, and if needed, static elements are reachable through a keyboard.
- Most of the interactive elements are atoms and organisms, for instance, tabs, buttons, input fields, drop downs, or cards, widgets, expanders, menu items, interactive table rows, etc. Besides, the elements that are also focusable are links, the use of features like drag and drop, selecting text, etc.
- Static elements are set to be focusable based on scenarios. It could be static table rows or cards, etc.
Operable
1. The focus order is sequential and meaningful, even if this is different from the order in which the content is encoded in the underlying source file.
- Ensure that users can navigate through content in a logical order, which is also the visual order on the screen. It should be consistent with the meaning of the content.
- For the navigation item order, heading tags should be used properly and in the correct order, including those in titles and breadcrumbs.
2. When a keyboard is used for navigation, the function of the focussed item should be inherited, but the behavior would be different depending on the elements/atoms. For example,
- The search drop down list opens for the recent/popular searched items in the meantime when search input field is focussed, but if it is a search icon (as a quiet icon button) on the UI, then the search input field is going to be triggered when user clicks enter.
- The page refreshes when user clicks the selected tab. So when user focuses on a selected tab and clicks enter, the page is also going to refresh.
If user would like to go to another tab, he/she has to focus on that tab and click enter.
- If user focuses on a dropdown, the dropdown list would open through the enter.
Visible
Use correct focus states in the Interact library.
- Each interactive atom has a focus state in the library, regardless light or dark theme, make sure that it is applied right on the UI. Because for people navigating an app through keyboard, focus state is how they know their location on the page.
- In case there are interactive elements on the UI that are not predefined components in the library, take style guide as a reference and provide a valid focus state to it.
Rules and best practices
Tab, shift, enter, esc, and arrow keys are the main keys involved in keyboard navigation.
Why is the approach taken for Interact products?
1. It is also a standard way in the industry, though there are differences between products.
2. There are massive complex tables in Interact products.
- Tables could be with tens of rows plus pagination.
- Tables rows could be with all kinds of actions.
Therefore, it would be good to provide a way for the user to traverse between basic blocks considering the efficiency. He/She doesn’t have to go through all the details in a table if the item is not what he/she wants, or he/she just wants to go to the next page button.
3. There are massive complex list views/tree structures in Interact products. Some of them could be skipped by the skip to main content link, some can’t due to their location, for example in a dialog. Therefore, it would be good to provide a way for the user to skip the list items considering the efficiency.
4. It might feel a bit strange the first time you traverse within the nonmodals, but soon you will get used to it. Usually, nonmodals are item lists. Therefore, it won’t be harmful for the user if he/she exits through tab by accident. Still, it has the benefit that for the nonmodals, it is easier to exit, compare to just using the esc only.
General rules
Rule 1: Use arrow keys to traverse sub-controls, like items in a dropdown list, in an action list, in a toolbar, in a list view, navigation items, tabs, breadcrumbs, etc.
- Depending on the complexity of the cases, designers could decide to use up and down keys only, or left and right keys only, or use both of them on their own.
- Also, depending on the particular case, designers could decide to reserve arrow keys for scrolling.
Rule 2: Use tab key to traverse the others.
- Use tab key to move to next focussed elements and shift+tab key to go back to the previous focussed elements.
- It is recommended to use tab key for cards and graphs because they are too complicated with variant layouts and content.
Rule 3: Use enter to trigger the subset of the content, toggle buttons, radio buttons, and checkboxes.
Rule 4: Make sure the focus state always loops in all kinds of cases.
Rule 5: The first focusable item is always the URL of the page and the second is the skip to main content link.
Consider to use both tab key and arrow keys to traverse some of the reachable elements based on scenarios.
Design system team
It is recommended to follow the rules strictly in navigations (top nav, side panel, 3rd nav, etc), subset of the content and tables unless there are strong reasons, so that we could achieve a bit of consistency cross Interact products.
Design system team
Best practices
Subset of content – Modals
Common modals are dialogs.
Modals are open through enter, close through esc. Esc means cancel, exit without saving. Make sure users can exit the modal through esc, won’t get trapped in modals.
Use tab key to traverse within a modal.
- When a modal is open, only the reachable elements within it can be navigated. The focus state are looping in the modal until user clicks esc to escape.
- When a modal is closed, reachable elements in the background can be navigated again and follow the order before user opens the modal.
- When the preferred/main action button of the dialog is enabled, make sure it is focussed prior, comparing to the neutral actions.
In this case, if the apply button is enabled, it would be focussed as No.4 item and cancel would be No.5.
In this case, the expand/collapse action is triggered through enter.
In this case, the keyboard behavior of the table follows all the rules for a table though it is in a dialog.
Subset of content – Nonmodals
Common nonmodals include dropdown lists, tooltips, action lists, temporary snack bars, and other popups which display on hover and focus, etc.
1. Nonmodals are open through enter, close through esc or tab. The differences between using esc and tab is
- If user clicks esc to escape, the nonmodal would be closed and the focus state is going to stay on the current reachable item on the page.
- If user clicks tab to escape, the nonmodal would be closed automatically with the focus state moving to the next reachable element on the page.
2. Use arrow keys to traverse within a non-modal, no matter how many sub-menus are.
- When a nonmodal is open, only the reachable elements within it can be navigated. The focus state are looping in the nonmodal until user escapes.
- When a nonmodal is closed, reachable elements in the background can be navigated again and follow the order before user opens the nonmodal.
3. Loop until user selects something or exit via esc or tab.
In this case, loop in the dropdown list with up and down arrow keys until user clicks enter to select something or clicks esc or tab to escape.
In this case, the tooltip is displayed when user hovers on the info icon. Therefore, the info icon should be focusable and once it is focused, the tooltip shows at the same time. When user moves to the next reachable element, the tooltip disappears.
Snack bar is an exception. Links and buttons in a snack bar, especially in a sticky snack bar, should have higher priority to be focused on the UI.
In this case, the link in the snack bar is the No.5 focused element on the UI, prior to any other reachable elements.
Tree structures are widely used in the navigation system. They can be on a page/panel, in the subset of the content as modals or nonmodals, etc.
Because they are in a clear structure. It is also recommended to use arrow keys to traverse within sub-items.
It is also recommended to use enter to trigger the expansion/collapse, following the same rule for action buttons.
In the tree structure of a streetlight, up and down keys provide a way to quickly switch between list items and users could traverse all the interactive elements in the tree structure by left and right arrow keys.
Use up and down keys to traverse table rows.
Use left and right keys to traverse detailed items, which means user could traverse all the reachable elements through the left and right keys.
In this case, the whole table row is actionable. Use up and down arrow keys to switch between rows and use left and right keys for sub-controls.
When the focus state stays on the last item of the row, the ellipse action icon in the case, and user clicks the right key again, the focus state is going to move to the next table row.
In this case, users are able to customize the properties. There could be tens of property values. Therefore, it would be good to allow users to traverse different table rows via up and down arrow keys to clearly see the info row by row, though the rows are static.
Edit mode:
- Since user uses tab to traverse in modals. When the page goes to edit mode, it could be seen as a big embedded “modal”. As a consequence, the tab behavior is kept.
- Also, another reason is based on the hypothesis that users would like to edit the values in the columns in this condition. So it also makes sense to use the tab to traverse all the details.
The two reasons should be considered in all the edit modes, not just for tables.
Then when the table is in edit mode and we switch from arrow key to tab key, it might be confusing for the users. Therefore, both ways are provided in this scenario.
In an editable table, users can still use up and down arrow keys to quickly navigate to the row they want, though the rows themselves are not actionable, and use left and right to switch between the actionable components in the rows like what the tab does.
In this case, the table rows are static. But the table could be very long and complex with many properties and other types of values. Therefore, we keep the focus state for the rows even they are not actionable so that user could quickly switch between different rows before jumping to specific items.
Cards are variable in layout, size, and content. It is recommended to use tab to traverse reachable elements in cards.
It is recommended to still provide a way to allow users to traverse between cards.
Graphs
Also, graphs can be variant in type, layout, and content. It is recommended to use tab to traverse reachable elements in graphs.
Date picker: Once user clicks enter, the date picker opens and the first interactive elements in it is focused automatically. Still, rules are kept that only arrows keys are used in the nonmodals.
User traverses between date rows through up and down keys though the row itself is static. Left and right keys are used to switch between dates regardless rows.
Use enter key to select dates.
Calendar views: It is recommended to use tab to traverse reachable elements in calendar views on the page.
Make sure that at least all map controls are reachable via tab. (More details are out of scope.)
In this case, at least make sure that all the controls on the map can be focused. After the last reachable item on the panel is focused, show labels will be focused through tab.
Skip to main content, accessibility guide and feedback
They all only appear when user is using the keyboard to navigate. They are focused after the page URL and before the first reachable element.
Skip to main content
It is especially important for pages that have large, multi-layered navigation menus.
- It is required. A link should be provided for users to skip to the page’s main content, bypass repeated blocks of content, such as the navigation.
- It appears as the second focusable item and only shows up when user starts to use keyboard to navigate. The link itself does not need to be visible when out of focus.
Accessibility guide and feedback (optional)
Both of them are optional.
They appear after skip to main content and only show up when user starts to use keyboard to navigate. The links themselves does not need to be visible when out of focus.
It should be part of the user guide. But there is entry point within keyboard navigation.
The possible content includes overall function explanation of the accessibility in the product, explanation of the accessibility links, like skip to main content, accessibility guide, accessibility feedback, info hierarchies in keyboard navigation, platform differences if there is any, etc. (More details are out of scope.)
It could be part of the feedback/customer support system. But there is entry point within keyboard navigation.
The possible content includes input field to collect the accessibility issues, or contact info, like mail, phone number, etc. (More details are out of scope.)
References
- The accessibility cheatsheet
- Guideline 2.1 – Keyboard accessible
- Ensuring that users are not trapped in content
- Ensuring correct tab and reading order in PDF documents
- Placing the interactive elements in an order that follows sequences and relationships within the content
- Ordering the content in a meaningful sequence
- Ensuring keyboard control for all functionality
- Adding keyboard-accessible actions to static HTML elements
- Understanding Success Criterion 1.4.13: Content on Hover or Focus
- Making the DOM order match the visual order
Wenlan’s portfolio site 