aria-braillelabel or aria-brailleroledescription has no equivalent

What is this issue?

An element sets aria-braillelabel without also having a valid accessible name (the text a screen reader announces to identify an element, coming from the first source that applies: aria-labelledby, aria-label, visible label text, then other element-specific fallbacks), or sets aria-brailleroledescription without a matching aria-roledescription.

Both braille attributes exist purely to adjust how an already-named element renders on a refreshable braille display; they’re a supplement, never a substitute. aria-braillelabel is meant to shorten a name that’s efficient to speak but unwieldy to read cell-by-cell in braille; aria-brailleroledescription does the same for a custom role’s description. An element that has only the braille attribute, with no standard counterpart backing it, technically has braille-specific text with nothing standard for it to be a shortened version of.

Why does this matter?

A refreshable braille display is a hardware device, typically connecting to a computer or phone by USB or Bluetooth, with a row of mechanical cells (usually 14 to 40) each made of tiny pins that raise and lower to form braille characters in real time as content is read. It’s used by many blind and low-vision screen reader users as an alternative or companion to synthesized speech, and it’s the primary way many deafblind users, who can’t rely on audio output at all, read a screen.

Braille has a hard physical constraint speech doesn’t: a 40-cell display shows roughly 40 characters at once, so a verbose accessible name like “3 out of 5 stars” costs real reading time to pan across, cell by cell, compared to a compact braille-specific label like “***”. That’s the entire reason aria-braillelabel exists. But when it’s set with no accessible name behind it, there’s nothing for it to be shortening: some assistive technology falls back to announcing nothing at all rather than falling back to a name that was never actually provided.

Who is affected?

• Screen reader users: specifically those reading via a connected refreshable braille display, or a standalone braille notetaker, who lose the element’s name entirely when the braille attribute has no accessible name to fall back on, rather than getting a full-length version instead of a short one.

What users experience

Oyelaran is deafblind and reads the web entirely through a 40-cell braille display paired with his laptop, with no audio output in use at all. A product page’s star-rating widget sets aria-braillelabel="***" on its container but the container has no aria-label and no visible text content of its own; the rating is conveyed only through five filled/unfilled icon spans with no accessible name. His braille display shows the widget’s bare role with no rating information whatsoever, not even the shortened “***” the developer intended, since the braille attribute never had a standard name to attach itself to.

How do I fix it?

Give the element a valid accessible name using aria-label, aria-labelledby, or visible text (the same as any other missing-name failure), and only then add aria-braillelabel as a shorter variant of that name for braille display rendering. This works because the braille attribute is designed to layer on top of an existing name, not stand alone; assistive technology that doesn’t support the braille attribute falls back cleanly to the standard name once one actually exists.

Apply the identical pattern to aria-brailleroledescription: add aria-roledescription first if the element uses a custom role that needs a human-readable description, then add the braille-specific shortened version alongside it, never instead of it.

If the full accessible name is already short enough to read comfortably on a braille display (a two- or three-word label), skip aria-braillelabel entirely rather than adding a value identical to the name it would duplicate. The attribute earns its place only when it meaningfully shortens something long, symbol-heavy, or awkward for a linear tactile read.

Code Examples

<button aria-braillelabel="***">
  <span class="stars">★★★☆☆</span>
</button>

<!-- Accessible name added first; aria-braillelabel shortens it for
     braille displays without changing what's spoken. -->
<button aria-label="3 out of 5 stars" aria-braillelabel="***">
  <span class="stars" aria-hidden="true">★★★☆☆</span>
</button>

The “before” example sets aria-braillelabel on a button whose only visible content is aria-hidden-worthy star icons, leaving no accessible name behind the braille shorthand at all. The fix adds aria-label="3 out of 5 stars" first, so a screen reader with speech output announces the full description and a connected braille display shows the compact “***” instead; both paths now resolve to real content.

Common Mistakes

Mistake: “aria-braillelabel is just a braille-specific alternative to aria-label, so I only need one or the other.” The two aren’t alternatives: aria-braillelabel only takes effect on a braille display and depends on a standard accessible name existing for every other assistive technology. Using only aria-braillelabel leaves speech-based screen reader users with no name at all.

Mistake: “Since braille users are a small audience, this attribute is optional polish, not a real bug.” The bug isn’t about whether the braille shorthand exists: it’s that setting a braille-only attribute with no accessible name breaks the element for everyone, since most assistive technology reads the standard accessible name, and only a smaller subset additionally benefits from the braille-specific text.

Mistake: “Making the braille label an abbreviation makes it less accurate, so it should say exactly the same thing as the accessible name.” The entire value of aria-braillelabel is that it can differ from the accessible name to fit the tactile medium’s line-length constraints: “***” losslessly represents “3 out of 5 stars” for someone reading cell by cell. Forcing them to be identical text defeats the purpose and just adds a redundant attribute.

How RedFlag Detects This

Automated: axe-core rule, runs on every scan. RedFlag calls axe-core’s aria-braille-equivalent rule as part of every scan, restricted to the WCAG 2.0/2.1/2.2 A and AA rule set. The rule flags any element with a non-empty aria-braillelabel that has no valid accessible name, and separately flags any element with a non-empty aria-brailleroledescription that has no aria-roledescription.

False negative: axe-core confirms a standard name or role description exists; it can’t judge whether the braille-specific text is an accurate shortened version of it, or whether it was placed on the correct element rather than a nearby parent or child that doesn’t actually need braille adjustment. False positive: none typical for this check, since the presence of the braille attribute paired with the absence of its required counterpart is a binary condition. Manual step: where possible, verify on an actual braille display or braille-capable screen reader setting that the shortened text reads sensibly against the full accessible name it’s meant to summarize.

Manual Testing

1. If a physical refreshable braille display is available, connect it to a screen reader that supports braille output (NVDA and JAWS on Windows both support connected braille displays).
2. Navigate to each element using aria-braillelabel or aria-brailleroledescription and confirm the display shows meaningful text, not a blank or role-only cell sequence.
3. Switch the same screen reader to speech-only mode and confirm the identical element still announces a full, accurate name; the braille attribute should never be the only source of a name.
4. Without a physical display available, use the browser’s accessibility inspector (Chrome DevTools → Elements → Accessibility pane) on the element and confirm the “Name” property is populated independently of the braille attributes.

Related WCAG Success Criteria

4.1.2 Name, Role, Value: Every interface component must expose a name, role, and current value to assistive technology. An element whose only name-adjacent attribute is a braille-specific one with no standard counterpart still fails this criterion for any assistive technology that doesn’t specifically consume the braille attribute.

Related Issues

ARIA command has no accessible name covers the more common version of a missing accessible name (no naming attribute of any kind), which is the same underlying gap this rule catches in its braille-specific form.

ARIA input field has no accessible name and ARIA toggle field has no accessible name cover the equivalent missing-name failure on data-entry and state-toggling widgets, both of which can also carry aria-braillelabel if their names are long enough to benefit from shortening.

ARIA tooltip has no accessible name is a related content-completeness failure: an element technically present in the DOM but functionally empty for assistive technology, the same shape of problem this rule catches for the braille-specific attributes.

Role value is not valid for this element is worth checking alongside this rule, since aria-brailleroledescription is only meaningful on elements whose role genuinely benefits from a role description in the first place.

References

• W3C Understanding 4.1.2: Name, Role, Value
• MDN: aria-braillelabel
• MDN: aria-brailleroledescription