A: aria-braille Attribute müssen ein non-braille Äquivalent haben (WCAG 4.1.2)

• Bedeutung
• Auswirkung
• Empfehlung
• Beispiele

Stellt sicher, dass aria-braillelabel und aria-brailleroledescription ein non-braille Äquivalent haben.

Das bedeutet

Wenn ein Element nur über Braille-Attribute benannt/beschrieben wird, fehlt anderen Assistive-Technologien (Sprachausgabe, Vergrößerung, Switch-Control) die entsprechende non-Braille-Information.

• aria-braillelabel braucht ein normales Accessible Name-Pendant (z. B. sichtbarer Text, aria-label oder aria-labelledby).
• aria-brailleroledescription braucht das non-Braille-Gegenstück aria-roledescription.

Auswirkung

Ohne non-Braille-Äquivalent sind Name/Rolle unvollständig: Screenreader sprechen nichts Sinnvolles, Fokusnavigation wird unklar → Risiko für Fehlbedienungen und WCAG-Verstoß.

Empfehlung

• Accessible Name immer auch non-Braille bereitstellen: sichtbarer Text, aria-label oder aria-labelledby.
• Falls nötig, Rollentext zusätzlich non-Braille setzen: aria-roledescription.
• Konsistenz: Braille- und non-Braille-Strings sollten übereinstimmen.
• Native HTML bevorzugen (z. B. <button>, <a>) und aria-roledescription sparsam einsetzen (nicht zur Änderung der eigentlichen Rolle verwenden).

Beispiel

Problematisch

<button aria-braillelabel="Absenden"></button>               <!-- kein non-braille Name -->
<div role="tab" aria-brailleroledescription="Register"></div> <!-- kein non-braille roledescription -->

Besser

<!-- Accessible Name vorhanden + Braille-Pendant -->
<button aria-label="Absenden" aria-braillelabel="Absenden"></button>
 
<!-- Rollenbeschreibung non-braille + Braille-Pendant -->
<div role="tab"
     aria-roledescription="Register"
     aria-brailleroledescription="Register">Profil</div>

Alternativ (sichtbarer Text statt aria-label)

<button aria-braillelabel="Absenden">Absenden</button>

Verknüpfte WCAG-Kriterien:
WCAG 4.1.2 – Name, Rolle, Wert