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 tabindex values.
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
Tab. - 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.
- Dynamically manage the focus by using JavaScript.
- 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
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.
Focus Management
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 Alt + 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
tabindex. - The
aria-activedescendantattribute.
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 0.
The roving 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
The aria-activedescendant strategy applies the aria-activedescendant attribute to programmatically set the focus to a specific element within a component. You can use JavaScript to dynamically update 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.
The 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.
The 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.
