Invalid ARIA Attributes and How to Spot Them

ARIA attributes are instructions to assistive technology. When an attribute is misspelled, given a value the specification does not allow, or placed on a role that cannot carry it, assistive technology ignores it or reads it wrong. The page looks unchanged to a sighted visitor, while the coded meaning quietly breaks. That is why invalid ARIA is worth hunting down even though nothing looks wrong.

The rule behind the hunt is WCAG 4.1.2 Name, Role, Value, at Level A: the name and role of every user interface component must be programmatically determinable, and states and values the user can set must be programmatically settable. An invalid ARIA attribute fails that rule in practice, because the name, role, or state it was meant to convey never reaches assistive technology in a usable form.

Key takeaways

• Check every ARIA attribute three ways: is the name real, is the value allowed, and does the role support it.
• A misspelled attribute is ignored, not corrected, by browsers and assistive technology.
• A wrong value, such as aria-checked="no", is ignored or misread. Use true, false, or mixed for tristate attributes.
• An attribute on the wrong role, such as aria-checked on a link, does nothing useful.
• The best fix for many ARIA problems is removing the ARIA and using native HTML instead.

Start with the first rule of ARIA

The first rule of ARIA, from the W3C, is blunt: if you can use a native HTML element or attribute with the semantics and behavior you need already built in, use it instead of repurposing an element and adding ARIA to make it accessible. A native button already has a button role, keyboard activation with Enter and Space, and a name from its text. A div with role="button", tabindex, and key handlers is a hand built copy of the same thing, with more ways to get it wrong.

Most invalid ARIA on small sites comes from copying a widget pattern and editing it by hand. A developer copies a tab component, renames a few attributes, and leaves an aria-selected on an element that no longer has a tab role. A designer adds aria-label to a div that is not interactive, hoping it will be announced. It will not be, because a plain div has no role that carries a name in the accessibility tree.

Before you fix an invalid attribute, ask whether the ARIA is needed at all. If a native element does the job, replace the custom widget with the native element and delete the ARIA. That removes the whole class of error.

Check one: is the attribute name real

The first check is spelling. ARIA attribute names all start with aria-, followed by a defined name. A typo creates an attribute that does not exist, and browsers pass it through as an unknown attribute with no effect. Deque's axe rule aria-valid-attr checks exactly this: attributes beginning with aria- must be valid ARIA attributes.

Failing version:

<button aria-lable="Search the site">Search</button>

Passing version:

<button aria-label="Search the site">Search</button>

Common misspellings include aria-lable, aria-desribedby, aria-expanded misspelled as aria-expand, and aria-hidden written as aria-hide. A code search for "aria-" across your templates, followed by a check of each hit against the specification list, finds these fast. Automated checkers flag them too, which is why a scan report is a good starting point rather than a manual read of every file.

Check two: is the value allowed

The second check is the value. Every ARIA attribute accepts only certain value types. Some accept true or false. Some accept true, false, or mixed. Some accept a token from a fixed list, such as aria-orientation accepting horizontal or vertical. Some accept an ID reference, or a list of ID references. Deque's axe rule aria-valid-attr-value checks this: values must be spelled correctly and correspond to values allowed for that attribute.

Deque gives a plain example. The value aria-hidden="true" passes. The values aria-hidden="rtue" and aria-hidden="pizza" fail. The first is a typo. The second is a word that is not a value for that attribute at all. Both are ignored, so the element's hidden state falls back to its default.

Failing version:

<div role="checkbox" aria-checked="no" tabindex="0">Send me updates</div>

Passing version:

<div role="checkbox" aria-checked="false" tabindex="0">Send me updates</div>

ID references are a quieter failure. An attribute such as aria-describedby="help-text" does nothing if no element on the page carries id="help-text". The reference dangles. Check that every ID named in an aria-labelledby, aria-describedby, or aria-controls attribute exists, is unique on the page, and points at the element you meant. Duplicate IDs break the reference for the same reason: the browser resolves to the first match, which may be the wrong element.

Also mind case and spacing. Values are case sensitive in practice for token lists, and an ID reference with a typo is a different ID. Copy IDs from the markup rather than typing them from memory.

Check three: does the role support it

The third check is fit between attribute and role. Each role supports a defined set of attributes. Putting an attribute on a role that does not support it has no effect, and it can mislead the next developer into thinking the state is conveyed. Deque's axe rule aria-allowed-attr checks this: an element's role must support its ARIA attributes.

Failing version:

<a href="/offers" role="link" aria-checked="true">Offers</a>

Passing version:

<input type="checkbox" checked> <label>Offers</label>

The passing version also shows the first rule of ARIA at work. A native checkbox already carries its checked state, its label, and its keyboard behavior. No ARIA is needed at all.

A routine that finds them

Run this routine on a template or a page, in order, and record what you find:

• Search the code for "aria-" and list every attribute name. Strike any name that is not in the specification.
• For each surviving attribute, check its value against the allowed type. Fix typos, replace invented words with allowed tokens, and confirm every ID reference exists and is unique.
• For each attribute, check the element's role. Remove attributes the role cannot carry, or change the role to one that can, with a native element preferred.
• Re-run the automated checker and confirm the count drops to zero for these rules. Then test with a keyboard and a screen reader, because a valid attribute can still be wrong for the content.

Common mistakes

• Copying a widget pattern and leaving attributes from the original role behind.
• Typing ID references from memory instead of copying them from the markup.
• Using "yes", "no", "on", or "off" where true or false is required.
• Adding aria-label to a plain div or span and expecting it to be announced.
• Stacking ARIA on a custom control instead of using the native element that already has the role.
• Treating a clean automated report as proof the names are sensible, rather than only proof they are valid.

How Axeazy helps with this exact issue

Axeazy lists ARIA attribute validity among the 14 fix categories it works on. A scan can flag invalid attribute names and values in your code, using the same axe-core engine that powers the accessibility panel in Chrome DevTools. Read the honest scope on the capabilities page, and read how the scan works to see how findings are recorded with a date and time.

For a site with its own GitHub repository, fixes arrive as a real pull request with a visible code diff for review and merge. For other sites, the scan gives the computed fix values and a guided checklist to apply by hand. The related aria-hidden guide in this series covers the one attribute most often misused on focusable content, and the link names guide covers the naming rule that ARIA attributes serve.

Want a quick read on your own site? Run Axeazy's free 60 second scan . It needs no signup.

Last checked: October 30, 2026.

FAQ

What happens when an ARIA attribute is invalid?

Assistive technology ignores it or reads it wrong. A misspelled name sets nothing. A wrong value falls back to a default or is ignored. The page looks unchanged to a sighted visitor, which is why invalid ARIA is easy to miss.

Is an automated checker enough to find invalid ARIA?

It finds the three validity checks in this article: bad names, bad values, and bad role fit. It cannot judge whether a valid name says the right thing. Read the names in a screen reader's control list to check sense as well as validity.

Should I remove ARIA instead of fixing it?

Often, yes. The first rule of ARIA says to use a native HTML element when one has the semantics and behavior you need. Replacing a custom widget with a native button, checkbox, or select removes the ARIA and the error class with it.

Can Axeazy fix invalid ARIA attributes for me?

A scan can flag invalid names and values, and for sites with a GitHub repository the fix can arrive as a reviewable pull request. Review the proposed change before merging, since the right value depends on what the control is meant to do.

Sources

• W3C Understanding Success Criterion 4.1.2: Name, Role, Value, checked October 30, 2026
• Deque axe rule: ARIA attributes must conform to valid values, checked October 30, 2026
• Deque axe rules list, including aria-allowed-attr, checked October 30, 2026
• MDN: aria-hidden attribute, checked October 30, 2026
• Axeazy capabilities, checked October 30, 2026