Toolbar: Toolbar is missing appropriate role and/or attributes

Rule

The name, role, value, states, and properties of user interface components MUST be programmatically determinable by assistive technologies.

Background

Every user interface control must have a role along with any applicable states and properties so that screen reader users know how to interact with the control. Native HTML elements - such as <button>, <a>, <input>, <select> - already have a role, and their necessary states and properties - such as the checked/unchecked state of a checkbox - are automatically conveyed so nothing more needs to be done. If you create a custom version of a native HTML element or a custom control or widget that does not have a native HTML equivalent, you must add the relevant role(s) and any applicable states and properties using ARIA as well as expected keyboard interactions.

How to Fix

A toolbar is a container for grouping a set of controls, such as buttons, menubuttons, or checkboxes. When a set of controls is visually presented as a group, the toolbar role can be used to communicate the presence and purpose of the grouping to screen reader users. Grouping controls into toolbars can also be an effective way of reducing the number of tab stops in the keyboard interface.

Fix this issue by using the following roles and attributes:

1. The element that serves as the toolbar container has role toolbar.
2. If the toolbar has a visible label, it is referenced by aria-labelledby on the toolbar element. Otherwise, the toolbar element has a label provided by aria-label.
3. If the controls are arranged vertically, the toolbar element has aria-orientation set to vertical. The default orientation is horizontal.

View the full ARIA design pattern including expected keyboard interaction and examples: https://www.w3.org/WAI/ARIA/apg/patterns/toolbar/