ARIA Attributes Must Conform to Valid Names: How to Fix It

What this check flags

This check fails when your HTML carries an attribute that starts with aria- but isn't a real WAI-ARIA attribute name — a typo, an invented name, or something from an old draft. It matters because assistive technology silently ignores any aria-* attribute it doesn't recognize, so a single wrong letter can wipe out the accessible name or state you thought you'd shipped, and nobody sees an error to warn them.

The rule behind it is axe-core's aria-valid-attr. It walks every element that has an attribute beginning with aria- and checks the name against the fixed ARIA vocabulary. It doesn't judge the value — that's a different check. aria-hidden="banana" passes this rule (wrong value, valid name); aria-hidden spelled aria-hiden fails.

A real failing example, and the fix

Here's a settings dialog where a developer wired up the label and the expand state by hand. It looks correct in a quick source review. It isn't.

<!-- FAILING: two attribute names that don't exist in ARIA -->
<div role="dialog" aria-labeledby="dlg-title">
  <h2 id="dlg-title">Account settings</h2>
  <button aria-expandable="false">Advanced</button>
</div>

Two failures hide in there. aria-labeledby is a misspelling of aria-labelledby (ARIA uses the double-L spelling), so the dialog has no accessible name — a screen reader announces "dialog" and nothing else. And aria-expandable is not an ARIA attribute at all; the real state is aria-expanded. Both are ignored outright.

<!-- FIXED: real ARIA names, correctly spelled -->
<div role="dialog" aria-labelledby="dlg-title">
  <h2 id="dlg-title">Account settings</h2>
  <button aria-expanded="false">Advanced</button>
</div>

Nothing about the visible page changes. What changes is that the accessibility tree now actually receives the name and the state.

The typos that trip almost everyone

A short reference beats a lecture. These are the misspellings and inventions that show up over and over in real audits.

The pattern: ARIA is a closed vocabulary. There's no "close enough." If a name isn't on the official list of states and properties, the browser treats it as decoration and moves on.

How to detect it

1. axe DevTools (browser extension) — run it on the page and look for the "ARIA attributes must conform to valid names" / aria-valid-attr violation. It points you straight at the offending element.
2. Lighthouse in Chrome DevTools — the Accessibility category runs the same axe rules; a failure lands under "ARIA attributes are not valid or misspelled."
3. WAVE (WebAIM) — flags unrecognized ARIA in its details panel, handy for a visual sweep of a template.
4. Grep your own source. A quick pass for aria- across your templates catches copy-paste typos before they ship. You already know the real names from the table above — anything not on the list is a suspect.

How to fix it

1. Find every flagged attribute from the axe/Lighthouse report — it names the element and the bad attribute.
2. Check the name against the ARIA spec (WAI-ARIA states and properties, or the MDN ARIA attribute reference). If it's a typo, correct the spelling; if it's invented, find the real attribute that does the job.
3. Fix it at the source — the component template, not the rendered page. A typo baked into a reusable component multiplies across every page that renders it.
4. Watch for framework interference. Some frameworks strip or rename unknown attributes at render time, so a name that looks fine in your JSX/template can arrive mangled in the DOM. Inspect the rendered element, not just the source.
5. Re-run the scanner on the rendered page to confirm the violation is gone and you didn't introduce a new one.

FAQ

Does an invalid ARIA name actually hurt SEO, or just accessibility?

Directly, this is an accessibility failure — a real user with a screen reader gets nothing from the broken attribute. Indirectly it drags on quality signals: it tanks your Lighthouse accessibility score, and unlabeled interactive elements add friction that shows up in engagement. Search engines lean on page-experience signals, and clean, valid markup is part of looking like a well-built page.

Why does aria-hidden="true" pass but aria-visible="true" fails?

Because this check only looks at the attribute name. aria-hidden is a real ARIA state, so it passes regardless of its value. aria-visible is not in the spec at all, so it fails on the name alone. To hide from assistive tech, use aria-hidden; there's no positive "visible" attribute because visible is the default.

Is data-* the same problem?

No. data-* attributes are the sanctioned way to attach custom data and are always valid HTML. The mistake is reaching for a made-up aria-* name when what you wanted was either a real ARIA attribute or a plain data- attribute for your own JavaScript.

My typo is in a third-party widget I can't edit. Now what?

Report it upstream first. If you can't wait, you can correct the rendered attribute with a small script after the widget mounts (read the wrong attribute, set the right one, remove the wrong one), but treat that as a patch, not a fix — it breaks the moment the vendor changes their markup.

Related checks

• Required ARIA Attributes Must Be Provided — the flip side: a valid role that's missing the attributes it depends on.
• ARIA Tooltip Must Have an Accessible Name — a related "the name never reaches the user" failure.
• Test Frames with Accessibility Tools — how to actually verify what assistive tech receives.
• Accessibility and SEO — where WCAG work and search optimization genuinely overlap.