Why ARIA Braille Attributes Must Not Be Used Alone

ARIA includes a small set of attributes specifically designed for braille displays. These attributes exist to adjust how information is rendered in braille, not to define what the element is.

Because of that, ARIA braille attributes can never stand alone. They must always be backed by a standard, non-braille label or role description.

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 available to assistive technologies.

Braille-only attributes do not satisfy this requirement by themselves.

What Is a Braille Display?

A refreshable braille display is a hardware device that converts on-screen text into tactile braille cells.
Unlike screen readers, which speak content aloud, braille displays:

• Show text using a limited number of cells (often 40 or fewer)
• Rely entirely on structured accessibility information
• Do not interpret visuals, layout, or proximity

Braille displays get their information from the accessibility tree, which browsers generate using semantic HTML and ARIA. If something is missing from that tree, the braille display never sees it.

What Are ARIA Braille Attributes?

ARIA braille attributes were introduced in WAI-ARIA 1.3 to allow authors to adjust how labels and role descriptions appear specifically on braille displays.

The two attributes are:

• aria-braillelabel
  A braille-specific rendering of an element’s accessible name
• aria-brailleroledescription
  A braille-specific rendering of a custom role description

These attributes do not participate in accessible name computation.
They are applied after the name and role have already been determined.

The Core Rule

Braille attributes must never be the only source of a label or role description.

WAI-ARIA requires that:

• aria-braillelabel is only used on elements that already have an accessible name
• aria-brailleroledescription is only used on elements that already have aria-roledescription

Without the non-braille equivalent, user agents are not required to expose the braille attribute at all.

Why Braille Labels Exist at All

Braille displays have real constraints:

• Limited cell width
• Higher cognitive load for long phrases
• Slower scanning compared to audio

Examples where braille attributes make sense:

• “Presentation slide” → sld
• “Application menu” → app menu
• “Four-star rating” → ****

These are presentation optimisations, not semantic definitions.

Correct Usage Examples

Good: aria-braillelabel with an accessible name

<button
  aria-label="Rating: 4 stars"
  aria-braillelabel="****">
  <img alt="4 stars" src="images/stars.jpg">
</button>

• aria-label defines the accessible name
• aria-braillelabel provides a shorter braille rendering
• Screen readers and braille displays both receive complete information

Bad: braille label without an accessible name

<img
  alt=""
  aria-braillelabel="****"
  src="images/stars.jpg">

This fails because:

• The element has no accessible name
• There is nothing for the braille label to modify
• User agents may ignore the braille attribute entirely

aria-brailleroledescription Examples

Good: braille role description with aria-roledescription

<div
  role="article"
  aria-labelledby="slideheading"
  aria-roledescription="slide"
  aria-brailleroledescription="sld">
  <h1 id="slideheading">My vacation in Rome</h1>
</div>

• aria-roledescription defines a custom role description
• aria-brailleroledescription shortens it for braille output

Bad: braille role description without a base role description

<div
  role="article"
  aria-labelledby="slideheading"
  aria-brailleroledescription="slide">
  <h1 id="slideheading">My vacation in Rome</h1>
</div>

This fails because:

• There is no aria-roledescription
• The braille role description has no non-braille equivalent
• Assistive technologies may ignore it

Important Warning About aria-roledescription

aria-roledescription and by extension aria-brailleroledescription should be used rarely.

ARIA Authoring Practices caution that:

• Screen reader users rely on standardised role vocabulary
• Overriding roles can reduce usability and predictability
• If you should not use aria-roledescription, you should not use its braille variant either

Braille attributes are not a workaround for poor semantics.

Browser & Assistive Technology Support (2025)

ARIA braille attributes are relatively new:

• Introduced in ARIA 1.3
• Support varies across browsers and assistive technologies
• Some screen readers may ignore them entirely

Because of this:

• Always test with real AT + braille displays
• Never rely on braille attributes as the sole source of meaning

Why This Matters

Braille users navigate by role, name, and structure, just like screen reader users — but with tighter constraints.

When Braille attributes are misused:

• The element may have no accessible name in the accessibility tree
• Role information may be incomplete or missing
• Navigation lists and structured exploration break down

This is a failure of WCAG SC 4.1.2 (Name, Role, Value).

Common Causes of Failure

• Using aria-braillelabel without an accessible name
• Using aria-brailleroledescription without aria-roledescription
• Treating braille attributes as replacements instead of alternatives
• Applying braille attributes to unnamed or decorative elements
• Using Braille attributes to compensate for bad labelling

Practical rule of thumb:

If removing the braille attribute causes the element to lose its accessible name or role description, the implementation is incorrect.

How This Is Tested

Some accessibility tools check that:

• aria-braillelabel is only present when a non-empty accessible name exists
• aria-brailleroledescription is only present when aria-roledescription exists

However, automated support is still evolving. Manual inspection and real assistive technology testing are essential.

Wrapping Up

ARIA braille attributes are presentation refinements, not semantic foundations. They exist to make content more usable on braille displays, especially where space and scanning speed matter, but they cannot define meaning on their own.

Every braille label or role description must be backed by a standard, programmatically determinable equivalent. If an element is not accessible without braille attributes, it will not become accessible with them either.