ARIA: Gift oder Gegenmittel?

Aaron Leventhal

Was ist ARIA?

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

Manchmal ist es notwendig, Screenreadern mehr zu erzählen oder ihnen sogar direkt zu „lügen“, 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 es eine magische Haftnotiz gibt, überschreibt sie entweder unsere Vorstellung davon, was jedes Tool ist oder tut. Beispiel: Sie fügen ARIA hinzu, das besagt: „Dieses Ding hier ist eine Heißklebepistole!“ Obwohl 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 die Klebepistole zu 30% gefüllt ist.

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 alles geschieht 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 kann dies mit CSS behoben werden. Bei range ist CSS jedoch etwas umständlich. Autoren können ihren eigenen Schieberegler erstellen und mit role="slider" und aria-valuenow der Tastatur den aktuellen Wert mitteilen.
• 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 nützlich sein, HTML-Elementen, die bereits funktionieren, ARIA-Angaben hinzuzufügen. So kann ein Formularkontrollelement beispielsweise auf eine Fehlermeldung für eine ungültige 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 erstellen. Das ist ziemlich ähnlich wie bei einem Webentwickler, der eine Menüleiste erstellen muss.

Das Element <nav> gibt es zwar, aber Menüleisten werden oft mithilfe von Divs, Bildern, Schaltflächen, Klick-Handlern, Tastendrücke-Handlern und ARIA erstellt.

Unterstützung für Mausnutzer

Erstellen wir gemeinsam 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. Mit CSS können wir Elemente gut ausrichten und visuelle Umrisse um sie herum platzieren. Wir gestalten sie so ähnlich wie andere Menüleisten, dass sehbehinderte Nutzer 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. Wenn der Nutzer den Mauszeiger auf eine davon bewegt, wird eine Animation gestartet, durch die das untergeordnete Menü herausgeschoben wird.

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 jetzt 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 Darstellung, 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 die Anfrage zurückgegeben, wie ein Fisch, der zu klein zum Essen ist. Unsere Regeln sind in etwa so:

• Wenn der Nutzer eine Pfeiltastaturtaste drückt, sehen wir uns unsere eigenen internen Menüleisten-Vorlagen an und entscheiden, was der neue aktive Menüpunkt sein 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. Entfernen Sie sie also. Das ist nicht einfach. Für die Menüleiste sind beispielsweise Pfeiltasten erforderlich, aber nicht Alt + Pfeil oder Befehl + 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 sehende Nutzer einwandfrei.

ARIA als Retter in der Not 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 aria-activedescendant. Legen Sie das Attribut auf die ID des aktiven Menüpunkts fest und aktualisieren Sie es bei Bedarf. Beispiel: aria-activedescendant="settings-menuitem" Dadurch betrachtet der Screenreader das ARIA-aktive Element als Fokus, das vorgelesen oder auf einer Braillezeile angezeigt wird.

Erläuterung von Vorfahr, Elternelement und Abkömmling

Der Begriff „Abkömmling“ bezieht sich darauf, dass ein Element in einem anderen enthalten ist. Der gegenteilige Begriff ist „Vorgänger“. Das bedeutet, dass ein Element von Vorgängern enthalten ist. Für den nächsten Container nach oben/unten können die spezifischeren Begriffe „übergeordnet“/„untergeordnet“ verwendet werden. Angenommen, Sie haben ein Dokument mit einem Absatz, der einen Link enthält. Das übergeordnete Element des Links ist ein Absatz, aber auch das Dokument ist ein übergeordnetes Element. Umgekehrt kann das Dokument viele untergeordnete Absätze mit jeweils Links enthalten. Die Links sind alle Nachkommen des übergeordneten Dokuments.

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, 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 Ersteller das role="none"-Zeichen in das img-Dreieck einfügen, um anzugeben, dass es sich nur um ein Beauty-Produkt handelt. So wird verhindert, dass der Screenreader redundante Informationen zum Bild liest.

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 Tabnavigation 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 Problemen mit dem Tastaturzugriff empfiehlt es sich, den Test auch ohne Screenreader oder mit deaktiviertem virtuellen Browsermodus durchzuführen. Tastaturfehler können auch ohne Screenreader erkannt werden, da der Tastaturzugriff mit HTML und nicht mit ARIA implementiert ist. 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 ein Autor ARIA falsch anwenden kann. 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 „Artikel 3 von 5“ präsentiert, damit der Nutzer weiß, wo er sich befindet. In der Regel wird dies automatisch vom Browser gezählt. In einigen Fällen und in einigen Kombinationen aus Browser und Screenreader werden jedoch möglicherweise falsche Zahlen berechnet und der Autor muss diese Zahlen mit aria-posinset und aria-setsize überschreiben.

Und das sind nur 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. Es gibt zu viele Nuancen. Idealerweise sollte alles mit mehreren verschiedenen Browser-Screenreader-Kombinationen getestet werden, da es aufgrund der zahlreichen Implementierungsabweichungen und einiger unvollständiger Implementierungen zu Problemen kommen kann.

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, erhält der Nutzer die ARIA-Version der Wahrheit, sofern ARIA vorhanden ist.

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 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 im Objektbaum kann Eigenschaften haben, z. B. eine Rolle (Was bin ich?), einen Namen oder ein Label, einen vom Nutzer eingegebenen Wert, eine Beschreibung und boolesche Status wie „auf Fokus ausgelegt“, „fokussiert“, „erforderlich“ oder „angeklickt“. ARIA kann alle diese Eigenschaften überschreiben.
  • Screenreader verwenden den Baum, um Nutzern die Navigation im virtuellen Puffermodus zu erleichtern, z. B. „Gehen Sie 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 eignet sich gut für diese APIs zur Barrierefreiheit. 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.