Aria roles

What it is

ARIA roles are special HTML attributes (e.g., `role="button"`) that tell screen readers and other assistive technologies what an element *is* and how it should behave. The WAI-ARIA specification defines a strict list of allowed role values — words like `button`, `navigation`, `dialog`, `alert`, `banner`, etc. An invalid ARIA role means you've used a value that doesn't exist in that list (for example, a typo like `role="navagation"`, an invented word like `role="card"`, or an outdated value). When a role is invalid, assistive technology simply ignores it, stripping away the accessibility context you intended to provide. WCAG Success Criterion 4.1.2 (Name, Role, Value) requires that all user interface components have roles that can be understood by assistive technology.

Why it matters

Screen reader users — who are often customers with visual impairments — rely entirely on ARIA roles to understand your page's structure and interactive elements. An invalid role means a screen reader may announce an element incorrectly (e.g., as plain text instead of a button), or skip it entirely, making menus, modals, forms, and key navigation landmarks unusable. This creates a direct barrier for disabled shoppers, exposes your store to legal risk under laws like the ADA (US), AODA (Canada), EAA (EU), and UK Equality Act, and can result in costly litigation or regulatory complaints. Google also uses accessibility signals as part of its quality assessments, so pages with broken ARIA markup can underperform in organic search compared to well-structured competitors.

How to fix it

1. Open your browser's developer tools (F12) on the affected page, go to the Elements/Inspector panel, and search the HTML source for the string `role=` to find every element using an ARIA role attribute.
2. For each `role` value found, verify it against the official WAI-ARIA roles list (landmark roles: `banner`, `navigation`, `main`, `region`, `complementary`, `contentinfo`, `search`, `form`; widget roles: `button`, `checkbox`, `dialog`, `alert`, `listbox`, `menu`, `menuitem`, `tab`, `tabpanel`, `tooltip`, `link`, `switch`, etc.).
3. Correct any invalid values: fix typos (e.g., `navagation` → `navigation`), remove invented/unsupported role names (e.g., `role="card"` — use a valid structural role or remove entirely), and replace deprecated roles with their current equivalents.
4. If the element already has a native HTML equivalent (e.g., `<button>`, `<nav>`, `<main>`, `<header>`), the best fix is often to remove the `role` attribute entirely and use the correct semantic HTML element instead, since native elements have built-in, implicit roles.
5. After saving changes, re-run an accessibility audit using a browser extension like axe DevTools or WAVE to confirm the `aria-roles` violation no longer appears.
6. Test the fixed page with an actual screen reader (NVDA + Firefox on Windows, or VoiceOver + Safari on Mac/iOS) to confirm the element is announced correctly.

<!-- ❌ INVALID — role value does not exist in WAI-ARIA spec -->
<div role="card">Featured Product</div>
<nav role="navagation">...</nav>
<div role="flyout">...</div>

<!-- ✅ VALID — use correct WAI-ARIA role or native HTML element -->
<div role="region" aria-label="Featured Product">Featured Product</div>
<nav>...</nav>  <!-- <nav> has implicit role="navigation" — no role attr needed -->
<div role="dialog" aria-modal="true" aria-label="Quick view">...</div>

Fix it on your platform

Pick your platform for the exact steps.

Frequently asked questions

Authoritative references

• How to fix this specific rule — Deque/axe (rule reference)
• WCAG 2 overview — W3C WAI
• ARIA basics — MDN