Why aria-roledescription Must Not Replace Semantic Roles

The aria-roledescription attribute allows authors to provide a custom, human-readable description of an element’s role for assistive technologies. It is descriptive only.

It does not define a role, does not change semantics, and does not make an element interactive. Because of this, aria-roledescription must only be used on elements that already have a semantic role, either implicit (from HTML) or explicit (via role="").

What aria-roledescription Is

What it does

• Refines how a role is announced
• Adds contextual meaning for users
• Preserves the underlying semantic role

What it does not do

• Create a role
• Replace a role
• Change how elements appear in role-based navigation
• Make non-interactive elements interactive

<button aria-roledescription="primary action">
  Save
</button>

A screen reader may announce:

“Save, primary action”

But the element is still a button in the accessibility tree.

A Quick Foundation: Roles, the Accessibility Tree, and Announcements

Screen readers do not analyse visual layout.

Browsers expose a separate structure, the accessibility tree, which contains:

• Role (what the element is)
• Name (what it’s called)
• State/value (its current condition)

aria-roledescription operates after the role is determined, modifying how that role is presented, not what the role is. If there is no role, there is nothing to describe.

What Counts as a Semantic Role?

An element has a semantic role if it has one of the following:

1. Implicit Native Role (HTML)

Examples:

• <button> → button
• <img> → img
• <input type="checkbox"> → checkbox
• <a href> → link

2. Explicit ARIA Role

<div role="combobox"></div>
<div role="button"></div>
<div role="dialog"></div>

Only in these cases is aria-roledescription meaningful.

Legitimate Use Cases

aria-roledescription is intended for complex or custom components where the standard role is technically correct but insufficiently descriptive.

Example: Carousel Slide

<div role="group" aria-roledescription="carousel slide">
  Slide 1 of 5
</div>

• Base role (group) remains intact
• Description adds context
• Users still navigate correctly by role

Example: Presentation Slide

<section role="region" aria-roledescription="presentation slide">
  Agenda
</section>

Example: Game or Chat UI Component

<div role="listitem" aria-roledescription="chat message">
  Hello!
</div>

In all cases:

• The standard role remains
• The description adds domain-specific meaning
• Navigation behaviour is unchanged

WCAG Context

WCAG 4.1.2 – Name, Role, Value

If an element is intended to function as a user interface component and does not expose a programmatically determinable role, assistive technologies cannot reliably interpret it.

Using aria-roledescription without an underlying role can contribute to a failure of SC 4.1.2 when the element is acting as a UI control. Not every misuse is automatically a WCAG failure, context matters.

Real Failure Example

<div aria-roledescription="button" onclick="save()">
  Save
</div>

Why this fails:

• No semantic role
• No keyboard support
• aria-roledescription falsely implies interactivity
• Screen readers may announce something “button-like” with no real role

This can fail:

• SC 4.1.2 (role not programmatically determinable)
• SC 2.1.1 (keyboard access)

Valid Usage Examples

Implicit Role

<img src="icon.png" aria-roledescription="status icon">

Native Interactive Element

<button aria-roledescription="destructive action">
  Delete
</button>

Explicit Role

<div role="combobox" aria-roledescription="search field"></div>

Important Nuance: Support vs Behaviour

The ARIA specification allows aria-roledescription on many roles.
However, assistive technology behaviour varies:

• Some screen readers announce it
• Some suppress it
• Some announce both role and description
• Some announce only the description

This is not a spec prohibition, it’s implementation variability.

Landmark Navigation: A Critical Detail

<nav aria-roledescription="main menu">

• Landmark navigation still exposes this as navigation
• aria-roledescription does not change how landmarks are listed
• Users navigating by landmarks will still encounter “Navigation”

This attribute does not redefine navigation models.

Why Overriding Role Vocabulary Is Dangerous

Screen reader users rely on standardised role terminology:

• Keyboard shortcuts jump between known roles
• Training materials use consistent vocabulary
• Muscle memory depends on predictable announcements

Replacing familiar role names can:

• Break expectations
• Reduce efficiency
• Increase cognitive load

This is why ARIA Authoring Practices recommend extreme restraint.

Localisation Warning (Often Missed)

aria-roledescription values:

• Are not automatically localised
• Must be translated manually
• Can drift out of sync with the visible UI language

If your interface is localised, your role descriptions must be too.

Testing Guidance

Automated

• Tools like axe may report pass / fail / incomplete
• “Incomplete” often indicates AT-dependent behaviour

Manual

1. Inspect element in DevTools → Accessibility
2. Verify:
   • Role exists
   • Description is exposed
3. Test with NVDA / JAWS / VoiceOver
4. Navigate by role and listen for announcements

If the role is unclear or missing, the implementation is incorrect.

Wrapping Up

• aria-roledescription does not create a role
• It must only be used on elements with an existing semantic role
• It should refine meaning, not replace standard vocabulary
• Misuse can cause inconsistent or misleading announcements
• Localisation and AT variability must be considered

Correct rule of thumb:
If the element does not have a semantic role without aria-roledescription, the implementation is incorrect.