ARIA Violations
What are ARIA violations and how do they break assistive technology?
What is aria violations?
ARIA (Accessible Rich Internet Applications) attributes provide extra semantic information to assistive technologies when native HTML elements are insufficient. ARIA violations occur when these attributes are used incorrectly — for example, applying an invalid role, using aria-labelledby to reference a non-existent ID, or adding redundant ARIA roles to elements that already have implicit semantics.
ARIA violations occur when Accessible Rich Internet Applications attributes are used incorrectly, such as applying invalid roles, referencing non-existent IDs, or adding redundant semantics. Incorrect ARIA is often worse than no ARIA because screen readers trust these attributes to describe element behavior accurately.
Why does aria violations matter?
Incorrect ARIA is often worse than no ARIA at all. A screen reader trusts ARIA attributes to accurately describe what an element is and what state it is in. When ARIA lies — for example, marking a div as role="button" without adding keyboard handlers — the screen reader announces it as a button, but it does not behave like one. This mismatch creates a confusing and broken experience for assistive technology users.
Pages using ARIA averaged 41% more detectable accessibility errors than pages without ARIA, demonstrating the harm of incorrect usage.
How to fix it
- Follow the first rule of ARIA: if you can use a native HTML element with the semantics you need (<button>, <nav>, <dialog>), use it instead of adding ARIA roles to a generic element.
- Validate that every aria-labelledby and aria-describedby value references an ID that actually exists in the DOM.
- Ensure ARIA roles match the element's actual behavior. If you use role="button", the element must be focusable and respond to Enter and Space key presses.
- Run an automated accessibility scanner (like axe-core) to catch common ARIA misuse patterns, then manually verify the flagged issues.
- Keep ARIA attributes up to date with dynamic state changes — for example, toggle aria-expanded="true"/"false" when an accordion opens or closes.
Bad seed, good seed.
<div role="button" onclick="submitForm()">
Submit
</div>
<!-- Not focusable, no keyboard handler, screen reader says "button" but Tab skips it --><button type="submit" onclick="submitForm()">
Submit
</button>
<!-- Native button: focusable, keyboard-operable, correct semantics automatically -->Frequently asked questions
When should I use ARIA attributes?
Use ARIA only when native HTML elements cannot provide the semantics you need — for example, a custom combobox, a live region, or a tabbed interface. Always prefer native elements first.
What is the most common ARIA mistake?
The most common mistake is adding role="button" to a <div> without also making it focusable (tabindex="0") and handling keyboard events (Enter and Space). The screen reader says "button" but it cannot be activated with the keyboard.
Can too much ARIA hurt accessibility?
Yes. Redundant or incorrect ARIA overrides the implicit semantics of native HTML elements, confusing screen readers. For example, adding role="link" to an <a> tag is redundant and can cause unexpected behavior in some assistive technologies.
Related guides
Keyboard Navigation
Keyboard navigation means that every interactive element on a page — links, buttons, form fields, menus, and custom widgets — can be reached...
Read more → AccessibilityForm Labels
Form labels are HTML <label> elements that programmatically associate a text description with a form input (text field, checkbox, select, et...
Read more → AI SEOStructured Data
Structured data is machine-readable markup (typically JSON-LD using the Schema.org vocabulary) embedded in your page's HTML that explicitly...
Read more →Scan your site for accessibility issues
Find and fix these issues automatically with eiSEO.
50 pages free · No credit card · Results in under 2 minutes