Names, roles & states
An Element Has an ARIA Role That Doesn't Suit It
A role that clashes with the element can hide what it really is. Screen reader users then hear the wrong thing, or miss something important.
aria-allowed-roleBest practiceBest practice — not a WCAG requirement, but it helps people all the same.
- Status
- MinorMinor — Cosmetic, or best practice.CurrentScanners run this rule today.
- Owner
- DesignDevTest
- Audit
- Automated+ManualA scanner finds it; a person confirms the fix.
Why it matters
A role tells screen readers what an element is, such as a button, a heading or a list. Each HTML element only suits certain roles.
A role that doesn't suit the element replaces its real meaning. A heading can stop being a heading. A list can stop being a list. It can also promise a control that doesn't work like one.
Who it affects
| Who | What they experience | Impact |
|---|---|---|
| Screen reader users | They hear "button" where there should be a heading, or lose the list and its item count. | High impact |
| Low-vision users (magnification) | Affected only if they also use a screen reader, as many do. | Partial impact |
| Keyboard-only users | If a heading or list item is made a "button" by role alone, Tab often can't reach it. | Partial impact |
| Cognitive and neurodivergent users | When the voice says one thing and the screen shows another, it's confusing. | Partial impact |
| Voice control users | Saying "click button" may target something that doesn't respond like a button. | Partial impact |
Business & product impact
| Area | Why | Impact |
|---|---|---|
| Legal | This is a best practice, not a WCAG 2.2 requirement on its own. But the harm it causes can fail WCAG checks under Australia's Disability Discrimination Act. | Moderate impact |
| Conversion | A broken "Show details" or menu can stop people finding prices, sizes or checkout. | Moderate impact |
| SEO | Search engines barely notice ARIA roles. Don't sell it as an SEO fix. | Low impact |
| Brand trust | Odd announcements signal that a site wasn't built with care. | Low impact |
| Cost to fix | Usually a small change in a shared component. Fixing it there fixes every page. | High impact |
Fixing it in code
A heading that opens more content
Don't
<h2 role="button" onclick="toggle()">Show details</h2>A screen reader says: “Show details, button (and Tab can't reach it)”
Do
<h2><button aria-expanded="false" onclick="toggle()">Show details</button></h2>A screen reader says: “Show details, button, collapsed, heading level 2”
A real button inside the heading keeps both meanings and works with the keyboard.
A main menu built from a list
Don't
<ul role="navigation">
<li><a href="/">Home</a></li>
<li><a href="/shop">Shop</a></li>
</ul>A screen reader says: “Navigation, Home, link (no list or item count)”
Do
<nav aria-label="Main">
<ul>
<li><a href="/">Home</a></li>
<li><a href="/shop">Shop</a></li>
</ul>
</nav>A screen reader says: “Main, navigation, list, 2 items, Home, link”
Wrap the list in nav instead of changing the list's role.
Designer's handoff note
Label each interactive part in your designs as what it is — button, link, heading or list. Developers can then pick the right HTML element, not patch it with a role.
Quick test
Tool
NVDA (opens in a new tab) (free, Windows) or VoiceOver (opens in a new tab) (Mac)
Checklist
- Pass
- Each part is announced as what it looks like and does, and Tab reaches every control.
- Fail
- A heading is called a button, a list loses its item count, or a control can't be reached by Tab.
Check these at the same time
- An ARIA attribute is used where it isn't allowed
aria-allowed-attr
What a green scan still misses
A scanner flags a role that doesn't suit the element. It can't tell whether your fix is the right element, or whether it works with the keyboard.
Reference
- Rule ID
aria-allowed-role- Raised by
- axe-core: “ARIA role should be appropriate for the element”
- WCAG
- Best practice — not a WCAG requirement
- Last reviewed
- 14 October 2026