Why ARIA Attributes Must Be Allowed for Their Roles

ARIA attributes are not universally allowed. Each ARIA role defines which states and properties are:

• Supported
• Required
• Prohibited

If an ARIA attribute is used where it is not permitted, the browser does not expose that attribute to assistive technologies. The information is lost, even though it still appears in the HTML.

This rule ensures that ARIA attributes are only used in combinations explicitly allowed by the WAI-ARIA specification.

WCAG Success Criterion

4.1.2 — Name, Role, Value (Level A)

User interface components must have a name and role that can be programmatically determined, and states, properties, and values that can be programmatically set and announced to assistive technologies. When prohibited ARIA attributes are used, the intended state or property is not programmatically determinable, failing SC 4.1.2.

How ARIA Actually Works

What Is an ARIA Role?

An ARIA role tells assistive technologies what kind of thing an element represents (for example, a button, a checkbox, or purely presentational content).

Roles come from the ARIA specification.
They are not the same as HTML elements.

⚠️ Important distinction:

• <strong> → an HTML element
• role="strong" → an ARIA role (rarely used, and not the same thing)

Most developers never need to use ARIA text roles directly.

What Is the Accessibility Tree?

Browsers do not expose raw HTML to screen readers.

Instead, they:

1. Parse the DOM
2. Apply native HTML semantics
3. Apply valid ARIA roles, states, and properties
4. Build an accessibility tree
5. Map that tree to platform accessibility APIs (UIA, AXAPI, ATK/AT-SPI)

If an ARIA attribute is not allowed for a role, it is not included in this tree.

What “Ignored” Really Means

When we say an ARIA attribute is ignored, we do not mean:

• It is visually ignored
• It throws a warning
• Assistive technologies, guess what you meant

We mean: The attribute is not mapped into the accessibility API at all. From the perspective of a screen reader, it does not exist.

The ARIA Role–State–Property Model

Every ARIA role definition specifies:

• Supported states and properties
  (attributes that may be used)
• Required states and properties
  (attributes that must be present)
• Prohibited states and properties
  (attributes that must not be used)
• Name calculation rules (nameFrom)

Attributes fall into different categories:

Global States and Properties

Examples:

• aria-label
• aria-labelledby
• aria-hidden

These are broadly allowed, but still subject to role restrictions.

Role-Specific States and Properties

Examples:

• aria-expanded
• aria-checked
• aria-selected

These are allowed only on specific roles.

Prohibited States and Properties

Some roles explicitly forbid certain attributes because they would contradict the role’s semantics.

What This Rule Checks

This rule verifies that:

• Each ARIA attribute used is supported for the element’s role
• No attribute listed as prohibited for that role is present
• Role–attribute combinations match the WAI-ARIA 1.2 role definition tables

If an attribute is prohibited, it is excluded from the accessibility tree.

Clarifying “Text-Like Roles”

When we refer to text-like roles, we mean ARIA roles, not HTML elements.

Examples of ARIA text roles:

• strong
• emphasis
• code
• insertion
• deletion

These roles represent static text semantics.

They are not interactive, and their accessible name behaviour is tightly defined (often nameFrom: contents or nameFrom: prohibited).

This has nothing to do with using <strong> or <em> in HTML.

Example: Prohibited Naming on a Text Role

<span role="strong" aria-label="Important">Warning</span>

Why this fails:

• The strong role derives meaning from its text content
• An author-provided label conflicts with the role’s naming rules
• The browser does not expose aria-label for this role

Screen reader result

The accessible name comes only from text content (“Warning”).
The label is discarded.

Presentation Roles and Semantics Removal

role="presentation" / role="none"

These roles explicitly remove semantic meaning.

<div role="presentation">★</div>

Result:

• Element is omitted from the accessibility tree
• It has no name, role, or states

Adding ARIA attributes does not restore semantics.

<div role="presentation" aria-label="Star icon">★</div>

Result:

• Role removes semantics
• aria-label is not exposed
• Screen readers announce nothing

This is not because aria-label is “globally prohibited”, but because the role eliminates semantic participation.

Why This Matters in Practice

When prohibited attributes are used:

• Information that the authors believe is exposed is silently dropped
• Screen reader output does not match developer intent
• Testing becomes misleading (“It’s in the DOM, why isn’t it announced?”)

This causes false confidence and inconsistent behavior across assistive technologies.

How to Fix Prohibited Attribute Usage

When you encounter a prohibited combination, determine why the attribute was added.

Option 1: Change the Role

If the element conveys meaning, the role may be wrong.

<!-- Instead of presentation -->
<div role="img" aria-label="Warning icon">⚠️</div>

Option 2: Provide the Information as Text

If the content is informational, text is often the correct solution.

<span class="visually-hidden">Warning</span>

Option 3: Move the Attribute to a Supported Element

<button aria-label="Open menu">
  <span role="presentation">☰</span>
</button>

Option 4: Remove the Attribute

If the attribute adds no meaningful information, removing it is correct.

Native HTML vs ARIA

Native HTML already defines:

• Valid semantics
• Allowed attributes
• Naming behavior

Using ARIA where it is prohibited does not enhance accessibility. It removes information from the accessibility tree.

A core ARIA principle applies: No ARIA is better than incorrect ARIA.

How This Is Tested

Accessibility tools verify that:

• Role–attribute combinations are valid
• No prohibited states or properties are present
• Required states are not missing

Automated tools reliably detect prohibited attributes.
Manual review confirms the intended semantics.

How to Know What’s Allowed

To verify a role–attribute combination:

1. Find the role in the WAI-ARIA 1.2 specification
2. Review the role’s table:
   • Supported states and properties
   • Required states and properties
   • Prohibited states and properties
   • nameFrom rules
3. Use only attributes explicitly allowed

Wrapping Up

ARIA attributes only work when used exactly as defined by the specification. If an attribute is not permitted for a role, it is not exposed to assistive technologies. The information is lost, even though the markup appears correct. Accessibility is not about adding ARIA everywhere. It is about using the right semantics in the right place. Only use ARIA attributes that are permitted for the element’s role.