Why ARIA Attributes Must Use Valid Names

ARIA attributes only work if browsers and assistive technologies recognise them. ARIA (Accessible Rich Internet Applications) is a specification that allows developers to expose roles, states, and properties to assistive technologies. Browsers translate valid ARIA attributes from the DOM into the accessibility tree, which screen readers rely on to understand what an interface element is and how it behaves. If an ARIA attribute name is invalid, it is ignored during this translation.

WCAG Success Criterion

Success Criterion: Name, Role, Value (4.1.2)

User interface components must have a name and role that can be programmatically determined, and states, properties, and values must be programmatically settable and available to assistive technologies.

Invalid ARIA attributes can cause failures of this criterion when required name, role, or state information cannot be programmatically determined.

What This Rule Means in Practice

ARIA is not free-form metadata. Only ARIA attributes explicitly defined in the WAI-ARIA specification are mapped into accessibility APIs. Attributes that are misspelt, invented, or outdated remain in the DOM but have no accessibility semantics.

In practice, this means:

• Valid attribute → mapped into the accessibility tree
• Invalid attribute → ignored by assistive technologies

The browser does not warn you when this happens.

What Counts as a Valid ARIA Attribute

A valid ARIA attribute must:

• Start with aria-
• Be defined in the WAI-ARIA specification (currently WAI-ARIA 1.2)
• Use the exact attribute name defined by the spec
• Be used as an attribute name (not confused with values)

Examples of valid ARIA attributes:

• aria-hidden
• aria-label
• aria-labelledby
• aria-expanded
• aria-checked
• aria-disabled
• aria-describedby

If the attribute name is not defined in the specification, it has no effect.

Correct Markup Examples

Valid attribute name

<button aria-expanded="true">
  Menu
</button>

Valid labelling attribute

<button aria-label="Close dialog">
  ✕
</button>

Valid state attribute

<div role="checkbox" aria-checked="false">
  Subscribe
</div>

In each case, the browser can expose the role and state to assistive technologies.

Incorrect Markup Examples

Misspelt attribute name

<button aria-expaned="true">
  Menu
</button>

aria-expaned does not exist. The expanded state is not exposed.

Non-existent attribute

<div aria-visible="true">
  Content
</div>

aria-visible is not a valid ARIA attribute and is ignored.

Typo in common attribute

<button aria-lable="Submit">
  Submit
</button>

Because the attribute name is invalid, the button has no accessible name.

Invented ARIA attributes

<div aria-clickable="true">
  Item
</div>

ARIA does not support custom attributes. This provides no accessibility information.

Invalid Attribute Names vs Invalid Values

This rule checks attribute names, not values, but both matter.

Invalid attribute name

<button aria-expaned="true"></button>

The attribute is ignored entirely.

Valid name, invalid value

<button aria-expanded="maybe"></button>

The attribute name is valid, but the value is not a permitted token. The state is treated as undefined or ignored.

Both cases result in missing or incorrect accessibility information.

Case Sensitivity Clarification

In HTML documents:

• ARIA attribute names are case-insensitive
• aria-hidden, ARIA-HIDDEN, and ArIa-HidDeN are equivalent

However:

• Attribute values may be restricted to specific tokens
• In XML/XHTML contexts, case sensitivity rules differ

What matters is that the attribute name and value match the specification exactly.

Why This Matters

ARIA attributes expose role, state, and property information to assistive technologies through the browser’s accessibility tree.

When an ARIA attribute name is invalid:

• The browser does not map it into accessibility APIs
• Screen readers never receive the intended information
• States like expanded, checked, or hidden are not announced
• Developers may believe accessibility is implemented when it is not

This creates silent failures that are invisible during visual testing.

Common Causes of This Failure

• Typographical errors (aria-lable, aria-expaned)
• Guessing attribute names instead of checking the spec
• Copy-pasting incorrect examples
• Confusing ARIA attributes with CSS or JS concepts
• Using deprecated or removed ARIA attributes
• Forgetting that ARIA is strictly defined

A key principle applies here:

No ARIA is better than invalid ARIA.

How This Is Tested

Automated tools (such as Axe) verify that:

• Every aria-* attribute name exists in the ARIA specification
• Attribute names are not deprecated or invalid
• Invalid attributes are flagged regardless of visual behaviour

This is a deterministic check:
An invalid ARIA attribute name always fails this rule.

How to Verify ARIA Attributes Yourself

You can inspect whether an ARIA attribute is working:

1. Open browser DevTools
2. Select the element
3. Open the Accessibility panel
4. Check whether the role, name, or state appears

If the attribute does not appear there, assistive technologies will not see it.

Wrapping Up

ARIA attributes must use valid, specification-defined names to work.

An invalid ARIA attribute:

• Remains in the DOM
• Is ignored by the accessibility tree
• Provides no information to assistive technologies
• Can lead to failures of Name, Role, or Value

ARIA only works when attribute names and values match the specification exactly.