Why ARIA Attributes Must Be Valid for Their Roles

ARIA attributes are not interchangeable. Each ARIA role defines exactly which states and properties are allowed, which are inherited, and which are global. Using attributes that are not supported for a given role results in invalid ARIA and unpredictable accessibility behaviour.

If an attribute is not permitted for a role, user agents may ignore it or expose inconsistent semantics through accessibility APIs.

WCAG Success Criterion 4.1.2 — Name, Role, Value

User interface components must have a programmatically determinable name and role, and any states or properties must be programmatically settable and exposed to assistive technologies.

Misusing ARIA attributes can prevent a component’s name, role, or value from being correctly exposed, which may fail SC 4.1.2.

Foundational Concepts

ARIA is built on three core concepts:

• Role — what the element is
  (e.g., button, checkbox, tab)
• State — the element’s current condition
  (e.g., checked, expanded, selected)
• Property — additional metadata or relationships
  (e.g., aria-labelledby, aria-controls, aria-describedby)

Roles define which states and properties are allowed. States and properties do not exist independently of the role.

How ARIA Actually Works (Accessibility Tree)

ARIA attributes live in the DOM, but assistive technologies do not read the DOM directly.

Instead:

1. The browser maps valid ARIA roles, states, and properties
2. These are exposed through platform accessibility APIs (AXAPI, UIA, ATK/AT-SPI)
3. Screen readers consume those APIs, not raw HTML

When ARIA is invalid:

• Some attributes are dropped
• Some are exposed inconsistently
• Behaviour varies across browsers and assistive technologies

Browsers do not validate ARIA against the spec at runtime. They expose what they can.

What This Rule Means (Plain Language)

ARIA is not free-form metadata.

You cannot:

• Add any aria-* attribute to any role
• Assume unsupported attributes are ignored safely
• Mix roles and attributes arbitrarily

Each role defines a contract:

If you use this role, only these states and properties are valid.

Anything outside that contract is invalid ARIA.

How ARIA Defines Allowed Attributes

In WAI-ARIA 1.2, each role includes tables that define:

• Required states and properties — must be present
• Supported states and properties — allowed but optional
• Inherited states and properties — inherited from abstract roles
• Global states and properties — allowed on all roles
  (e.g., aria-labelledby, aria-describedby, aria-hidden)

An attribute is invalid only if it is neither supported, inherited, nor global.

Correct Usage Examples

Valid: Supported state for the role

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

• aria-checked is supported on role="checkbox"
• State is valid and exposed correctly

Valid: Global attribute on any role

<div role="button" aria-describedby="hint">
  Submit
</div>
<p id="hint">Saves your changes</p>

• aria-describedby is a global property
• Allowed on all roles

Invalid Usage Examples

Unsupported attribute for the role

<div role="checkbox" aria-expanded="true">
  Subscribe
</div>

Why this fails:

• aria-expanded is not supported on role="checkbox"
• The attribute may be ignored or inconsistently exposed
• Screen readers may announce contradictory or missing state

Attribute conflicts with native semantics

<input type="checkbox" aria-valuenow="1">

Why this fails:

• aria-valuenow is not supported for checkboxes
• Native checkbox state is binary
• Value-based attributes conflict with the role’s model

Valid attribute, invalid context

<div role="button" aria-sort="ascending">
  Submit
</div>

Why this fails:

• aria-sort is only supported on columnheader and rowheader
• The attribute has no meaningful effect here
• Results in invalid ARIA

Why This Matters for Users

When unsupported ARIA attributes are used:

• Screen readers may announce states that don’t apply
• Users may hear incomplete or misleading information
• Role-based navigation becomes unreliable
• Debugging accessibility issues becomes significantly harder

For example, applying aria-expanded to a checkbox may be ignored by NVDA, while VoiceOver may expose it inconsistently depending on browser context.

Native HTML vs ARIA

Native HTML elements already define:

• Role
• State
• Value
• Allowed attributes

<input type="checkbox">

Already exposes:

• Role: checkbox
• State: checked / not checked

Adding unsupported ARIA does not enhance accessibility.
It may interfere with how assistive technologies interpret the element.

Rule of thumb:
If native HTML provides the behaviour you need, do not add ARIA.

How This Is Tested

Accessibility tools and audits check whether:

• ARIA attributes are permitted for the assigned role
• Required states are present
• Unsupported attributes are applied
• Role–attribute combinations conform to the ARIA specification

Automated tools can detect many violations, but manual review is often required, especially when roles or attributes are applied dynamically.

How to Fix the Problem

• Remove unsupported ARIA attributes
• Verify role–attribute combinations in WAI-ARIA 1.2
• Account for global and inherited attributes
• Prefer native HTML elements
• Follow ARIA Authoring Practices for complex widgets

If an attribute is not supported, inherited, or global, do not use it.

Wrapping Up

ARIA is precise by design.

• Roles define what an element is
• States define its current condition
• Properties define relationships and metadata
• Only specific combinations are valid

When role–attribute combinations violate the ARIA specification, browsers and assistive technologies may expose inconsistent or incomplete information.