Barrierefrei navigieren in Web-Apps

Eine für jeden gleichermaßen gut benutzbare und robuste Navigation in JavaScript-Apps umzusetzen ist nicht trivial. Problematisch ist das sogenannte „Routing“ – ein dynamischer Austausch von Teilen des DOMs, das den klassischen Serverrequest ersetzt.

Die Entwicklerin und Barrierefreiheits-Expertin Marcy Sutton hat sich im Sommer 2019 diesem Problem angenommen. Um eine Navigation per Routing zu gewährleisten, die auch für Benutzer und Benutzerinnen von Hilfsmitteln wie Screenreadern klar und nachvollziehbar ist, gibt es bisher zwar einige technische Ansätze. Jedoch kann man bisher keine davon besten Gewissens als „Best Practice“ bezeichnen. Letztendlich wird es Aufgabe des Gremiums W3C (World Wide Web Consortium) sein, einen Standard zu etablieren.

Best Practice gesucht

Bis das geschehen ist – und die Browserhersteller, jenen in ihrer Software umgesetzt haben – wird aber noch Zeit ins Land gehen. Deswegen tut eine Zwischenlösung dieses Problems mit den vorhandenen Mitteln Not. Der erste Schritt um eine von möglichst vielen Menschen nutzbare Methode zu etablieren, ist ein aussagekräftiger Test mit betroffenen Benutzergruppen – und genau das hat Marcy Sutton in Zusammenarbeit mit dem User-Testing-Start-Up „Fable“ gemacht.

Die Gruppe der Probanden bestand aus:

• Nutzern von Vorlese-Anwendungen („Screenreader“)
• Nutzern von Bildschirmvergrößerungs-Software
• Nutzern von Programmen, die die Bedienung eines Computers rein per Sprache ermöglichen
• Nutzern von „Switch Controls“, also einem zentralen Schalter als Eingabegerät

Um die Eignung der bereits bestehenden Lösungsversuche zum barrierefreien Routing zu überprüfen, testeten die Gruppen vier einfache Prototypen mit vier verschiedenen Ansätzen.

Kleinsten gemeinsamen Nenner gefunden

Nach Auswertung der Rückmeldungen kam Sutton zu den folgenden Schlüssen:

• Eine an Screenreader gerichtete Benachrichtigung allein, die über den erfolgreichen Wechsel einer Route informiert, genügt nicht für alle Benutzergruppen
• Am geeignetesten ist, ein interaktives Element in jedem Route-Zustand zu ergänzen, das sichtbar wird, wenn der Benutzer per Tastatur durch die App navigiert.
• Um auch bei vergrößterter Bildschirmdarstellung vollständig angezeigt und nicht abgeschnitten zu werden, sollte dieses Element vergleichsweise klein sein
• Dieses Element benötigt ein aria-label oder aria-labelledby-Attribut mit einer Referenz auf den nahegelegenen Inhalt (wie eine Überschrift) und Informationen über die eigene Interaktivität. Der Bezeichner im Accessibiliy Tree für so ein Steuerungselement könnte "Portfolio, zurück zur Navigation" lauten.

Am Ende der Testreihe steht die Erkenntnis, dass Maßnahmen, die auf eine Verbesserung des Nutzererlebnis einer Gruppe zielen wiederum Nachteile für eine andere Gruppe liefern könnte. Entsprechend ist die oben gelistete Methode als kleinster gemeinsamer Nenner zu verstehen - ein Kompromiss, der die Vielfalt sowohl der Website-Besucher, als auch ihrer technischen Hilfsmittel berücksicht. Für tiefergehende Informationen hat Marcy Sutton im Blog ihres Arbeitgebers Gatsby in einem ausführlichen Bericht die Notwendigkeit, den Ansatz und die Erkenntnisse ihrer Testreihe zusammengefasst - und schließt endet mit dem Appell: Wir sollten uns an Nutzer mit Behinderungen wenden, damit sie uns zu sagen, was für sie funktioniert – und nicht immer davon ausgehen, dass wir es bereits wissen.