## 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