org.sonar.l10n.web.rules.Web.S6843.html Maven / Gradle / Ivy
Why is this an issue?
Interactive DOM elements are elements that users can interact with. These include buttons, links, form inputs, and other elements that can be
clicked, focused, or otherwise manipulated by the user. ARIA roles, on the other hand, are used to improve accessibility by providing additional
semantic information about an element’s purpose and behavior. ARIA roles can be divided into two categories: interactive roles and non-interactive
roles.
Interactive ARIA roles are used for elements that a user can interact with, such as buttons or sliders. Non-interactive ARIA roles are used for
elements that are not meant to be interacted with, such as content containers or landmarks. Examples of non-interactive ARIA roles include
article, banner, complementary, contentinfo, definition, directory,
document, feed, figure, group, heading, img, list,
listitem, math, none, note, presentation, region,
separator, status, term, and tooltip.
Interactive DOM elements should not have non-interactive ARIA roles because it can confuse assistive technologies and their users. For example, if
a button (an interactive element) is given a non-interactive ARIA role like article, it can mislead users into thinking that the button
is just a piece of content, not something they can interact with. This can lead to a poor user experience, especially for users who rely on assistive
technologies to navigate the web.
Therefore, it’s important to ensure that interactive DOM elements are not given non-interactive ARIA roles.
How to fix it
Ensure that interactive DOM elements are not given non-interactive ARIA roles.
Code examples
Noncompliant code example
<button role="article">Click me!</button> <!-- Noncompliant; "button" is interactive, but "article" isn't -->
Compliant solution
<button role="button">Click me!</button>
Resources
Documentation
- WCAG - Name, Role, Value
- WCAG - WAI-ARIA Roles
- MDN web docs - WAI-ARIA Roles