ARIA
Braille labels need a plain-text equivalent
- Rule:
aria-braille-equivalent - Severity: Serious
- WCAG level A
Why it matters
aria-braillelabel and aria-brailleroledescription are only read on a braille display. Without a matching aria-label the control has no name at all for anyone using speech.
How to fix it
- Add aria-label (or aria-roledescription) alongside the braille attribute.
- Keep the two in agreement: the braille version abbreviates the same name, it does not say something different.
- Drop the braille attribute entirely if you do not have a specific reason for it — a plain label works everywhere.
In markup
<button aria-braillelabel="Sv">Save</button><button aria-label="Save" aria-braillelabel="Save">Save</button>The requirement behind it
This rule is one way of failing the following WCAG 2.2 success criteria. The W3C, which writes the standard, explains each of them:
- 4.1.2 Name, Role, Value (opens in new tab) — WCAG level A
Further reading
Deque University on aria-braille-equivalent (opens in new tab)
Deque maintains axe-core, the open-source engine our scanner runs. Their page documents the rule as the engine implements it.
Automated checks find failures a browser can prove. They cannot judge whether a caption is accurate, whether an alt text is useful, or whether a page can be operated end to end with a keyboard — those need a person.