20 Tips für zugänglichere Web-Apps

Der Beginn des neuen Jahres ist es eine gute Gelegenheit, sich mit der Barrierefreiheit Ihrer Web-Applikation auseinanderzusetzen. Deswegen habe ich im folgenden 20 Startpunkte gesammelt, die Ihnen helfen können, Ihre App im Jahr 2020 zugänglicher zu gestalten (bitte beachten Sie, dass mangels deutschsprachiger Alternativen viele verlinkte Inhalte in nur Englisch vorliegen).

1. Ein Großteil der Arbeit, eine Web-App barrierefreier zu machen, besteht darin, Grundlagen zu befolgen. Ja, es gibt spezielle Zugänglichkeitsprobleme, die mit der Funktionsweise von Webanwendungen zu tun haben, aber Tatsache ist auch: Wenn Sie sich auf die Grundlagen der Erstellung eines zugänglichen Webdokuments konzentrieren, werden Sie die große Mehrheit der Barrierefreiheitsproblemen von Webanwendungen lösen. Denn was nützt ein ausgeklügeltes Tastaturfokus-Management zum Beispiel bei Route Changes, wenn nicht-visuelle User die Hauptnavigation gar nicht erst finden können?
2. Nutzen Sie CSS, um zu erkennen, ob ihre User Animationen wünschen. Bieten Sie darüber hinaus eine Möglichkeit, sie manuell abzustellen. Für einige Leute können Animationen im Web nicht nur lästig, sondern sogar schädlich sein (siehe „Understanding vestibular disorders“ von A11yProject). Glücklicherweise können User eine Einstellung in ihrem Betriebssystem aktivieren, die es ihnen ermöglicht, mögliche Anfall auslösende Animationen auszuschalten, und wir als Developer können diese Einstellung per CSS erkennen. Dazu gibt es den Media Query prefers-reduced-motion. Aber unabhängig von der Fähigkeit des Betriebssystems, eine Präferenz für reduzierte Bewegungen zu übermitteln: Nutzen Sie die Stärke der Statefulness Ihrer Webanwendung, um eine manuelle Einstellung wie diese zu bauen (hier ist ein Beispiel, wie Sie dies in Vue.js tun könnten). Ein gutes Beispiel dazu aus der Praxis ist Twitters neue Webanwendung.
3. Testen Sie Zwischenzustände, wie z. B. das Nachladen von Daten, mit Screen Readern. Eine typische Eigenschaft einer Web-Anwendung ist es, Daten asynchron nachzuladen, z. B. von einer internen oder externen Schnittstelle oder Datenbank. Dies führt zu Ladezuständen, die Sie, wie ich annehme, visuell mit schön animierten Fortschrittsbalken vermitteln. Abe was ist, wenn User Ihre Anwendung und insbesondere diese Zwischenzustände mit einem Screenreader bedienen: Ist es klar, was passiert oder schweigt das Bildschirmvorleseprogramm einfach nur für eine unbestimmte Zeit, und lässt die User im Ungewissen? Wenn ja, dann sollten Sie sich informieren, ob ARIA Live-Regionen helfen können (für einen Einstieg ins Thema empfehle ich das Praxismuster „accessible notifications“ in meinen Projekt „Accessible App“).
4. Nutzen Sie automatisierte Tests zur Barrierefreiheit in Ihren Deployments und internen Prozessen. Die meisten Web-App-Umgebungen haben ein Tooling-Setup, um einen Entwicklungs-Server auszuführen, Ihre Anwendung in den Auslieferungszustand bringen und Tests ausführen zu können. Während dies die Entwicklung von Webanwendungen ziemlich komplex macht, gibt es Ihnen die Möglichkeit, Barrierefreiheits-Tests zu schreiben und durchzuführen. Achtung: nur etwa 20-30% der Zugänglichkeitsprobleme sind automatisch testbar, und es gibt manchmal Fehlinterpretationen der Skripte – aber im Großen und Ganzen schadet es nicht, wenn die Tests die Zugänglichkeit abdecken, besonders wenn es darum geht, andere Teammitglieder, die am selben Projekt arbeiten, damit implizit zu schulen.
5. Stellen Sie sicher, dass ihre komplette Applikation (inklusive JavaScript-basierter Widgets) tastaturbedienbar ist. Die Zugänglichkeit der Tastatur ist entscheidend für ein inklusives Interface. Viele Entwicklerinnen und Entwickler sind sich nicht bewusst, wie vielfältig die Möglichkeiten und Strategien sind, die Menschen bei der Nutzung von Websites haben – und wie wichtig die Barrierefreiheit der Tastatur in dieser Hinsicht ist. Wenn man über benutzerdefinierte Elemente spricht, sollte man zunächst sicherstellen, dass diese spezielle Form der Eingabe wirklich nicht mit einem nativen Eingabeelement gelöst werden kann (da es eine außergewöhnliche Menge an eingebauten Eingabehilfen bietet). Wenn dies nicht möglich ist, werfen Sie einen Blick in die WAI-ARIA Authoring Practices (lesen Sie aber auch den nächsten Punkt dieser Liste).
6. Seien sie sich bewusst, dass die WAI-ARIA Authoring Practices weder unumstritten noch Web-Standards sind. Wenn Sie zum ersten Mal über die „Authoring Practices“ (AP), gesammelte Verfahren der Web Accessibility Initiative des W3C, stolpern und Ihnen das zugängliche Web am Herzen liegt, sind Sie möglicherweise erleichtert. "Endlich", denken Sie vielleicht, "eine Ressource, wie man mit modernem JavaScript und WAI-ARIA zugängliche benutzerdefinierte Steuerelemente und Widgets erstellt". Dies ist zwar zum Teil wahr - die Autorenpraktiken zeigen, wie WAI-ARIA verwendet werden sollte, aber man muss im Hinterkopf haben, dass einige APs umstritten sind: Wegen der zugrunde liegenden Konzepte, wegen eines versehentlichen Ausschlusses bestimmer Usergruppen oder Inkonsistenzen in Hilfstechnologien. Als allgemeine Faustregel gilt: Schauen Sie sich die Diskussionen in den Github Issues zu dem jeweiligen Verfahren an und schauen Sie, ob es eine Diskussion um die Praxis gibt, die Sie implementieren möchten.
7. Recherchieren Sie, wie es in Ihrem gewählten JavaScript-Framework um Dokumentation zur Barrierefreiheit steht. Einige der wichtigsten JavaScript-Frameworks, die Ihnen bei der Erstellung von Webanwendungen helfen, haben einen ganzen Abschnitt über Inklusivität in ihrer offiziellen Dokumentation (z. B. React). Studieren Sie diese Ressourcen gründlich. Es könnten einige Perlen versteckt sein, die Sie darauf stoßen könnten, wie Sie in diesem speziellen Framework mit seinen Funktionen und Stärken barrierefreie Lösungen implementieren. Auch wenn Ihr Lieblings-Framework noch keinen solchen Abschnitt in seinen offiziellen Dokumenten hat, Sie aber ein Spezialistin oder Spezialist für Barrierefreiheit sind (oder eine gewisse Erfahrung in einem anderen Framework haben), denken Sie daran, das bisher Gelernte weiterzutragen (und gegebenenfalls anzupassen). Schließlich ist es Open Source.
8. Folgen Sie Leuten, die sich in dem Framework Ihrer Wahl mit Barrierefreiheit beschäftigen. Häufig gibt es in Communities Menschen, die sich zu bestimmten Themen als "Vordenkerin oder Vordenker" engangieren, oder zumindest Spezialthemen besetzen. Ich wette, es gibt in jedem Framework-Gemeinschaft mal mehr, mal weniger Leute, die sich auf Barrierefreiheit spezialisiert haben und es wert sind, abonniert zu werden (z. B. in sozialen Medien oder über ihren Blog-RSS-Feed). Tun Sie genau das, halten Sie sich über die Funktionen Ihrer Bibliotheken auf dem Laufenden, die möglicherweise der ganzen Community helfen könnten, ihre Apps zugänglicher umzusetzen.
9. Überprüfen Sie interaktive Elemente Ihrer Web-App: Sind es semantisch Links oder Schaltflächen (wenn es sich nicht um Formular-Elemente handelt)? Mit JavaScript war es immer schon einfach, Elemente klickbar zu machen. Aber in Bezug auf die Barrierefreiheit macht ein (sagen wir mal) klickbares <span>-Element keinen Sinn und ist sogar schädlich. Es gibt viele gute Artikel, die dies immer wieder erklären (wie dieser Artikel von Karl Groves), also versuche ich nicht, einen weiteren hinzuzufügen. Vielmehr möchte ich betonen, dass es wichtig ist, zu wissen, wann ein Link (im Allgemeinen: für Änderungen des der Seite oder des genauen Ortes in der Anwendung) und wann eine Schaltfläche (im Allgemeinen: zum Ändern des Status der Anwendung oder zum Ausblenden/Anzeigen von Dingen) verwendet werden soll. Marcy Suttons Vortrag „The Links vs. Buttons Showdown“ ist eine geeignete Ressource, um das eigene Wissen zum Thema zu vertiefen.
10. Schauen Sie sich Bereiche Ihrer Applikation, die Infite Scrolling verwenden, genauer an. Unendliches Scrollen, oder virtuelles Scrollen, ist sowohl eine verbreitete Funktion (z. B. Twitters sich ständig ändernde, selbst aktualisierende und nie endende Timeline), als auch ein sehr häufiges Zugänglichkeitsproblem. Und während die WAI-ARIA-Rolle „feed“ die Nutzer von Screenreadern über die dynamische und aktualisierende Natur eines Widgets informiert, sind „unendliche“ Feeds immer noch ein Problem für andere Gruppen, z.B. für Nutzer, die nur mit der Tastatur, einem Einfachsensor-Taster oder Spracherkennung arbeiten. Ich empfehle, Raghavendra Satish Peri's Artikel „Infinite Scrolling & Role=Feed Accessibility Issues“ zu lesen. Darin sind die Probleme, die diese Gruppen haben, genauer beschrieben. Und auch eine Lösung skiziert, um die meisten davon zu lösen. Schauen Sie sich an, ob das auf Ihre Applikation anwendbar ist.
11. Wenn Ihre App Ihren Usern ermöglicht, Inhalte zu erstellen, sind diese möglichst barrierearm? Dies ist ein Thema, das nicht in einem Absatz zusammengefasst werden kann. Aber die wichtigen Punkte sind: Stellen Sie sicher, dass sowohl nutzergenerierte Inhalte selbst als auch der Weg zu nutzergenerierten Inhalten (beispielsweise Editoren) zugänglich sind. Und wissen Sie um die Existenz von Web-Standards in diesem Zusammenhang: Die Richtlinien für die Zugänglichkeit von Autorenwerkzeugen, ATAG
12. „Viel hilft viel“ gilt nicht für WAI-ARIA. Für einige Leute ist WAI-ARIA die Lösung für alle Probleme der Zugänglichkeit, fügt wie durch Wuderhand Funktionalität hinzu, indem es einfach nur ergänzt wird. Nach dem Motto: Streuen Sie ein wenig ARIA über Ihre Web-Anwendung, und es wird automatisch die Zugänglichkeit verbessern. Leider könnte das nicht weiter von der Wahrheit entfernt sein. In Wirklichkeit ist ARIA eine Spezifikation speziell für assistive Technologie und in gewisser Hinsicht „ein Polyfill für HTML“. Es hilft Entwicklerinnen und Entwicklern, eigene Widgets so zu bauen oder nachzurüsten, dass z. B. Screenreader die Möglichkeit haben, sie zu verstehen. WAI-ARIA ist in erster Linie ein Vertrag mit dem Nutzenden über die Einhaltung bestimmter Nutzungsmuster und die Ankündigung, dass eine bestimmte Art der Tastaturbedienbarkeit bereit stehen wird. Ich denke, dieses allgemeine Missverständnis führt zu Erkenntnissen wie die Analyse WebAim-Million, die aufdeckte, dass eine Website umso weniger zugänglich ist, je mehr ARIA genutzt wird. Oder, wie Bruce Lawson es ausdrückt: "...wenn man nicht wirklich weiß, was man tut, ist es leicht, die Dinge mit ARIA zu verschlimmern." Stolpern Sie nicht in diese Falle, wenn Sie Ihre Webanwendung erstellen!
13. Testen Sie Ihre Apps mit Menschen mit Behinderung! Das Einhalten von Standards, Dogmatismus in der Webentwicklung ist nur ein Teil des Puzzles (leider wird dieser Aspekt allein oft vernachlässigt). Der andere wesentliche Teil ist, mit Ihren Usern zu sprechen, die eignenen Annahmen zu testen und – idealerweise – Menschen mit Behinderungen ganz konkret einzuladen, um gemeinsam herauszufinden, ob Ihre App (oder jedes digitale Projekt in dieser Hinsicht) wirklich inklusiv und für alle zugänglich gebaut ist.
14. Bevor Sie sich für ein Frontend-Framework (wie z. B. Bootstrap) entscheiden, überprüfen Sie es auf seine Barrierearmut. Manchmal ist es nicht die wirtschaftlichste Option für Ihr Projekt, alles von Grund auf neu zu erstellen und Sie greifen auf etablierte Web-UI-Frameworks wie Foundation, Bootstrap, Material UI oder Uikit zurück. Bedenken Sie dabei, dass es wichtig ist, eine Vorstellung davon zu haben, wie zugänglich dieses Frontend-Framework tatsächlich ist, und ob es Ihnen hilft oder hindert, Ihre Anwendung zugänglicher zu machen. Um Hilfe dabei zu erhalten, recherchieren Sie, was über die Zugänglichkeit des von Ihnen gewählten Frameworks geschrieben wurde, oder lesen Sie Artikel wie „The state of accessible web UI frameworks“ von Derek Kay, der einen methodischen Ansatz bei der Überprüfung von mehr als 20 UI-Bibliotheken hinsichtlich ihrer Zugänglichkeitsfunktionen verwendet hat.
15. Verfolgen Sie Entwicklungen um die Accessibility Object Model-Spezifikation (AOM). AOM wird eine Schnittstelle sein, die es Developern erlaubt, den Accessibility Tree zu modifizieren und die Semantik zu vermitteln, ohne auf HTML angewiesen zu sein (zur Erinnerung: dieser „Baum“ ist eine Darstellung des DOM-Tree für assistive Technologien wie Screenreader oder Spracherkennungssoftware). Um Hidde de Vries zu zitieren: "Der Accessibility Tree ist eine Darstellung des DOM-Baums für assistive Technologien wie Screenreader oder Spracherkennungssoftware: Mit direktem Zugriff auf Informationen zur Barrierefreiheit könnten wir Barrierefreiheitseigenschaften ohne Markup setzen, wir könnten Barrierefreiheitsbäume für Dinge erstellen, die im DOM nicht existieren (wie z.B. für den Inhalt von Canvas-Elementen), und das Testen der Barrierefreiheit könnte sich verbessern.“ Obwohl sich sowohl die Vorschläge als auch die Browser-Implementierungen des Barrierefreiheitsobjektmodells noch im "work in progress"-Zustand befinden, lohnt es sich sehr, seine Entwicklung zu verfolgen. Genau dazu würde ich Veröffentlichungen, Tweets und Vorträge von Leonie Watson (Blog, Twitter) und dem oben genannten Hidde (Blog, Twitter) vorschlagen.
16. Informieren Sie sich, welche Vorteile JavaScript-Framworks für die Barrierefreiheit bringen können. Es ist nicht immer alles schwarz oder weiß, besonders wenn es um die Zugänglichkeit geht. Dennoch haben JS-Frameworks in dieser Hinsicht einen schlechten Ruf. Aber es ist spannend, darüber nachzudenken, wie man ihre unbestreitbaren Vorteile „für die gute Sache“ einsetzen kann. Im Jahr 2019 half mir eine ganze Reihe von Leuten dabei, eine Liste von Ideen, Ressourcen, Schlüsselwörtern und Startpunkten zur Beantwortung der Frage in meinen englischsprachigen Blog zu sammeln: „In what ways could React, Vue, Angular and Co and their features actually facilitate inclusive designs?“ (in etwa: „Auf welche Art und Weise könnten React, Vue, Angular und Co und ihre Funktionen inklusives Design ermöglichen?“).
17. Informierien Sie sich über den Formular-Modus von Screen Readern. Die Screen Reder für das Betriebssystem Windows, nämlich NVDA und JAWS, haben spezielle Modi, in die sie umschalten und bieten Interaktionsmuster, die zu diesem Modus oder den Umständen passen. Es gibt den Browse-Modus, den sogenannten Anwendungsmodus und den Formular-Modus. Da Webapplikationen überwiegend aus einer Art von Eingabe-Kontrollelementen oder Formularsammlungen bestehen, lohnt es sich, einen Blick auf zuletztgenannten Modus zu werfen. Im Allgemeinen können Screenreader-Benutzer im Formularmodus nur zu einem fokussierbaren Element navigieren - das muss man im Auge behalten, insbesondere wenn es um Eingabebeschriftungen, Beschreibungen, Fehler und ihre jeweiligen programmatischen Zusammenhänge geht. Mein Vorschlag, in dieses Thema einzutauchen: Accessibility Developer Guide's „Screen reader browse and focus modes“.
18. Folgen Ihre Widgets Grundmustern wie "modal" oder "expandierend"? In seinem Buch "Apps for All" schreibt Heydon Pickering: „Wenn man sich JavaScript-gesteuerte Webinterfaces ansieht, basiert der bei weitem häufigste Interaktionsstil darauf, Dinge zu zeigen oder zu verstecken oder... oh, das ist so ziemlich alles.“ Ich empfehle, einen intensiveren Blick auf Ihre Interfaces und Ihren Code zu werfen. Schaltet ein Bedienelement die Sichtbarkeit eines anderen um? In diesem Fall ist es wahrscheinlich, dass Sie eine Art (expandierendes) „Disclosure Widget“ gebaut haben. Löst ein anderes Steuerelement die Sichtbarkeit eines anderen Containers aus, und versucht der Container, den Rest der Schnittstelle inaktiv zu machen? Dann könnte dies das "modale" Konzept sein. Wenn Muster wie diese in Ihrer Anwendung vorhanden sind, versuchen Sie, die Auswirkungen auf die Zugänglichkeit beider zu analysieren.
19. Wenn Ihre App serverseitig gerendert wird, setzen Sie auf progressive Verbesserung („Progressive Enhancement“)? JavaScript ist nicht immer verfügbar. Sein Fehlen führt normalerweise dazu, dass Single Page Applications überhaupt nicht laufen. Aber nicht jede Webanwendung wird vollständig vom Client gerendert. Stellen Sie sicher, dass alle Ihre Inhalte wahrnehmbar und unabhängig von der Verarbeitung durch JavaScript sind. Andy Bell zeigt am Beispiel eines Akkordions, wie robuste Widgets gebaut werden können.
20. Seien sie kritisch in Bezug auf Code in Tutorials und Übungen, wenn Sie sich in Ihrem Framework weiterbilden. Zu viel Autoren und Autorinnen von Fachartikeln, Anleitungen und Übungsvideos haben kein Bewusstsein dafür, wie wichtig Barrierefreiheit ist. Das ist insofern unglücklich, da Tutorials für viele Lernende eine wichtige Grundlage darstellen – und barrierebehaftete Lösungen sich häufig so weiter verbreiten. Was, neben dem Code selbst, häufig auch kopiert wird ist das fehlende Wissen oder das Desinteresse des Lehrenden am Thema.