A: aria-braille attributes must have a non-braille equivalent (WCAG 4.1.2)

• Meaning
• Impact
• Recommendation
• Examples

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

This means

If an element is named/described only via braille attributes, other assistive technologies (screen readers, magnifiers, switch control) lack the corresponding non-braille information.

• aria-braillelabel requires a normal accessible name counterpart (e.g., visible text, aria-label or aria-labelledby).
• aria-brailleroledescription requires the non-braille counterpart aria-roledescription.

Impact

Without a non-braille equivalent, name/role are incomplete: screen readers say nothing meaningful, focus navigation becomes unclear → risk of misuse and WCAG violation.

Recommendation

• Always provide an accessible name also non-braille: visible text, aria-label or aria-labelledby.
• If necessary, provide role text additionally non-braille: aria-roledescription.
• Consistency: Braille and non-braille strings should match.
• Prefer native HTML (e.g., <button>, <a>) and use aria-roledescription sparingly (do not use to change the actual role).

Example

Problematic

<button aria-braillelabel="Submit"></button>               <!-- no non-braille name -->
<div role="tab" aria-brailleroledescription="Register"></div> <!-- no non-braille roledescription -->

Better

<!-- Accessible name present + braille counterpart -->
<button aria-label="Submit" aria-braillelabel="Submit"></button>
 
<!-- Role description non-braille + braille counterpart -->
<div role="tab"
     aria-roledescription="Register"
     aria-brailleroledescription="Register">Profile</div>

Related WCAG criterion:
WCAG 4.1.2 - Name, Role, Value