ARIA-Attribute für die Braille-Ausgabe
Viele, die sich intensiv mit digitaler Barrierefreiheit beschäftigen, sind mit aria-label, aria-labelledby oder aria-describedby vertraut. aria-braillelabel und aria-brailleroledescription sind hingegen eher wenig bekannt. Im folgenden Artikel stellen wir die beiden vergleichsweise neuen Attribute mal vor.
ARIA zur Optimierung der Braille-Ausgabe
Bislang existierte keine Möglichkeit, die Braille-Ausgabe separat zu optimieren. Der sogenannte zugängliche Name (Accessible Name) eines Elements – zum Beispiel aus sichtbarem Text oder aria-label – wird ohne besondere Optimierung sowohl in der Sprachausgabe als auch auf der Braillezeile weitgehend identisch ausgegeben. Dasselbe gilt für Rollenbeschreibungen. Hier kommen aria-braillelabel und aria-brailleroledescription ins Spiel. Diese beiden Attribute ermöglichen es jetzt, für Braillezeilen gezielt kompakte oder fachspezifische Texte bereitzustellen, ohne dabei die ausführlichere Sprachausgabe zu verändern.
Braille-Ausgabe versus Sprachausgabe
Versteckte Zusatz-Informationen, wie zum Beispiel „Nachricht senden und Fenster schließen“ können in der Sprachausgabe sinnvoll sein und für hilfreichen Kontext zur Orientierung sorgen. Die Länge von Texten und Zusatz-Informationen spielt dabei in der Sprachausgabe eine eher untergeordnete Rolle, weil sie durch eine erhöhte Sprechgeschwindigkeit der Sprachausgebe kompensiert werden kann. Gerade erfahrene Screenreader-Nutzende erhöhen die Sprechgeschwindigkeit der Sprachausgabe oft drastisch.
Die Ausgabe auf einer Braillezeile funktioniert hingegen anders und ist durch die Anzahl der verfügbaren Zeichen räumlich begrenzt (üblich sind 40 oder 80 Zeichen). Diese physische Grenze lässt sich nicht über Einstellungen verändern. Man kann zwar ggf. schneller lesen, aber man kann nicht mehr Zeichen gleichzeitig anzeigen. Zusatz-Informationen führen also zunächst einmal zu einem erhöhten Aufwand auf der Braille-Ausgabe. Was in der Sprachausgabe also vielleicht gut ist, kann in der Braille-Ausgabe störend wirken. Dieser Zielkonflikt ließ sich bisher nicht lösen.
Kompaktere Informationen in der Braille-Ausgabe
Um beim zuvor genannten Beispiel zu bleiben: ein Button mit aria-label="Nachricht senden und Fenster schließen" könnte zusätzlich ein aria-braillelabel="Senden" tragen. Die Audioansage bliebe dann ausführlich, auf der Braillezeile erschiene dann aber nur die komprimierte Variante. aria-brailleroledescription funktioniert analog für Rollenbeschreibungen. Eine bereits vorhandene und mit aria-roledescription formulierte Rolle kann für die Braille-Ausgabe verkürzt oder angepasst werden.
Einsatzmöglichkeiten der Braille-Optimierung
Es gibt für aria-braillelabel und aria-brailleroledescription durchaus sinnvolle Einsatzszenarien, allerdings nur in relativ klar umrissenen Situationen. Ein vielleicht gut nachvollziehbares Anwendungsbeispiel wäre ein digitales Schachbrett, bei dem ein aria-label eine detaillierte Sprachausgaben wie „Schwarzer Springer auf Feld C3“ ermöglicht, während das aria-braillelabel="sS C3" die Ausgabe auf der Braillezeilen optimiert. Korrespondierend funktioniert das dann zum Beispiel mit aria-roledescription="Spielfeld" und aria-brailleroledescription="Fld". Das Konzept funktioniert, weil Braille-Nutzende daran gewöhnt sind, Informationen verdichtet aufzunehmen (vergleichbar mit Stenografie oder Kürzeln, wie ROFL oder AFK). Aus diesem Grund „fliegen“ Füllwörter meist ganz raus und normale Worte werden auf ihre prägnanten Konsonanten reduziert (z. B. Fld statt Feld).
Es gibt allerdings keinen fest definierten Standard, der vorschreibt, dass "sS" für "schwarzer Springer" stehen muss. Die Wahl dieser Abkürzungen basiert auf Konventionen innerhalb der Zielgruppe und Nutzer-Tests.
Tatsächlich gibt es aber auch bereits sogenannte Braille-Codes, also spezialisierte Notationen, die über das normale Alphabet hinausgehen. Solche Braille-Codes werden zum Beispiel eingesetzt, um komplexe Inhalte wie Mathematik, Musik oder Informatik platzsparend und eindeutig auf Braillezeilen darzustellen. Beispiele dafür sind Nemeth-Code und Kurzbraille: Aus „Ich kann jetzt nicht“ wird dann zum Beispiel in der 6-Punkt-Lautschrift zum Beispiel: # k j n.
Technische Unterstützung
Moderne Browser-Engines unterstützen die entsprechenden Eigenschaften inzwischen wohl gut. WebKit nennt die Unterstützung in Safari 18 ausdrücklich, und auch Chromium-basierte Browser sowie Firefox haben die entsprechenden Schnittstellen implementiert. Entscheidend ist allerdings die gesamte Kette: Browser, Accessibility-Schnittstellen, Screenreader und Braille-Treiber müssen hier zusammenspielen. Jaws und NVDA unterstützen die Attribute nach meiner Recherche aber auch schon seit einiger Zeit.
Begrenzte Bekanntheit der Braille-Optimierung
Es gibt mehrere Gründe, weshalb aria-braillelabel und aria-brailleroledescription selbst in Fachkreisen nur wenig präsent sind. Manuelle Accessibility-Audits berücksichtigen zwar in der Regel auch Tests mit Screenreader-Sprachausgabe, aber eine gesonderte Betrachtung der Braille-Ausgabe findet zumeist nicht statt. Ein weiterer Grund, warum die beiden ARIA-Attribute derzeit noch exotisch sind, hat mit dem aktuellen Status der zugrundeliegenden Spezifikationen zu tun. Derzeit befindet sich ARIA 1.3 noch im Working-Draft-Stadium, weshalb gängige Best Practice Pattern und Tutorials neuere Attribute noch gar nicht abbilden. Last but not least lässt sich die Wirkung der Attribute auf dem Bildschirm ohne Braillezeile oder Braille-Viewer derzeit nicht erkennen. NVDA stellt zwar einen integrierten Braille-Viewer bereit, mit dem sich die Ausgabe simulieren lässt, aber ohne tiefgreifendes Verständnis von Brailleschrift und Kurzbraille bringt das letztendlich auch nichts.
Risiken und Grenzen der Braille-Optimierung
Obwohl die genannten Beispiele das theoretische Potenzial von aria-braillelabel und aria-brailleroledescription aufzeigen, ist die Verwendung dieser beiden Attribute aus meinr Sicht in der Praxis mit hohen Risiken verbunden. Ein sinnvoller Einsatz ist fast ausschließlich auf komplexe Fachanwendungen oder spezialisierte Widgets begrenzt. Und selbst dort sollte eine Braille-Optimierung aus meiner Sicht nur unter Einbeziehung der Zielgruppe angegangen werden. In gängigen Web-Interfaces sollte man auf diese Attribute besser verzichten und keine Experimente wagen. Es ist wie so oft mit ARIA, eine zusätzliche Schicht erhöht die Komplexität und Fehleranfälligkeit und kein ARIA ist besser als fehlerhaft implementiertes ARIA.
