ARIA: Gift oder Gegenmittel?

Wie Lügen mit Screenreadern wirkt sich positiv auf die Barrierefreiheit aus, wenn sie nicht salzig ist!

Aaron Leventhal

Was ist ARIA?

Mit ARIA können Webautoren eine alternative Realität schaffen, die nur Screenreader nutzen können 🤥

Manchmal müssen Sie die Wahrheit erweitern oder sogar ganz richtig "anlügen", um Screenreadern darüber zu informieren, was in Webinhalten passiert. Beispiele: „Fokus ist wirklich hier drüben!“ oder „Das ist wirklich ein Schieberegler!“ Es ist, als würden Sie magische Haftnotizen über Tools und Widgets auf Ihrer Workbench hinzufügen. Diese magischen Haftnotizen bringen alle zum Glauben, was darauf geschrieben ist.

Wenn eine magische Haftnotiz vorhanden ist, überschreibt sie entweder unsere Überzeugung, was das jeweilige Tool ist, oder etwas über das Tool. Beispiel: „Das Ding hier drüben ist eine Klebepistole!“ Obwohl es sich eigentlich um einen leeren blauen Kasten auf der Werkbank handelt, wird die magische Haftnotiz darauf hinweisen, dass es sich um eine Klebepistole handelt. Wir können auch hinzufügen: „and it is 30% complete!“. Der Screenreader meldet jetzt, dass sich dort eine 30-prozentige Klebepistole befindet.

Das entsprechende Web-Äquivalent besteht darin, ein einfaches Box-Element (ein div-Element) mit einem Bild darin zu nehmen und mit ARIA einen Schieberegler mit einem Wert von 30 von 100 zu verwenden.

Was ist nicht ARIA?

ARIA hat keinen Einfluss auf das Erscheinungsbild einer Webseite oder das Verhalten einer Maus oder Tastatur. Nur Nutzer von Hilfstechnologien werden einen Unterschied zu ARIA bemerken. Webentwickler können jede beliebige ARIA hinzufügen, ohne Nutzer zu beeinträchtigen, die keine Hilfstechnologien verwenden.

Sie haben es richtig gelesen: ARIA ändert nichts mit Tastaturfokus oder TAB-Reihenfolge. Das alles ist in HTML erledigt, manchmal mit JavaScript-Snippets angepasst.

Wie funktioniert ARIA?

Browser werden von einem Screenreader oder einer anderen Hilfstechnologie nach Informationen zu jedem Element gefragt. Wenn ARIA in einem Element vorhanden ist, nimmt der Browser die Informationen auf und ändert, was der Screenreader über dieses Element mitteilt.

Warum ARIA?

Warum sollten wir unsere Nutzenden jemals anlügen wollen?

Angenommen, im lokalen Web-Store werden nicht alle benötigten Widgets verkauft. Aber wir sind MacGyver, verdammt. Wir können einfach unsere eigenen Widgets aus anderen Widgets erfinden! FWIW, die sieben am häufigsten verwendeten Dinge von MacGyver, sind Schweizer Armeemesser, Kaugummi, Schuhschnüren, Streichhölzer, Büroklammern, Geburtstagskerzen und Klebeband. Er nutzt sie, um Bomben und andere Dinge zu bauen, die nicht nur herumliegen. Das ist vergleichbar mit einem Webautor, der eine Menüleiste erstellen muss. Menüleisten sind so nützlich, dass man meinen, sie wäre Teil von HTML, aber sie sind es nicht. Na gut! Du hättest nicht gedacht, dass Autoren mit Links und Schaltflächen zufrieden wären? Der Autor baut also mithilfe seiner bevorzugten Tools eine Kombination aus: divs, images, style, Click-Handlern, Keypress-Handlern, Spit und ARIA.

Manchmal nutzen wir ARIA nur als Optimierung, anstatt ARIA voll auszuschöpfen. Es kann nützlich sein, ein wenig ARIA auf HTML-Code zu verteilen, der im Grunde bereits funktioniert. Beispielsweise kann es sein, dass eine Formularsteuerung auf eine Fehlermeldung zu einer ungültigen Eingabe verweist. Oder wir möchten angeben, dass ein Textfeld für die Suche bestimmt ist. Diese kleinen Anpassungen können die Nutzung gewöhnlicher Websites mit einem Screenreader verbessern.

Beispiel für Menüleiste

Mausklicker unterstützen

Erstellen wir nun gemeinsam eine Menüleiste. Wir zeigen eine Reihe von Artikeln in generischen „box“-Elementen, den „divs“-Elementen. Jedes Mal, wenn der Nutzer auf ein div-Element klickt, wird der entsprechende Befehl ausgeführt. Cool, das funktioniert auch für Mausklicks!

Als Nächstes sorgen wir dafür, dass es hübsch aussieht. Wir nutzen CSS, d.h. Stile, Elemente, die optisch ansprechend sind. Sie ähnelt anderen Menüleisten, sodass alle intuitiv wissen, dass es sich um eine Menüleiste handelt und sie zu verwenden ist. Unsere Menüleiste verwendet sogar eine andere Hintergrundfarbe für jedes Element, auf dem sich der Mauszeiger befindet. So erhält der Nutzer hilfreiches visuelles Feedback.

Einige Menüpunkte sind übergeordnet. Sie erzeugen untergeordnete Untermenüs. Immer wenn der Nutzer den Mauszeiger auf eine dieser Optionen bewegt, wird eine Animation gestartet, die aus dem untergeordneten

Dies ist natürlich alles ziemlich unzugänglich, wie es bei vielen Dingen im Web der Fall ist, vor allem, weil die Assistenten für HTML-Standards nicht alles hinzugefügt haben, was ein Webautor benötigt. Und selbst wenn sie es täten, würden Webautoren ohnehin immer ihre eigene besondere Version erfinden wollen.

Die Menüleiste mit der Tastatur zugänglich machen

Als ersten Schritt zur Barrierefreiheit fügen wir nun die Tastatur-Bedienungshilfen hinzu. In diesem Teil wird nur HTML und nicht ARIA verwendet. Beachten Sie, dass ARIA bei Nutzern ohne Hilfstechnologien keine Kernaspekte wie Darstellung, Maus oder Tastatur beeinflusst.

Genau wie eine Webseite auf die Maus, aber auch auf die Tastatur reagieren kann. Unser JavaScript erfasst alle vorhandenen Tastenanschläge und entscheidet, ob der Tastendruck sinnvoll ist. Andernfalls wird die Seite wieder auf die Seite geworfen, wie ein Fisch, der zu klein zum Essen ist. Unsere Regeln sehen in etwa so aus:

• Wenn der Nutzer eine Pfeiltaste drückt, schauen wir uns unsere eigenen internen Vorlagenleisten-Blueprints an und entscheiden, wie das neue aktive Menüelement lauten soll. Wir löschen alle aktuellen Highlights und heben den neuen Menüpunkt hervor, damit der sehende Nutzer sehen kann, wo er sich befindet. Die Webseite sollte dann event.preventDefault() aufrufen, um zu verhindern, dass der Browser die übliche Aktion (in diesem Fall das Scrollen auf der Seite) ausführt.
• Wenn der Nutzer die Eingabetaste drückt, können wir dies wie einen Klick behandeln und die entsprechende Aktion ausführen (oder sogar ein anderes Menü öffnen).
• Wenn die Nutzenden eine Taste drücken, die etwas anderes tun soll, essen Sie das nicht! Wirf es in der vorgesehenen Weise auf die Seite zurück. Die Tabulatortaste wird in der Menüleiste beispielsweise nicht benötigt, also geben Sie sie zurück. Es ist schwierig, das zu ändern, und Autoren machen es falsch. Die Menüleiste benötigt beispielsweise Pfeiltasten, aber nicht Alt + Pfeil oder Befehlstaste + Pfeil. Das sind Verknüpfungen, mit denen du im Webprotokoll deines Browsertabs zur vorherigen oder nächsten Seite wechseln kannst. Wenn der Autor nicht aufpasst, verschwindet die Menüleiste. So etwas kommt häufig vor, und wir haben noch nicht einmal mit ARIA angefangen!

Screenreader-Zugriff auf unsere Menüleiste

Unsere Menüleiste wurde mit Klebeband und Divs erstellt. Screenreader kennen diese nicht, sondern als Hintergrundfarbe für das aktive Element. Die „div“-Elemente der Menüoptionen sind einfache Objekte ohne besondere Bedeutung. Daher erhält ein Nutzer unserer Menüleiste keine Anleitung dazu, welche Tasten er drücken oder welches Element er sich befindet.

Aber das ist unfair! Die Menüleiste funktioniert für den sehenden Nutzer problemlos.

ARIA kommt zur Rettung. Mit ARIA können wir uns den Screenreadern vorstellen, deren Fokus sich in einer Menüleiste befindet. Wenn der Autor alles richtig macht, sieht unsere benutzerdefinierte Menüleiste für den Screenreader wie eine Menüleiste in einer Desktopanwendung.

Zuerst verwenden wir das Attribut aria-activedescendant und legen es auf die ID des aktuell aktiven Menüelements fest. Achte darauf, es bei jeder Änderung zu aktualisieren. Beispiel: aria-activedescendant="settings-menuitem" Diese kleine weiße Lüge führt dazu, dass der Screenreader unser aktives ARIA-Element als Fokus betrachtet, das vorgelesen oder auf einer Braillezeile angezeigt wird.

Erläuterung von ancestor, ancestor und ancestor

Der Begriff „Nachfolger“ bezieht sich darauf, dass ein Element irgendwo innerhalb eines anderen Elements enthalten ist. Der gegenteilige Begriff ist „Ancestor“, was bedeutet, dass ein Element von Ancestors enthalten ist. Für den nächsten Container nach oben/unten können diese die spezifischeren Begriffe über-/untergeordnet verwenden. Stellen Sie sich zum Beispiel ein Dokument mit einem Absatz vor, der einen Link enthält. Das übergeordnete Element des Links ist ein Absatz. Es hat jedoch auch das Dokument als übergeordnetes Element. Das Dokument kann jedoch auch viele untergeordnete Absätze mit Links haben. Die Links sind alle Nachfolger des übergeordneten Dokuments.

Zurück zu aria-activedescendant. Da der Screenreader damit von der fokussierten Menüleiste auf ein bestimmtes Menüelement zeigt, wohin der Nutzer bewegt wurde, weiß der Screenreader nichts mehr über das Objekt. Was ist das überhaupt ein div-Ding? Hier kommt das Rollenattribut ins Spiel. Wir verwenden role="menubar" für das enthaltende Element für den gesamten Inhalt, dann role="menu" für Elementgruppen und role="menuitem" für Trommelwirbel... die einzelnen Menüpunkte.

Und was ist, wenn der Menüpunkt zu einer untergeordneten Speisekarte führen kann? Das müssen die Nutzenden wissen, oder? Für sehende Nutzer kann am Ende des Menüs ein kleines Bild eines Dreiecks angezeigt werden. Der Screenreader weiß aber nicht, wie Bilder automatisch gelesen werden. Wir können jedem maximierbaren Menüelement aria-expanded="false" hinzufügen, um anzugeben, dass es 1) etwas gibt, das erweitert werden kann, und 2) es derzeit nicht erweitert ist. Als zusätzliche Ergänzung sollte der Autor role="none" auf das Bild-Dreieck setzen, um anzuzeigen, dass es nur zu Schönheitszwecken dient. So wird verhindert, dass der Screenreader Informationen über das Bild ausspricht, die im besten Fall redundant und möglicherweise störend wären.

Umgang mit Programmfehlern

Tastaturfehler (HTML!)

Auch wenn der Tastaturzugriff zum HTML-Hauptbestandteil gehört, machen Autoren ihn ständig durcheinander, entweder weil sie die Tastatur nicht allzu oft verwenden oder weil die richtige Eingabe sehr feiner sein kann.

Beispiele für Programmfehler:

• In einem Kästchen wird zum Umschalten die Leertaste verwendet, aber der Autor hat vergessen, preventDefault() aufzurufen. Jetzt kann mit der Leertaste das Kästchen ein- und ausgeschaltet werden. Dies ist das Standardverhalten des Browsers für die Leertaste.
• Ein modales ARIA-Dialogfeld möchte die Tab-Navigation innerhalb des ARIA-Dialogfelds erfassen. Der Autor vergisst, explizit Strg + Tabulatortaste zum Browser zuzulassen. Jetzt kann mit Strg + Tabulatortaste nur innerhalb des Dialogfelds gewechselt und der Tab im Browser nicht mehr wie gewünscht gewechselt werden. Das ist ungerecht.
• Ein Autor erstellt eine Auswahlliste und implementiert den Aufwärts- und Abwärtspfeil, aber keine Start-/Ende-/Bild-auf-/Bild-ab-Navigation oder die Navigation aus dem ersten Buchstaben.

Autoren sollten bekannte Muster befolgen. Weitere Informationen finden Sie im Abschnitt Ressourcen.

Bei Problemen mit dem Tastaturzugriff ist es sinnvoll, es auch ohne Screenreader oder bei deaktiviertem virtuellen Browsermodus zu versuchen. Screenreader sind im Allgemeinen nicht erforderlich, um Tastaturfehler zu erkennen, und der Tastaturzugriff wird mit HTML und nicht mit ARIA implementiert. Schließlich hat ARIA keinen Einfluss auf grundlegende Dinge wie Tastatur oder Maus. Der Screenreader hat lediglich Einfluss darauf, was auf der Webseite oder das aktuelle Fokusziel ist usw.

Tastaturfehler sind fast immer Fehler in Webinhalten, insbesondere in HTML und JavaScript, nicht in ARIA.

ARIA-Bugs: Warum gibt es so viele?

Es gibt viele Stellen, an denen Autoren ARIA falsch einordnen können, und die jeweils zu einem vollständigen Bruch oder zu subtilen Unterschieden führen. Die subtilen sind wahrscheinlich noch schlimmer, da der Autor die meisten davon vor der Veröffentlichung nicht erkennt.

Denn wenn die Person keine erfahrenen Screenreader-Nutzer ist, funktioniert in der ARIA ein Fehler. In unserem Beispiel mit der Menüleiste könnte der Autor denken, dass die Rolle „option“ verwendet werden sollte, wenn „menuitem“ korrekt war. Sie könnten vergessen, aria-expanded zu verwenden, vergessen, aria-activedescendant zur richtigen Zeit festzulegen und zu löschen, oder vergessen, eine Menüleiste mit den anderen Menüs zu haben. Und was ist mit der Anzahl der Gerichte auf der Speisekarte? Normalerweise werden Menüpunkte von Screenreadern mit etwas wie „Punkt 3 von 5“ präsentiert, damit Nutzende wissen, wo sie sich befinden. Dies wird im Allgemeinen automatisch vom Browser gezählt. In einigen Fällen und in einigen Browser-/Screenreader-Kombinationen werden jedoch unter Umständen falsche Zahlen berechnet und der Autor muss diese Zahlen mit aria-posinset und aria-setsize überschreiben.

Und das sind nur Menüleisten. Überlegen Sie, wie viele Arten von Widgets es gibt. Werfen Sie einen Blick auf die ARIA-Spezifikation oder die Erstellungspraktiken. Für jedes Muster gibt es Dutzende Möglichkeiten, wie ARIA missbraucht werden könnte. ARIA ist darauf angewiesen, dass die Autoren wissen, was sie tun. Was könnte schiefgehen, da die meisten Autoren keine Screenreader nutzen?

Mit anderen Worten: echte Screenreader-Nutzer müssen ARIA-Widgets zu 100 % ausprobieren, bevor sie als auslieferbar gelten. Das sind zu viele Nuancen. Idealerweise sollte alles mit verschiedenen Browser-Screenreader-Kombinationen ausprobiert werden, weil es neben einigen unvollständigen Implementierungen auch zahlreiche Macken gibt.

Zusammenfassung

Zusammenfassend lässt sich sagen, dass die ARIA-Magie verwendet werden kann, um alles, was der HTML-Text ausgibt, zu überschreiben oder zu ergänzen. Sie können damit kleine feine Änderungen an der Präsentation zur Barrierefreiheit vornehmen oder eine ganze User Experience schaffen. Aus diesem Grund ist ARIA für unsere freundlichen lokalen Webautoren, die im Allgemeinen keine Screenreader verwenden, sowohl unglaublich leistungsstark als auch gefährlich.

ARIA ist eine einfache, wahrheitsgemäße Überschreibungs-Markup-Ebene. Wenn ein Screenreader fragt, was passiert ist, erhält er, sofern ARIA vorhanden ist, die ARIA-Version der Wahrheit anstelle der tatsächlichen zugrunde liegenden Wahrheit.

Anhang 1: Zusätzliche Ressourcen

Hybridreferenz mit Tastaturinformationen und Codebeispielen

• ARIA-Authoring-Praktiken des W3C: Hier werden die wichtigen Eigenschaften der Tastaturnavigation der einzelnen Beispiele beschrieben und der funktionierende JS-/CSS-/ARIA-Code bereitgestellt. Die Beispiele konzentrieren sich darauf, was heute funktioniert, und decken nicht mobile Inhalte ab.

Anhang 2: Wofür wird ARIA am häufigsten verwendet?

ARIA kann kleine oder große Wahrheiten ersetzen oder ergänzen und ist im Allgemeinen nützlich, um Dinge zu vermitteln, die für den Screenreader wichtig sind.

Hier sind einige gängige Anwendungsbereiche von ARIA.

• Spezielle Widgets, die in HTML nicht vorhanden sind, z. B. Menüleiste, automatische Vervollständigung, Baumstruktur oder Tabelle
• Widgets, die in HTML vorhanden sind, aber der Autor dennoch eigene erfunden hat, möglicherweise deshalb, weil das Verhalten oder Erscheinungsbild des normalen Widgets angepasst werden musste. Ein HTML-<input type="range">-Element ist beispielsweise im Grunde ein Schieberegler, das jedoch von den Autoren anders aussehen soll. In den meisten Fällen kann CSS verwendet werden, aber für input type="range" ist CSS umständlich. Ein Autor kann einen eigenen Schieberegler erstellen und darauf role="slider" mit aria-valuenow verwenden, um den aktuellen Wert anzugeben.
• Mit Live-Regionen teilen Sie Screenreadern mit, dass „in diesem Bereich der Seite dem Nutzer alles, was es ändert, wichtig ist.“
• Orientierungspunkte (HTML hat Äquivalente derzeit). Sie ähneln Überschriften, da sie Screenreader-Nutzenden helfen, das Gesuchte schneller zu finden. Unterscheiden sich jedoch darin, dass sie den gesamten zusammengehörigen Bereich enthalten. Zum Beispiel: „Dieser Container ist der Hauptbereich der Seite“ und „dieser Container hier ist ein Navigationsbereich“.

Anhang 3: Was ist eine Accessibility API?

Eine Accessibility API ist die Art und Weise, wie ein Screenreader oder andere AT weiß, was sich auf der Seite befindet und was gerade passiert. Beispiele hierfür sind MSAA, IA2 und UIA. Und das ist nur Windows! Eine Accessibility API besteht aus zwei Teilen:

• Ein „Baum“ von Objekten, der eine Containerhierarchie darstellt. Diese sind wie russische Puppen, aber jede Puppe kann mehrere andere Puppen enthalten. Ein Dokument kann beispielsweise mehrere Absätze enthalten und ein Absatz kann Text, Bilder, Links, Fettdruck usw. enthalten. Jedes Element in der Objektstruktur kann Eigenschaften wie eine Rolle (was bin ich?), einen Namen/Label, einen vom Nutzer eingegebenen Wert, eine Beschreibung sowie boolesche Status wie fokussierbar, fokussiert, erforderlich, aktiviert haben. ARIA kann alle diese Eigenschaften überschreiben. Der Screenreader verwendet den Baum, um dem Nutzer bei der Navigation im virtuellen Zwischenspeichermodus zu helfen, z. B. „Gehen Sie bitte zur nächsten Überschrift“.
• Eine Reihe von Ereignissen, die Änderungen am Baum beschreiben, z. B. „Fokus ist jetzt hier!“. Der Screenreader teilt dem Nutzer anhand der Ereignisse mit, was gerade passiert ist. Wenn sich wichtige HTML- oder ARIA-Markups ändern, wird ein Ereignis ausgelöst, um den Screenreader darüber zu informieren, dass sich etwas geändert hat.

Normalerweise verwenden Autoren einfach HTML, was eine gute Ergänzung zu diesen Barrierefreiheits-APIs darstellt. Wenn HTML nicht ausreicht, wird ARIA verwendet und der Browser überschreibt die HTML-Semantik, bevor der Objektbaum oder die Ereignisse an den Screenreader gesendet werden.