Invalid ARIA Attributes: When Trying to Help Makes Things Worse

ARIA (Accessible Rich Internet Applications) attributes exist to fill gaps native HTML can't cover on their own — describing a custom widget's role, state, or relationships to assistive technology. They're powerful specifically because browsers and screen readers trust them completely: aria-expanded="true" is taken at face value, whether or not it's actually true. That trust is exactly what makes invalid ARIA so damaging — a typo doesn't just do nothing, it can actively misinform.

This falls under WCAG Success Criterion 4.1.2 (Name, Role, Value), Level A.

The three ways ARIA breaks

Invalid attribute names — a misspelling like aria-lable instead of aria-label isn't a recognized ARIA attribute at all. Browsers and screen readers silently ignore unrecognized attributes, so the element behaves exactly as if no label was provided.

<!-- Silently ignored — not a real ARIA attribute -->
<button aria-lable="Close">×</button>

<!-- Correct -->
<button aria-label="Close">×</button>

Invalid attribute values — aria-expanded only accepts "true" or "false"; a value like aria-expanded="yes" fails validation and gets treated as if the attribute weren't set.

<!-- Invalid value -->
<button aria-expanded="yes">Menu</button>

<!-- Correct -->
<button aria-expanded="false">Menu</button>

Invalid or misused roles — assigning a role value that doesn't exist in the WAI-ARIA specification, or a role that requires attributes you haven't provided. role="tab", for instance, is expected to live inside a role="tablist" container and typically needs aria-selected — using it standalone without that context leaves assistive technology unable to build a coherent picture of the widget.

<!-- Incomplete: a tab needs required attributes and proper context -->
<div role="tab">Settings</div>

<!-- Complete -->
<div role="tablist">
  <div role="tab" aria-selected="true" id="tab-1">Settings</div>
</div>

How to catch this reliably

Unlike a lot of accessibility issues, invalid ARIA is close to 100% automatable — the WAI-ARIA spec defines an exact, finite list of valid attributes, valid values per attribute, and valid roles, so a scanner can check syntax with certainty. If you're hand-writing ARIA, cross-reference the actual spec (or the WAI-ARIA Authoring Practices Guide's widget patterns) rather than guessing at attribute names from memory — this is one of the few areas of accessibility where there's a strict right answer, not a judgment call.

The bigger picture: "No ARIA is better than bad ARIA"

This is the second half of the well-known first rule of ARIA (the first half being "don't use ARIA if native HTML already does the job"). A <div> with a broken role="button" and no keyboard handling is often worse for a screen reader user than a plain, unstyled <div> — the broken ARIA actively announces "this is a button" for something that doesn't behave like one, creating a confusing mismatch between what's announced and what actually happens.

Official references

• Deque University: aria-hidden-focus
• Deque University: aria-required-attr
• Deque University: aria-roles
• Deque University: aria-valid-attr
• Deque University: aria-valid-attr-value