Provide non-braille equivalents for braille ARIA attributes
Accessibility isn’t only about avoiding violations — it’s about ensuring your product can be used confidently by everyone. This guide explains the principle of this rule, shows what goes wrong in real-world code, and provides a verified fix that meets WCAG and the European Accessibility Act (EAA).
Why this matters and how to fix it
Why this matters
Some assistive technologies display information through refreshable braille devices. ARIA braille attributes, such as aria-braillelabel or aria-brailleroledescription, provide specific text for these devices. However, when they are used without matching non-braille equivalents, other assistive technologies like screen readers may not receive the same information. This creates an unequal experience between users of different assistive technologies, potentially leaving critical information inaccessible.
How to fix this issue
Ensure that any element using braille-specific ARIA attributes also includes a visible or standard accessible label. This can be achieved by adding aria-label, aria-labelledby, or aria-roledescription alongside the braille attribute. Review component templates and ensure parity between braille and non-braille descriptors so all users receive equivalent information.
Developer guidance
Developers often overlook braille-specific attributes because they’re uncommon in typical testing workflows. However, enterprise-grade accessibility requires inclusive coverage for all assistive technologies. Ensure your accessibility QA process verifies parity between braille attributes and text-based equivalents. If your team does not use braille hardware, consult the WAI-ARIA specification to simulate or validate expected behavior.
Code examples
Incorrect Implementation
<div aria-braillelabel="OK"></div>Correct Implementation
<div aria-braillelabel="OK" aria-label="OK"></div>
Trusted by organizations across Europe working toward WCAG and EAA conformance