ARIA: Gift oder Gegenmittel?

Was ist ARIA?

Mit ARIA können Webentwickler eine alternative Realität schaffen, die nur von Screenreadern gesehen wird.

Manchmal ist es notwendig, Screenreadern mehr zu erzählen oder ihnen sogar direkt „Lügen“ zu erzählen, um ihnen zu erklären, was in den Webinhalten passiert. Beispiel: „Der Fokus liegt hier!“ oder „Das ist wirklich ein Schieberegler!“ Es ist, als würden Sie magische Haftnotizen auf Tools und Widgets auf Ihrer Werkbank kleben. Diese magischen Haftnotizen lassen alle glauben, was darauf steht.

Wenn eine solche Haftnotiz existiert, überschreibt sie entweder unsere Überzeugung darüber, was das jeweilige Tool ist oder was es tut. Beispiel: Sie fügen ARIA hinzu, das besagt: „Dieses Ding hier ist eine Heißklebepistole!“ Auch wenn es sich um eine leere blaue Kiste handelt, erfahren wir durch die magische Notiz, dass es sich um eine Heißklebepistole handelt. Wir können auch hinzufügen: „und es ist zu 30 % gefüllt“. Der Screenreader meldet jetzt, dass sich eine Vollklebepistole zu 30% befindet.

Im Web entspricht dies einem einfachen div mit einem Bild darin, bei dem mit ARIA angegeben wird, dass es sich um einen Schieberegler mit dem Wert 30 von 100 handelt. ARIA macht das div nicht zu einem Schieberegler, sondern weist den Screenreader nur an, es als solchen anzusagen.

ARIA hat keine Auswirkungen auf das Erscheinungsbild einer Webseite oder das Verhalten für Nutzer mit Maus oder Tastatur. Nur Nutzer von Hilfstechnologien bemerken die Auswirkungen von ARIA. Webentwickler können beliebige ARIA-Angaben hinzufügen, ohne dass dies Auswirkungen auf Nutzer hat, die keine Hilfstechnologien verwenden.

Sie haben richtig gelesen: ARIA hat keinen Einfluss auf den Tastaturfokus oder die Tabulatorreihenfolge. Das geschieht alles in HTML, manchmal mit ein paar JavaScript-Snippets.

Wie funktioniert ARIA?

Browser werden von einem Screenreader oder einer anderen Hilfstechnologie um Informationen zu jedem Element gebeten. Wenn ARIA für ein Element vorhanden ist, nimmt der Browser die Informationen auf und ändert, was er dem Screenreader über dieses Element mitteilt.

Im Folgenden sind einige gängige Anwendungsfälle von ARIA aufgeführt.

• Fügen Sie spezielle Komponenten hinzu, die in HTML nicht vorhanden sind, z. B. Autocomplete, einen Baum oder eine Tabelle.
• Es werden Komponenten hinzugefügt, die in HTML vorhanden sind, die der Autor aber neu erfinden wollte, möglicherweise weil er das Verhalten oder Aussehen des Standardelements ändern wollte. Ein HTML-<input type="range">-Element ist beispielsweise im Grunde ein Schieberegler, aber die Autoren möchten, dass er anders aussieht.
  • In den meisten Fällen lässt sich dies mit CSS beheben. Bei range ist CSS jedoch etwas umständlich. Autoren können ihren eigenen Schieberegler erstellen und role="slider" mit aria-valuenow verwenden, um der Tastatur den aktuellen Wert mitzuteilen.
• Fügen Sie Live-Regionen hinzu, um Screenreader über relevante Änderungen an einem Bereich einer Seite zu informieren.
• Erstellen Sie Markierungen wie Überschriften. Markierungen helfen Nutzern von Screenreadern, schneller das Gesuchte zu finden. Sehenswürdigkeiten können einen ganzen zugehörigen Bereich umfassen. Beispiel: „Dieser Container ist der Hauptbereich der Seite“ und „Dieser Container hier ist ein Navigationsbereich“.

Warum ARIA?

Es kann hilfreich sein, HTML-Code ARIA hinzuzufügen, die bereits funktioniert. So kann ein Formularkontrollelement beispielsweise auf eine Fehlermeldung bei ungültiger Eingabe verweisen. Oder wir möchten die spezifische Verwendung einer Texteingabe angeben. Mit diesen Optimierungen können normale Websites mit einem Screenreader besser genutzt werden.

Beispiel für eine Menüleiste

Angenommen, der lokale Webshop verkauft nicht alle benötigten Widgets. Aber wir sind MacGyver. Wir können einfach unsere eigenen Widgets aus anderen Widgets erfinden! Das ist ziemlich ähnlich wie bei einem Webentwickler, der eine Menüleiste erstellen muss.

Das <nav>-Element ist zwar vorhanden, aber die Menüleisten werden oft mit Divs, Bildern, Schaltflächen, Klick-Handlern, Tastendruck-Handles und ARIA zusammengebaut.

Unterstützung für Mausnutzer

Erstellen wir nun eine Menüleiste. Wir zeigen eine Reihe von Elementen in generischen Box-Elementen, die als Divs bezeichnet werden. Jedes Mal, wenn der Nutzer auf ein Div klickt, wird der entsprechende Befehl ausgeführt. Cool, es funktioniert für Nutzer mit Mausklicks.

Als Nächstes machen wir es hübsch. Wir verwenden CSS, um Elemente schön auszurichten und visuelle Umrisse zu setzen. Wir lassen sie ähnlich aussehen wie andere Menüleisten, bei denen Sichtende intuitiv erkennen, dass es sich um eine Menüleiste handelt und wie sie verwendet wird. In unserer Menüleiste wird sogar für jedes Element, auf das der Mauszeiger zeigt, eine andere Hintergrundfarbe verwendet, was den Nutzern hilfreiches visuelles Feedback gibt.

Einige Menüpunkte sind übergeordnet. Sie erzeugen untergeordnete Untermenüs. Jedes Mal, wenn der Nutzer den Mauszeiger auf eine davon bewegt, wird eine Animation gestartet.

Das ist alles ziemlich unzugänglich, wie es bei vielen Dingen im Web üblich ist.

Menüleiste für die Tastatur zugänglich machen

Fügen wir „Bedienungshilfen“ für die Tastatur hinzu. Dazu sind nur HTML-Änderungen erforderlich, keine ARIA-Änderungen. Denken Sie daran, dass ARIA keine Auswirkungen auf grundlegende Aspekte wie Erscheinungsbild, Maus oder Tastatur für Nutzer ohne Hilfstechnologien hat.

Genau wie eine Webseite auf die Maus reagieren kann, kann sie auch auf die Tastatur reagieren. Unser JavaScript kann alle Tastenanschläge erfassen und entscheiden, ob die Tastenaktivierung sinnvoll ist. Andernfalls wird er auf die Seite zurückgegeben wie ein Fisch, der zu klein zum Essen ist. Unsere Regeln sind in etwa so:

• Wenn der Nutzer eine Pfeiltaste drückt, sehen wir uns unsere internen Entwürfe der Menüleisten an und entscheiden, wie das neue aktive Menüelement aussehen soll. Wir entfernen alle aktuellen Hervorhebungen und markieren den neuen Menüpunkt, damit sehende Nutzer visuell erkennen können, wo sie sich befinden. Die Webseite sollte dann event.preventDefault() aufrufen, um zu verhindern, dass der Browser die übliche Aktion ausführt (in diesem Fall das Scrollen der Seite).
• Wenn der Nutzer die Taste Eingabetaste drückt, können wir dies wie einen Klick behandeln und die entsprechende Aktion ausführen oder sogar ein anderes Menü öffnen.
• Wenn der Nutzer eine Taste drückt, die eine andere Aktion auslösen sollte, leiten Sie ihn zurück zur Seite. Für unsere Menüleiste ist beispielsweise die Taste Tab nicht erforderlich. Das ist nicht einfach. Die Menüleiste benötigt beispielsweise die Pfeiltasten, aber nicht Alt + Pfeil oder Befehlstaste + Pfeil. Das sind Tastenkürzel, mit denen Sie zum vorherigen und zum nächsten Eintrag im Webverlauf Ihres Browsertabs wechseln können. Wenn der Autor nicht aufpasst, werden diese von der Menüleiste verschluckt. Diese Art von Fehlern kommt häufig vor und wir haben noch nicht einmal mit ARIA begonnen.

Screenreader-Zugriff auf die Menüleiste

Unsere Menüleiste wurde mit Klebeband und divs erstellt. Ein Screenreader kann daher nicht erkennen, was es ist. Die Hintergrundfarbe des aktiven Elements ist nur eine Farbe. Die Divs für die Menüpunkte sind einfache Objekte ohne besondere Bedeutung. Daher erhält ein Nutzer unserer Menüleiste keine Anleitung dazu, welche Tasten er drücken muss oder auf welchem Element er sich befindet.

Aber das ist nicht fair! Die Menüleiste funktioniert für den sehenden Nutzer einwandfrei.

ARIA kommt zur Rettung. Mit ARIA können wir dem Screenreader vortäuschen, dass sich der Fokus in einer Menüleiste befindet. Wenn der Autor alles richtig macht, sieht unsere benutzerdefinierte Menüleiste für den Screenreader genauso aus wie eine Menüleiste in einer Desktopanwendung.

Das erste ARIA-Attribut ist das aria-activedescendant-Attribut. Legen Sie für das Attribut die ID des aktiven Menüpunkts fest und achten Sie darauf, das Attribut bei jeder Änderung zu aktualisieren. Beispiel: aria-activedescendant="settings-menuitem" Dies führt dazu, dass der Screenreader unser aktives ARIA-Element als Fokus betrachtet, das vorgelesen oder auf einer Braillezeile angezeigt wird.

Wenn der Nutzer mit aria-activedescendant von der fokussierten Menüleiste auf einen bestimmten Menüpunkt zeigt, weiß der Screenreader jetzt, wohin sich der Nutzer bewegt hat, aber nichts anderes über das Objekt. Was ist das div-Element überhaupt? Hier kommt das Attribut „Rolle“ ins Spiel. Wir verwenden role="menubar" für das gesamte enthaltende Element, dann role="menu" für Gruppen von Elementen und role="menuitem" für… Trommelwirbel… die einzelnen Menüpunkte.

Was ist, wenn der Menüpunkt zu einem untergeordneten Menü führen kann? Das muss der Nutzer wissen. Für sehende Nutzer wird am Ende des Menüs möglicherweise ein kleines Dreieck angezeigt. Der Screenreader kann Bilder jedoch zumindest derzeit nicht automatisch vorlesen. Wir können jedem maximierbaren Menüpunkt das Symbol aria-expanded="false" hinzufügen, um anzuzeigen, dass etwas maximiert werden kann und es nicht maximiert ist. Außerdem sollte der Autor role="none" im Dreieck img platzieren, um anzugeben, dass es nur für Beauty-Zwecke gedacht ist. So wird verhindert, dass der Screenreader redundante Informationen zum Bild vorliest.

Tastaturfehler beheben

Der Tastaturzugriff ist zwar Teil des Kern-HTML, lässt sich aber leicht überschreiben. Beispiel:

• Ein Kästchen kann mit der Leertaste aktiviert und deaktiviert werden, aber der Autor hat vergessen, preventDefault() aufzurufen. Jetzt kann mit der Leertaste sowohl das Kästchen aktiviert und deaktiviert als auch die Seite nach unten bewegt werden. Das ist das Standardverhalten des Browsers für die Leertaste.
• In einem modalen ARIA-Dialogfeld soll die Tabulatornavigation eingeblendet werden. Wenn der Autor vergisst, die Tastenkombination Strg + Tab zuzulassen, um im Dialogfeld einen neuen Tab zu öffnen, funktioniert das nicht wie erwartet.
• Ein Autor erstellt eine Auswahlliste und implementiert die Tasten „Hoch“ und „Runter“. Der Autor muss jedoch weiterhin die Navigationselemente „Pos1“, „Ende“, „Seitenanfang“, „Seitenende“ oder „Erster Buchstabe“ hinzufügen.

Autoren sollten bekannten Mustern folgen. Weitere Informationen finden Sie im Abschnitt Ressourcen.

Bei reinen Tastaturzugriffsproblemen ist es sinnvoll, es auch ohne Screenreader oder bei deaktiviertem virtuellen Browsermodus zu testen. Fehler auf der Tastatur lassen sich auch ohne Screenreader erkennen, da der Tastaturzugriff mit HTML und nicht mit ARIA implementiert wird. ARIA hat schließlich keine Auswirkungen auf das Verhalten der Tastatur oder Maus. Stattdessen täuscht es dem Screenreader vor, was sich auf der Webseite befindet, was gerade der Fokus ist usw.

Tastaturfehler sind fast immer ein Fehler im Webcontent, insbesondere in HTML und JavaScript, nicht in ARIA.

Warum gibt es so viele?

Es gibt viele Möglichkeiten, wie Autoren ARIA falsch anwenden können. Jeder Fehler führt entweder zu einem kompletten Absturz oder zu subtilen Unterschieden. Die subtilen Probleme sind möglicherweise schlimmer, da der Autor sie vor der Veröffentlichung wahrscheinlich nicht bemerkt.

Schließlich wird es bei der ARIA-Programmierung zu Fehlern kommen, es sei denn, der Autor ist ein erfahrener Screenreader-Nutzer. In unserem Beispiel für die Menüleiste könnte der Autor der Meinung sein, dass die Rolle „option“ verwendet werden sollte, wenn „menuitem“ richtig ist. Er könnte vergessen, aria-expanded zu verwenden, aria-activedescendant nicht zur richtigen Zeit festzulegen und zu löschen oder eine Menüleiste mit den anderen Menüs zu vergessen. Und wie sieht es mit der Anzahl der Menüpunkte aus? Normalerweise werden Menüpunkte von Screenreadern mit etwas wie „Punkt 3 von 5“ dargestellt, damit der Nutzer weiß, wo er sich befindet. In der Regel wird dies vom Browser automatisch gezählt. In einigen Fällen und in einigen Browser-/Screenreader-Kombinationen werden jedoch möglicherweise die falschen Zahlen berechnet und der Autor müsste diese Zahlen mit aria-posinset und aria-setsize überschreiben.

Und das sind nur die Menüleisten. Denken Sie daran, wie viele Arten von Widgets es gibt. Sehen Sie sich die ARIA-Spezifikation oder die Best Practices für die Erstellung an. Für jedes Muster gibt es Dutzende Möglichkeiten, wie ARIA missbraucht werden kann. Bei ARIA müssen die Autoren wissen, was sie tun. Was kann schiefgehen, da die meisten Autoren keine Screenreader-Nutzer sind?

Mit anderen Worten: Es ist absolut notwendig, dass ARIA-Widgets von Nutzern mit Screenreadern getestet werden, bevor sie als produktionsreif eingestuft werden. Das sind zu viele Nuancen. Aufgrund der zahlreichen Fehler bei der Implementierung sowie einiger unvollständiger Implementierungen sollten Sie idealerweise alles mit verschiedenen Kombinationen aus Browser und Screenreader ausprobieren.

Zusammenfassung

Mit ARIA können Sie alles in der HTML-Datei überschreiben oder ergänzen. Sie können damit kleine Änderungen an der Barrierefreiheit vornehmen oder eine vollständige Umgebung erstellen. Aus diesem Grund ist ARIA sowohl unglaublich leistungsstark als auch gefährlich in den Händen unserer Entwickler, die keine Screenreader-Nutzer sind.

ARIA ist eine Markup-Ebene, die andere Optionen überschreibt. Wenn ein Screenreader fragt, was passiert, und wenn ARIA vorhanden ist, erhält der Nutzer die ARIA-Version der Wahrheit.

Zusätzliche Ressourcen

In den ARIA-Autorisierungspraktiken des W3C werden die wichtigen Merkmale der Tastaturnavigation für jedes Beispiel dokumentiert und es werden funktionierende JavaScript-, CSS- und ARIA-Codes bereitgestellt. Die Beispiele konzentrieren sich auf das, was heute funktioniert, und umfassen keine Mobilgeräte.

Was ist eine API für Barrierefreiheit?

Über eine Bedienungshilfen-API erfahren Screenreader oder andere Hilfstechnologien, was auf der Seite zu sehen ist und was passiert. Beispiele hierfür sind MSAA, IA2 und UIA. Eine Accessibility API besteht aus zwei Teilen:

• Ein „Baum“ von Objekten, der eine Containerhierarchie darstellt. Ein Dokument kann beispielsweise mehrere Absätze enthalten. Ein Absatz kann Text, Bilder, Links und Textdekorationen enthalten. Jedes Element in der Objektstruktur kann Attribute wie die Rolle (was bin ich), einen Namen oder ein Label, einen vom Nutzer eingegebenen Wert, eine Beschreibung und boolesche Statuswerte wie „fokussierbar“, „fokussiert“, „erforderlich“ und „ausgewählt“ haben. ARIA kann alle diese Eigenschaften überschreiben.
  • Screenreader verwenden die Baumstruktur, um Nutzern die Navigation im virtuellen Puffermodus zu erleichtern, z. B. „Gehe bitte zur nächsten Überschrift“.
• Eine Reihe von Ereignissen, die Änderungen am Baum beschreiben, z. B. „Der Fokus liegt jetzt hier!“ Der Screenreader informiert den Nutzer anhand von Ereignissen darüber, was gerade passiert ist. Wenn sich wichtiges HTML- oder ARIA-Markup ändert, wird ein Ereignis ausgelöst, um den Screenreader darüber zu informieren, dass sich etwas geändert hat.

HTML lässt sich gut auf diese APIs für Barrierefreiheit abbilden. Wenn HTML nicht ausreicht, kann ARIA hinzugefügt werden, damit der Browser die HTML-Semantik überschreibt, bevor der Objektbaum oder die Ereignisse an den Screenreader gesendet werden.