ARIA attribute name is not valid

What is this issue?

An attribute in the reserved aria- namespace has a name that doesn’t correspond to any attribute the WAI-ARIA specification actually defines. This is almost always a spelling mistake (aria-lable, aria-decribedby, aria-requried) rather than an attempt to use a genuinely custom attribute, since the aria- prefix is understood by browsers and assistive technology as a fixed, closed vocabulary, not an open namespace like data-*.

This is distinct from an attribute that’s spelled correctly but used on the wrong role, or has an invalid value; here, the attribute name itself isn’t recognized at all, so nothing downstream about role compatibility or value validity is even relevant yet.

Why does this matter?

HTML parsing is deliberately tolerant of attributes it doesn’t recognize: the browser doesn’t throw an error or log a warning for aria-lable, it simply keeps the attribute in the DOM as inert data and moves on. That tolerance, which keeps the web resilient to markup the browser doesn’t understand, is exactly what makes this class of typo so easy to miss: the page renders correctly, the code passes a visual review, and the browser gives no signal that anything is wrong.

The cost lands entirely on assistive technology users, silently. A developer who writes aria-lable="Submit order" on a checkout button sees the button work exactly as expected in every manual test that doesn’t specifically involve a screen reader: click handlers fire, styling applies, the page looks correct. Only a screen reader user discovers the button has no accessible name at all, because the misspelled attribute was never a real naming mechanism the browser could recognize.

Who is affected?

• Screen reader users: hear no name, description, or state for whatever the misspelled attribute was meant to provide, since the browser never builds the intended value into the accessibility tree in the first place.

What users experience

Beatriz uses NVDA on Windows to check out on an online bookstore. The “Complete purchase” button has aria-lable="Complete purchase order, total $47.20" instead of aria-label, a typo introduced when the attribute was hand-typed rather than copied from a snippet. NVDA doesn’t recognize aria-lable as a real attribute, so it falls back to whatever visible text is inside the button; in this case, none, since the button only contains an icon. NVDA announces just “button” with no name and no price confirmation, at the exact moment Beatriz needs the most certainty that she’s about to complete the right purchase.

How do I fix it?

Correct the attribute name to match its exact spelling in the WAI-ARIA specification. This works because browsers and assistive technology only recognize the precise, spec-defined attribute names; the moment the spelling matches, the browser starts building the intended value into the accessibility tree exactly as the developer meant it to.

Check the corrected name against the WAI-ARIA specification’s States and Properties list if you’re unsure of the exact spelling, since several attribute names have easy-to-mistype variants (aria-labelledby, not aria-labeledby; aria-describedby, not aria-describeby). Where possible, use a code editor or linter with ARIA attribute validation, such as an accessibility-focused ESLint plugin, so a misspelled attribute name is caught while writing the code rather than discovered later in a scan or, worse, by a user.

Code Examples

<button aria-lable="Complete purchase order, total $47.20">
  <svg aria-hidden="true">...</svg>
</button>

<button aria-label="Complete purchase order, total $47.20">
  <svg aria-hidden="true">...</svg>
</button>

Correcting aria-lable to aria-label is the entire fix; no other markup changes, since the attribute’s value was always correct and complete, only its name was misspelled. The aria-hidden="true" on the decorative icon inside the button was already correct and unaffected; it’s shown here to make clear that fixing the typo doesn’t require touching anything else in the button’s markup.

Common Mistakes

Mistake: “The attribute is right there in the HTML, so it must be doing something.” Presence in the DOM and recognition by the accessibility tree are two different things. A misspelled aria-* attribute is fully present and inspectable in the browser’s Elements panel while being completely invisible to the accessibility tree the browser builds from recognized attribute names only.

Mistake: “I tested this in the browser and nothing looked broken, so the attribute must be working.” A misspelled ARIA attribute produces no visual difference and no console error, since HTML parsing tolerates unrecognized attributes silently. The only way to catch this class of bug through testing is with a screen reader or an accessibility tree inspector, not a standard visual or functional test pass.

Mistake: “Autocomplete in my editor suggested this attribute name, so it must be correct.” Autocomplete suggestions can be based on incomplete or stale attribute lists, especially in editors without a dedicated, spec-synced ARIA linting extension. Cross-checking against the actual WAI-ARIA specification, or using a linter built specifically for ARIA validation, is more reliable than trusting general-purpose autocomplete.

How RedFlag Detects This

Automated: axe-core rule, runs on every scan. RedFlag calls axe-core’s aria-valid-attr rule as part of every scan, restricted to the WCAG 2.0/2.1/2.2 A and AA rule set. The rule checks every attribute whose name starts with aria- against the WAI-ARIA specification’s complete list of defined attribute names, flagging any attribute name that doesn’t match one exactly.

False negative: the rule only confirms the attribute name is spelled correctly; it says nothing about whether that attribute is valid for the element’s role or contains a valid value; those are separate checks entirely. False positive: none typical for this check, since matching an attribute name against a fixed, published vocabulary is a binary string comparison axe-core evaluates reliably. Manual step: after correcting a misspelled attribute name, confirm with a screen reader that the intended name, description, or state is now actually announced, since fixing the spelling doesn’t guarantee the corrected attribute is also valid for that specific role.

Manual Testing

1. Open the page in Chrome or Firefox with NVDA or VoiceOver running.
2. Tab to or navigate to elements you expect to have a specific accessible name, description, or state from an ARIA attribute.
3. Listen to what’s announced. If a name, description, or state you expect is missing entirely, and the element visually appears to have the right markup, suspect a misspelled attribute name.
4. Open the browser’s accessibility inspector (Chrome DevTools → Elements → Accessibility pane) and check whether the “Name,” “Description,” or relevant property is populated; a blank value despite an apparently-correct attribute in the DOM points to a spelling mismatch.
5. Compare the exact attribute name in the page’s source against the WAI-ARIA specification’s list of defined attributes to confirm the spelling.

Related WCAG Success Criteria

4.1.2 Name, Role, Value: Every interface component must expose a name, role, and value to assistive technology. A misspelled aria-* attribute fails this criterion because the browser never recognizes it as a naming, describing, or state mechanism at all; from the accessibility tree’s perspective, it’s as if the attribute was never written.

Related Issues

ARIA attribute has an invalid value is the natural next check once an attribute name is confirmed correct; it verifies the value inside a correctly-spelled attribute is also one the specification allows.

ARIA role is invalid is the equivalent typo check for the role attribute’s value instead of an aria-* attribute’s name: the same category of mistake on a different attribute.

ARIA attribute is not allowed for this role and ARIA attribute is not valid for the current role value both assume the attribute name is already spelled correctly; this rule’s failure is more fundamental and needs fixing first.

aria-hidden=“true” is present on the document body and Focusable element is inside an aria-hidden container both concern the same aria-hidden attribute this rule validates the name of; a correctly-spelled aria-hidden can still cause its own separate problems depending on where it’s applied.

References

• W3C Understanding 4.1.2: Name, Role, Value
• WAI-ARIA 1.2: States and Properties
• MDN: ARIA attributes reference