We'd like to set Google Analytics cookies to learn how people use the Knowledge Base, so we can improve it. We set them only if you accept.

Skip to main content
Digital Accessibility Knowledge Base

aria-braille-equivalent

Web validation

Ensure aria-braillelabel and aria-brailleroledescription have a non-braille equivalent.

ARIA braille attributes like aria-braillelabel and aria-brailleroledescription are specialized properties that allow developers to provide optimized text for braille displays. These attributes give authors greater control over how content is presented in braille, especially when standard translations from speech are ambiguous, overly verbose, or culturally mismatched. However, these properties are only meant to supplement, not replace mainstream accessible labels or role descriptions. If used alone, they will be ignored by most assistive technologies and could create inconsistent or confusing experiences for braille users.

Pass Patterns

aria-braillelabel with an equivalent alt text

This example passes because aria-braillelabel is paired with another equivalent label (alt attribute), allowing braille users to receive a concise representation while the speech output still conveys the full meaning.

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

aria-brailleroledescription with an equivalent aria-roledescription

In this case, aria-brailleroledescription is correctly used alongside aria-roledescription, providing a compact role for braille output while preserving the full role meaning for speech output.

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

Fail Patterns

An image with aria-braillelabel and an empty alt attribute

This fails because aria-braillelabel is used on an element that has no accessible name, such as an image with an empty alt attribute. Without a non-braille label, the braille-specific label is ignored.

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

aria-brailleroledescription without an equivalent aria-roledescription

This fails because aria-brailleroledescription is used without a matching aria-roledescription, which is required for compatibility and proper interpretation.

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

Try It Yourself

Since there is no point in performing this test with a screen reader and without a Braille display, we will only present the test in the browser here.

Inspecting the browser dev-tools

  1. Open the browser’s dev tools and navigate to the Accessibility pane.
  2. Select the element using aria-braillelabel or aria-brailleroledescription.
  3. Check whether a valid accessible name and role are present alongside the braille-specific attributes.

Expected result:

  • The element has a standard accessible name registered to the accessibility tree (the name field on the Accessibility pane has a value).
  • The element has a “roledescription” registered to the accessibility tree.

Actual result:

  • The element does not have a standard accessible name registered to the accessibility tree (the name field on the Accessibility pane is empty).
  • The element has only a “role” on the accessibility tree without a “roledescription”.

FAQ

How does this issue relate to 4.1.2 Name, role, value?

This issue falls under SC 4.1.2 because it affects the way user interface components are programmatically determined and communicated to assistive technologies. Missing accessible names or roles create incomplete information, breaking the accessibility tree.

Why is this issue marked as Serious?

This issue is serious because it can lead to significant confusion for assistive technology users. When no fallback label or role is provided, screen readers may ignore the braille-specific attribute entirely, causing the element to appear unlabeled or misrepresented.

Standards and Regulations

StandardSuccess CriterionReference
WCAG 2.24.1.2 Name, Role, Value (A)For all user interface components, the name and role can be programmatically determined; states, properties, and values that can be set by the user can be programmatically set; and notification of changes to these items is available to assistive technologies.
EN 301 5499.4.1.2 Name, Role, ValueSame as the WCAG text.

Personas impacted by this issue