Why is this an issue?

Non-interactive DOM elements should usually not be given interactive ARIA roles. Doing so changes how assistive technologies announce the element without giving it the native behavior users expect.

For example, <div role="button"> is announced as a button, but it does not automatically get the keyboard support, focus behavior, or activation semantics of a real <button>. This mismatch can confuse users and make the page less accessible.

In most cases, prefer native interactive elements instead of assigning interactive roles to non-interactive markup.

Exceptions

According to the ARIA in HTML conformance table, some HTML elements may use specific ARIA roles without violating the HTML specification. Here are some examples:

For some elements, such as <table>, the specification allows a broader set of roles than the examples above. See the ARIA in HTML conformance table for the full list.

How to fix it

Use a native interactive element whenever possible. For example, replace <li role="button"> with a real <button> when the content is meant to behave like a button.

Keep an interactive ARIA role on a non-interactive element only when the ARIA in HTML specification explicitly allows that composite-widget pairing, such as <fieldset role="radiogroup"> or <ul role="tablist">.

Code examples

Noncompliant code example

function myListElement() {
    return <li role="button">Foo</li>; // Noncompliant; "li" isn't interactive, but "button" is
}

Compliant solution

function myListElement() {
    return <button type="button">Foo</button>;
}

Resources

Documentation