ARIA role should be appropriate for the element

HTML elements come with built-in semantics — a <button> is inherently a button, a <ul> is inherently a list, and so on. When you assign a WAI-ARIA role to an element, you’re overriding those built-in semantics and telling assistive technologies to treat the element differently. However, not all overrides make sense. Some combinations conflict with the element’s native behavior, its expected interaction patterns, or the browser’s internal handling of the element. For example, assigning role="button" to a <ul> element creates a contradiction: the browser still treats it as a list structurally, but screen readers announce it as a button, resulting in confusing and unpredictable behavior.

This issue primarily affects users who rely on screen readers and other assistive technologies. These tools depend on accurate role information to communicate what an element is, how it behaves, and how to interact with it. When role assignments conflict with the underlying HTML element, screen readers may announce the wrong type of control, skip content entirely, or present a user interface that doesn’t match what sighted users see. Users who are blind, deafblind, or who use assistive technologies for mobility impairments are all affected.

While this rule is classified as a Deque best practice rather than a direct WCAG failure, it aligns with the principles behind WCAG 4.1.2 Name, Role, Value, which requires that user interface components expose their role correctly to assistive technologies. Mismatched roles undermine this requirement. At best, an invalid element-role combination has no effect; at worst, it can disable accessibility for entire sections of a page.

How to Fix

1. Check the ARIA in HTML specification. The ARIA in HTML spec defines which role values are allowed for each HTML element. Before assigning a role, verify that the combination is permitted.
2. Use the right element for the job. Often, the best fix is to use a native HTML element that already has the semantics you need, rather than overriding a different element with a role. For example, use a <button> for button behavior instead of adding role="button" to a <div>.
3. Restructure when necessary. If you need a specific role, find an element that is allowed to carry it. This might mean changing your markup structure slightly.
4. Don’t use abstract roles. Roles like widget, landmark, roletype, structure, and command are abstract and must never be used directly in content. They exist only as conceptual categories in the ARIA taxonomy.

Examples

Incorrect: Role not appropriate for the element

A <ul> element assigned role="button" — lists cannot be buttons:

<ul role="button">Name</ul>

A <button> element assigned role="heading" — buttons should not be headings:

<button role="heading" aria-level="2">Welcome</button>

In both cases, the assigned role conflicts with the element’s native semantics and expected behavior, causing assistive technologies to report inaccurate information.

Correct: Role appropriate for the element

A <ul> element assigned role="menu" — this is an allowed role for <ul>, and the child elements use compatible roles:

<ul role="menu">
  <li role="none">
    <button role="menuitem">Start</button>
  </li>
  <li role="none">
    <button role="menuitem">Stop</button>
  </li>
</ul>

Here, role="menu" is a permitted override for <ul>, role="none" removes the <li> list-item semantics (which aren’t meaningful in a menu context), and role="menuitem" is allowed on <button> elements.

Correct: Using native HTML elements instead of role overrides

Rather than forcing mismatched roles, use elements that already have the semantics you need:

<button type="button">Name</button>

<h2>Welcome</h2>

Native HTML elements provide built-in keyboard support, focus management, and correct semantics without any ARIA needed. This is almost always the simplest and most robust approach.

Learn more:

Deque Reference

Deque University - How To Fix

→