Powered by
Names, roles & states
A Role Attribute Uses a Value That Doesn't Exist
When `role` is misspelt, made up or abstract, screen readers ignore it — so people can't tell what the element is or how to use it.
aria-rolesWCAG 2.0Introduced in WCAG 2.0.Level AA — the minimum. Missing it blocks people outright.
- Status
- CriticalCritical — Someone can complete the task only with great difficulty or outside help.CurrentScanners run this rule today.
- Owner
- DesignDevTest
- Audit
- Automated+ManualA scanner finds it; a person confirms the fix.
Why it matters
The role attribute tells screen readers what an element is — a button, a tab, a dialog. It only works with exact, real values like button or tablist.
A typo like role="buton" or an invented value like role="card" is ignored. The element is announced as plain text or a generic group, so people don't know they can use it.
Who it affects
| Who | What they experience | Impact |
|---|---|---|
| Screen reader users | They hear plain text, or nothing useful, where there should be a button, tab or menu. | High impact |
| Low-vision users (magnification) | Affected only if they also use a screen reader, as many do. | Partial impact |
| Voice control users | Saying "click button" may not find the control, because it isn't exposed as a button. | Partial impact |
Business & product impact
| Area | Why | Impact |
|---|---|---|
| Legal | It fails WCAG 4.1.2 at Level A, the minimum. Complaints under Australia's Disability Discrimination Act point to WCAG 2.2 AA, and EN 301 549 applies in Europe. | High impact |
| Conversion | If a checkout button or menu isn't announced as one, some customers can't finish and leave. | Moderate impact |
| SEO | No real search benefit — don't sell it as one. | Low impact |
| Brand trust | A control that is silent to a screen reader looks careless to the people who rely on one. | Moderate impact |
| Cost to fix | Usually a one-word fix. Fix it once in the shared component and it's fixed everywhere. | High impact |
Fixing it in code
A misspelt role
Don't
<div role="buton" tabindex="0">Add to cart</div>A screen reader says: “Add to cart”
Do
<button type="button">Add to cart</button>A screen reader says: “Add to cart, button”
A real <button> has the right role built in, with no spelling to get wrong.
An invented or abstract role
Don't
<div role="card">
<h3>Summer sale</h3>
</div>A screen reader says: “Summer sale, heading level 3 (the role is ignored)”
Do
<article>
<h3>Summer sale</h3>
</article>A screen reader says: “Article, Summer sale, heading level 3”
Use a real HTML element or a valid role; made-up and abstract roles like card or widget do nothing.
Designer's handoff note
Name components after real roles in specs — say "tabs" or "dialog", not a brand name — so developers pick a valid role.
For each custom control, write down what the screen reader should say, for example "Add to cart, button".
Quick test
Tool
NVDA (opens in a new tab) (free on Windows)
Checklist
- Pass
- Each control is announced with a real role, like "button", "tab" or "menu".
- Fail
- A control is read as plain text, or with no role at all.
Check these at the same time
- An element has an ARIA role that doesn't suit it
aria-allowed-role
What a green scan still misses
A scanner catches role values that don't exist. It can't tell whether a valid role is the right one for the element — for that, listen and try it.
Reference
- Rule ID
aria-roles- Raised by
- axe-core: “ARIA roles used must conform to valid values”
- WCAG
- 4.1.2 Name, Role, Value (opens in a new tab) · Level A · since WCAG 2.0
- Other standards
- EN 301 549 9.4.1.2 · RGAA 7.1.1
- Last reviewed
- 14 October 2026