Barrierefreiheit für individuell definierte Elemente

Benutzerdefinierte Elemente richtig anwenden

Die barrierefreie also problemlose Nutzung einer Website für einen Besucher, der auf eine Bedienungshilfe angewiesen ist, stellt gerade bei der Definition von individuellen Web-Elementen eine Herausforderung dar. Browser müssen die Semantik des Codes verstehen, um der Hilfstechnologie korrekte Informationen kommunizieren zu können.

Ein Bildschirmlese-Tool, das sehbehinderten Menschen das „Lesen“ und Navigieren einer Website ermöglicht, liest den Code einer Website, verarbeitet diesen und gibt dem Benutzer dann über die Sprachausgabe die Informationen über das angewählte Element aus. Der entsprechende Code für einen einfachen Login-Button lautet beispielsweise

Und die Bildschirmlesehilfe kann hier korrekt zurückgeben „Button: Einloggen“. Der Nutzer weiß dadurch, welches Element er ausgewählt hat und welche Aktionen möglich sind. In diesem Fall kann er den Button anwählen, um zum Login zu gelangen.

Standard-Elemente können nicht nur von einer Bedienungshilfe in der Regel problemlos interpretiert werden, sondern lassen auch eine Navigation per Tastatur zu. Dies ist entscheidend für die barrierefreie Nutzung für User, die keine Maus oder anderes optisches Auswahlgerät verwenden können.

Benutzerdefinierte Elemente können nicht interpretiert werden

Benutzerdefinierte Elemente fehlt die Semantik, um vom Bildschirmleser interpretiert werden zu können und sie gewährleisten auch die Tastaturnavigation nicht. Definiert man also einen neuen, individuellen Tag, kann der Browser nicht interpretieren, ob es sich dabei um einen Button, Slider oder nur um einen Text-Container handelt.

Standard-Elemente erfüllen jedoch nur selten die Anforderungen und Wünsche, die man als Web-Entwickler an Optik und Funktion hat. Für das barrierefreie Definieren und Einfügen individueller Elemente gilt es allerdings, einiges zu beachten. Als Grundlage dient in jedem Fall der ARIA Authoring Practices Guide, um die individuelle Definition von Web-Elementen vorzunehmen.

Barrierefreie Integration von benutzerdefinierten Elementen

Das Stylen von Standard-Elementen kann schon ohne das Berücksichtigen der Barrierefreiheit unkomfortabel sein. In der Regel verwendet man hier schon relativ erfinderische Verschachtelungen von Code. Damit auch Bedienungshilfen das Styling verarbeiten können und in der Lage sind, das richtige Element zu kommunizieren, bedarf es noch weiteren Aufwands. Das Hinzufügen eines aria-label mit einem eindeutigen Label-Text, der von Hilfstechnologien ausgelesen werden kann, gehört dabei zu den einfachen Schritten.

Da eine barrierefreie Semantik der individuell definierten Elemente mit Aufwand und teilweise auch Grenzen verbunden ist, entscheiden viele Web-Entwickler, darauf zu verzichten und Elemente frei und ganz nach Ihren Wünschen und Anforderungen zu gestalten. Im Ergebnis entstehen so Websites mit vielen ansprechend und individuell gestylten Elementen, die aber Nutzern mit Bedienungshilfen schwerlich bis gar nicht zugänglich sind.

Barrierefreiheit durch Einbinden mittels Web API

Je nach System sind oder nicht immer im Sinne eines regulären DOM-Elements implementiert. Sie werden jedoch sehr häufig verwendet, weshalb es auch unzählige Beiträge gibt, die erklären, wie sie mithilfe von CSS gestaltet werden können. Manchmal werden sie direkt vom Betriebssystem gerendert und erscheint wie jede andere native Dropdown-Liste auch. Die Darstellung und damit Interpretation dieser Elemente wird dem Browser überlassen und ein 100 % sicheres Styling daran zu knüpfen, ist unmöglich.

Alternativ können diese Elemente als performante neue Web APIs eingebunden werden. Das macht nicht nur die Gestaltung bestehender Elemente wie und wesentlich flexibler, sondern auch Erweiterungen wie sind denkbar.

Dieses Vorgehen ermöglicht es, auf das mühselige Stylen mit CSS zu verzichten. So können Elemente individuell definiert werden, ganz nach unseren Wünschen und Anforderungen und zudem auch barrierefrei. Die Entscheidung entweder Standard-Elemente umfassend und aufwendig per CSS zu stylen oder aber im Umkehrschluss für jedes benutzerdefinierte Element die Barrierefreiheit gegebenenfalls nachzutragen, entfällt damit.

Accessibility Object Model (AOM) unterstützt Barrierefreiheit

Das neue Accessibility Object Model (AOM) hat das Potenzial, umfassend bei einer korrekten Semantik und Nomenklatur für die benutzerdefinierten Elemente zu unterstützen. Mit AOM lässt sich die Semantik der Elemente direkt im Accessibility-Tree definieren.

Da ARIA ausschließlich eine HTML-Attribute-API ist, müssen wir das DOM jedes Mal anfassen, wenn wir unsere Semantik aktualisieren wollen. Für ein einzelnes Element kann dieser Aufwand noch tragbar sein. Bei einer Vielzahl von anzusprechenden Elementen, kann es dann aber schnell zu Performance-Einbußen kommen.

Mit AOM kann einem Element innerhalb des Constructors die Semantik einfach zugeordnet werden.

Bei der Verwendung von ARIA müssen alle Element-Beziehungen mit entsprechenden ID-Referenzen definiert werden. Auch hier ist eine Definition für einzelne Elemente machbar - bei einer größeren Zahl kommt hier vermehrter Koordinationsaufwand der ID-Referenzen auf. Teilweise ist dies dann nur noch automatisiert möglich.

Neue Standards wie „Shadow DOM“ schaffen darüber hinaus Scoping-Grenzen für IDs. AOM löst dies, indem es erlaubt, Beziehungen mithilfe von Objektreferenzen aufzubauen.

Die accessibleNodes entstehen aus Verweisen zu andere Elemente des betreffenden Web-Projekts und das automatisiertes Generieren von IDs entfällt.

„Benutzerdefinierte Standard-Elemente“

Ein Gegenentwurf zum Hinzufügen der Semantik ist das Vererben der Eigenschaften durch die vorhandenen Standard-Elemente. Dies hat man als „benutzerdefinierte Standard-Elemente“ bezeichnet. Mit diesen benutzerdefinierten Standard-Elementen kann mit den Eigenschaften und Methoden der HTMLInputElement Schnittstelle und.

Leider wird diese Methode nicht durchgängig von den heutigen Browsern unterstützt, da sie in der tatsächlichen Umsetzung vielfach problematisch ist. Möchte man von einem Element vererben und fügt dann noch die eigene „shadow root“ hinzu, hebelt dies das Standard-Styling und Verhalten des Elements aus. Da man aber primär natürlich den Style des Elements definieren möchte, kommt man hier zu keinem zufriedenstellenden Ergebnis.

Zukunft des barrierefreien Designs

Diese Überlegungen und Problematiken gelten nicht nur alleine für Standard-Elemente, sondern letztlich betrifft dies alle Web-Components. So sollten alle gleichermaßen von Neuerungen wie AOM profitieren. Denn angepasste, individuell definierte Elemente sind die einzige Möglichkeit, Komponenten zu schaffen, die von verschiedenen Frameworks gemeinsam genutzt werden können.