Elements in the focus order need a role appropriate for interactive content
Accessibility testing for dev teams - No experience required
Compliance Data & Impact
Disabilities Affected
- Blind
- Deafblind
- Mobility
Standard(s)
- WCAG 2.1 Experimental
How to Fix the Problem
Ensure all elements in the focus order have an appropriate
role attribute value, and if the element is a custom widget, that
correspond to valid ARIA role attribute values are applied.
Ensure all device-independent user input methods have appropriate roles to enable interaction with form content.
When no role exists at all, when focusing on the element, the screen reader will not announce anything.
When an inappropriate role like paragraph is used for an interactive element, the element will not receive focus, and the screen reader will not announce anything.
If the role matches a list of roles that could be an interactive element (for
example, button, text input, radio option, checkbox, etc.), if native HTML, no
extra roles are required, but if it is a custom widget you need an aria role
that makes sense, such as role="button".
If a screen reader user lands on the element and it has text, it will read the text, but the user will not know what the element is without an appropriate role.
Available roles by type are:
- Landmark: article, banner, complementary, main, navigation, region, search, contentinfo
- Widget: alert, alertdialog, application, dialog, group, log, marquee, menu, menubar, menuitem, menuitemcheckbox, menuitemradio, progressbar, separator, slider, spinbutton, status, tab, tablist, tabpanel, timer, toolbar, tooltip, tree, treegrid, treeitem
- Pseudo HTML: button, button, checkbox, columnheader, combobox, contentinfo, form, grid, gridcell, heading, img, link, listbox, listitem, option, radio, radiogroup, row, rowgroup, rowheader, scrollbar, textbox, checkbox, columnheader, combobox, contentinfo, form, grid, gridcell, heading, img, link, listbox, listitem, option, radio, radiogroup, row, rowgroup, rowheader, scrollbar, textbox
- Document: document (when creating a document region inside an other type of region)
- Application: application (only around a widget to enable normal keyboard shortcuts for page content)
- Presentation: presentation (to cancel the native role of the element)
- Other Semantic: math, definition, note, directory
- Abstract: command, composite, input, landmark, range, section, sectionhead, select, structure, widget
Why it Matters
Elements in the focus order need a role appropriate for interactive content so that screen reader technology can communicate that information to users.
If interactive content elements do not have appropriate roles, the role will not be able to perform the accessibility function intended by the developer.
When screen readers and other assistive technologies do not know the appropriate role of each element on the web page, they are not able to interact with it intelligently, nor are they able to communicate the role to the user. When the value for a role is not valid, there is no way the HTML element's set of features, properties, and methods of conveying information to and/or from the user can be communicated via assistive technologies.
Rule Description
User input elements must have appropriate roles, whether native HTML or a
custom widget, to convey to screen reader users their meaning when landed on
and given focus. If a custom widget, appropriate ARIA role values
must be used instead of abstract roles to correctly expose the purpose of the
element.
The Algorithm (in simple terms)
Checks all interactive elements in the focus order to ensure that the role attribute value is valid and appropriate, whether native HTML or a custom ARIA widget.
Resources
Refer to the complete list of axe 4.4 rules.
Was this information helpful?
Your response was as follows:
Date/Time feedback was submitted: