Managing the Focus in Websites and Apps
Managing the focus of your application or website is an essential aspect of creating an accessible and valuable experience for all users. It is the process of controlling the order in which and the mechanism by which elements on a page receive focus. Focus implementation is of huge importance for the accessibility capabilities of your project as it affects the usability of a page for keyboard users and users with assistive technologies.
In web design, focus is managed through the
tabindex HTML attribute, which specifies the order in which elements receive keyboard focus when the user presses the
Tab key. The focus is then moved from one element to the next in the order specified by the
Common Guidelines for Components
For an accessible user experience, you have to manage the focus in a predictable and consistent manner. Such consistency means that all buttons, links, inputs, and other interactive elements receive focus when they are activated, avoiding unexpected changes of the focus, and providing a clearly visible focus state.
The following list summarizes some best practices and guidelines for managing the focus in web components:
- Ensure that all interactive elements, such as buttons, links, and form controls, receive focus when they are activated either by a mouse click or through a keyboard
- Prevent moving the focus to another element on the page unexpectedly as this can cause confusion for keyboard-only users and may interrupt their workflow.
- Make sure that the navigation order in which interactive items receive keyboard focus is logical and intuitive. Generally, keyboard navigation logic needs to follow the visual horizontal and vertical flow of the page, for example, left to right and top to bottom, header first followed by the main and, then, the page navigation.
- When creating modals or other types of overlays, ensure that the focus is trapped within the overlay so that users don't accidentally interact with the underlying content.
- Guarantee that the focus state is clearly visible so that users can see which element is currently focused.
Number of Tab Stops
According to the number of elements that are part of the page tab sequence, components are split in the following groups:
Non-focusable components cannot receive focus. They neither have elements that belong to the page tab sequence, nor are they focused by any internal component logic. An example of such component is the Notification.
Single Tab Stop Components
A single tab stop component is a user interface element that exposes only a single element in the page tab sequence. This means that when the user presses the
Tab key, the focus moves directly to the next component rather than stopping at multiple points within the component.
In Telerik and Kendo UI, single tab stop components are buttons, checkboxes, radio buttons, comboboxes, and more.
Multiple Tab Stop Components
A multiple tab stop component is a component that contains multiple elements which can receive focus when the user presses the
Tab key. The multiple tab stop approach implements a focus that can be moved between different elements within the component rather than just to and from the component as a whole.
In Telerik and Kendo UI, multiple tab stop components are modal dialogs, accordions, forms, and more.
Depending on the specifics of each component, it may or may not require a dedicated focus management implementation. In Telerik and Kendo UI, components that do not feature managed focus are the buttons, textboxes, and checkboxes.
Other components require more advanced focus management as the focus must be moved around the component elements following a user interaction or a keyboard shortcut. An example of such a component is the ComboBox, which allows the user to move the focus from the input to its popup by pressing the
Down Arrow keys.
To manage the focus within a component, follow either of the following strategies, which are designed to improve the accessibility and usability of components for keyboard users, including users with disabilities:
- The roving
Roving tabindex Strategy
With the roving
tabindex strategy, the component dynamically changes the element that has its
tabindex attribute set. That happens when the users move the focus between different elements within the component through the keyboard or other interaction.
When applying the roving
tabindex strategy, the
tabindex value is set to
-1 for elements within the component which must not receive focus; for elements which must receive focus, the
tabindex value is set to
tabindex strategy is suitable for components in which each element that can receive focus can be the focusable element of the component. An example is the single tab stop ToolBar component—in it, the focusable element on each next
Tab navigation will be the ToolBar button that was last focused.
aria-activedescendant strategy applies the
aria-activedescendant attribute to reflect the current state of the component upon user interaction. For example, when a user opens a drop-down popup, the
aria-activedescendant attribute will be set to point to the currently active (focused) option in the popup.
aria-activedescendant attribute is set on the currently focused element on the page and points to the
id of the element that needs to be interpreted as a currently focused.
aria-activedescendant strategy is suitable for components where the
tabindex cannot be set on the element that needs to be interpreted as focused, for example, the options in a drop-down popup. You can also use this approach to provide additional information about the structure and behavior of the component to assistive technology users.