How to Fix Invalid ARIA Roles on Your Website
A misspelled or made-up ARIA role is silently ignored, leaving screen-reader users without the cues you meant to give them. Here is how to correct them.
Reviewed by Jacob Rhinehart for Strelva's co-founder; products and operations lead responsibilities.
ARIA roles are labels you can add to elements to tell assistive technology what they are, such as a button, a navigation region, or a dialog. They are powerful, but only when valid. A misspelled role like navigtion, or an invented one like container, is simply ignored by screen readers, so the cue you intended to provide never reaches the user.
The usual culprits
- Typos: buton, navigtion, complimentary instead of complementary.
- Made-up roles: container, card, content, which are not real ARIA roles.
- Abstract roles: widget, which exists in the spec but is not meant to be used directly.
Step by step
- Find the invalid roles. Your audit, or a tool like the axe browser extension, lists them.
- Correct the typos. Fix the spelling against the official ARIA role list (MDN keeps the authoritative reference).
- Remove invented roles. A made-up role adds nothing; delete it, or replace it with the correct real role.
- Prefer native elements. Instead of <div role="button">, use an actual <button>. Native elements come with the right role, keyboard behaviour, and focus handling for free.
- Use specific roles, not abstract ones. Replace widget with the precise role the element actually plays.
- Re-test. Run the accessibility checker again to confirm no invalid roles remain.
The golden rule
The best ARIA is often no ARIA. If a native HTML element does the job, use it; reach for a role only when you are building something HTML has no element for. Fewer custom roles means fewer chances to get them wrong.
Frequently asked
What business owners ask next.
What makes an ARIA role 'invalid'?
Either it is misspelled (like 'navigtion'), it is not a real role at all (like 'container' or 'card'), or it is an abstract role not meant for direct use (like 'widget'). Screen readers ignore any of these.
Should I use div-plus-role or a native element?
Prefer the native element. A real button or nav brings the correct role, keyboard support, and focus behaviour automatically. Recreating that with a div and a role is more work and more error-prone.
I added an aria-label but the audit still flags the role. Why?
An aria-label does not fix an invalid role; they are separate things. Correct or remove the invalid role first, then the label will work as intended on a valid element.