Single Page Applications und Frameworks als Sollbruchstellen des Internets

Inklusiver Hürdenlauf – (k)ein barrierefreies Web für alle!
Kommentare

Opa sieht nicht mehr so gut, der Sohn der Nachbarin hat Probleme mit der Motorik und damals in der Schule gab es ein Kind mit Epilepsie, das Probleme mit blinkenden Lichtern hatte. Behinderungen sind keineswegs selten und gehen uns darum alle etwas an. Moderne Webtechnologien können allerdings ganz neue Hürden für Menschen mit außergewöhnlichen Bedürfnissen im Umgang mit dem Internet erzeugen. Glücklicherweise lässt sich das ändern, ohne gleich auf Frameworks und Single Page Applications verzichten zu müssen.

Wer Webinhalte nur auf sehende, hörende, geistig fitte Nutzer ausrichtet, erzeugt Barrieren – und könnte irgendwann selbst davon betroffen sein. Behinderungen bestehen nämlich nicht nur aus angeborenen Schwierigkeiten, sondern können erworben werden. Ein Unfall – oder einfach das Alter – führt ganz schnell dazu, dass das, was heute noch problemlos möglich war, morgen schon zur Herausforderung wird. Insofern ist Barrierefreiheit kein Nischenthema.

Zwei Fliegen mit einer Klappe

Das Problem beginnt lange vor der Screenreader-Tauglichkeit von Inhalten und geht weit darüber hinaus. Grundlegend gilt nämlich: Was einen Nutzer mit durchschnittlichen Fähigkeiten nerven kann, kann die Usability für viele andere Menschen komplett zerstören. Wer sich das bewusst macht, kann vielen selten bedachten Problemen vorbeugen.

Mega-Dropdownmenüs, die bei einer winzigen Mausbewegung direkt wieder verschwinden, stören beispielsweise schon Nutzer mit durchschnittlichen motorischen Fähigkeiten und sind darum ein gutes Beispiel für „normale“ Barrieren. Besser ist es hier, eine statische Alternative anzubieten. Für Nutzer mit Schwierigkeiten im Umgang mit der Maus sind solche Menüs nämlich kaum noch zu gebrauchen. Und was ist mit den so beliebten Karussells? Häufig drehen sich die Bilder immer weiter im Kreis, sie wechseln sich endlos ab – wer Informationen nur geringfügig langsamer verarbeitet, kommt da einfach nicht mit. Also braucht es zumindest einen Pausen-Button.

Barrierefreiheit überprüfen

Um nun zu testen, wie es um die Barrierefreiheit der einen oder anderen Website steht, können verschiedene Tools verwendet werden. So gibt es für die Chrome DevTools eine Erweiterung, die beispielweise überprüfen kann, ob der Code einer Website mit den ARIA-Spezifikationen kompatibel ist oder ob Nachbesserungsbedarf besteht.

Daneben können Webangebote wie WAVE genutzt werden, die innerhalb einzelner Seiten ganz genau markieren, wo Probleme auftreten. Außerdem gibt es auch die Möglichkeit, Accessibility Tests in die automatischen Tests zu integrieren, die ein Projekt vor der Veröffentlichung durchläuft. Zu diesem Zweck hat Paypal das Automated Accessibility Testing Tool (AATT) auf GitHub zur Verfügung gestellt.

ARIA?

Die ARIA-Spezifikationen stellen eine gute Möglichkeit dar, um die Barrierefreiheit im Web zu erhöhen. Das heißt allerdings nicht, dass sie jederzeit und in jeder Form verwendet werden sollten. Am Ende sind Webinhalte nämlich oft dann am barrierefreisten, wenn sie möglichst viel natives, semantisches HTML enthalten. Sobald eine Funktion also per HTML umsetzbar ist, sollte auf ARIA verzichtet werden. Kreative Tag-Nutzungen sind allerdings keine gute Idee: Wenn ein Button als Überschrift verwendet werden soll, sollten Button und Überschrift in separaten Tags realisiert werden, statt die Funktionen zu kombinieren.

Sobald es aber darum geht, Nutzer von Screenreadern über Vorgänge auf dem Bildschirm zu informieren, ist ARIA natürlich das Mittel der Wahl. Diese Option steht in nativem HTML nicht zur Verfügung, genau so bietet ARIA erweiterte Optionen für Grids oder Menüs an, die die Screenreader-Tauglichkeit von Inhalten erweitern.

Single Page Applications: Ember 2 und React

Besonders problematisch in Sachen Barrierefreiheit sind die derzeit beliebten Single Page Applications. Während viele „klassische“ Websites immer noch irgendwie für Nutzer von Screenreadern verwendbar sind, auch wenn sie nicht optimal darauf ausgelegt wurden, ist bei Single Page Applications (SPA) schnell Schluss für sehbehinderte Menschen. Wenn sich nämlich nur die Inhalte verändern, ohne dass eine ganz neue Seite geladen wird, ist das für Screenreader nicht mehr auslesbar. Hier müssen Entwickler also besonders darauf achten, von Anfang an barrierefrei zu arbeiten.

Die Lösung für dieses Problem lautet, ein Event zu erstellen, das dem Screen Reader das Laden neuer Inhalte anzeigt. Patrick Fox hat sich einmal angeschaut, wie das in verschiedenen Frameworks funktioniert. In React steht Entwicklern die Methode componentDidUpdate() zur Verfügung. Diese wird nach jedem Update des Inhalts einer angezeigten Anwendung aktiviert und von Screenreadern aufgegriffen. Wer mit Ember 2 arbeitet, sollte allerdings vorsichtig sein. Die bislang verfügbaren Views wurden ersetzt. Wie Patrick Fox erklärt, kann das Problem aber über ein Router File umgangen werden. Hier kann über die renderTemplate() Methode ein Template-File spezifiziert und über das 'afterRender' Event festgelegt werden, dass nach dem Laden einer Seite eine Nachricht ausgegeben werden soll.

Angular

Auch in Angular 2 steht mit ngAfterViewInit ein ähnlicher Weg zur Verfügung, um SPAs für Nutzer von Screenreadern zugänglich zu machen. Das ist jedoch noch lange nicht alles. Gavin Ogston hat in einer Anleitung beschrieben, wie sich SPAs mit Angular und ngARIA barrierefreier gestalten lassen.

Wichtig, so Ogston, ist dabei zuerst einmal, dass bestimmte Grundlagen der Arbeit mit HTML auch bei Single Page Applications nicht vergessen werden. Ein einfacher Titel-Tag kann nämlich schon sehr hilfreich sein, um blinden Nutzern eine grundlegende Orientierung in SPAs zu ermöglichen. Außerdem sollten Views ebenfalls einen Namen bekommen. Um die Seite per Tastatur problemlos bedienen zu können, steht außerdem das ng-clickElement zur Verfügung, das sich mit allem kombinieren lässt – dadurch können native Elemente verwendet werden, was ja auch den Empfehlungen des W3C hinsichtlich ARIA entspricht.

Bootstrap & jQuery

Wer mit Bootstrap arbeitet, kann erneut auf eine Lösung von Paypal zurückgreifen. Das Bootstrap Accessibility Plugin bietet unter anderem eine Lösung für die bereits erwähnte Problematik der Karussells an, auch Dropdown-Menüs lassen sich damit barrierefrei gestalten. Ergänzt wird es durch das Bootstrap-a11y-theme, das eine pure CSS/LESS-Lösung darstellt.

Auch für jQuery gibt es inzwischen das ein oder andere Tool, um Websites barrierefreier zu gestalten. So können Accordion-Elemente wie Menüs mit Slide-Effekten über das jquery-accessible-accordion-aria-Plugin für blinde Nutzer verfügbar gemacht werden. Die Website von jQuery bietet außerdem eine ganze Sammlung von Plug-ins für mehr Barrierefreiheit an.

Wo anfangen?

Aber wo sollten Entwickler nun damit beginnen, ihre Projekte barrierefrei zu gestalten? Einige Tipps für mehr Barrierefreiheit haben wir bereits vor einigen Wochen zusammengefasst. Wer es aber noch genauer wissen will, kann sich an den WCAG 2.0-Richtlinien für barrierefreie Web-Inhalte orientieren. Diese ordnen die Erfordernisse barrierefreier Websites in verschiedene Stufen ein. Luke McGrath hat aus dieser ausführlichen Dokumentation eine Checkliste erstellt, anhand der Entwickler schnell erfassen können, wo ihr Webangebot steht und was zu tun ist, um bestehende Probleme zu lösen.

Das spannende daran ist: Viele der grundlegenden Ziele in Sachen Barrierefreiheit werden die meisten Entwickler bereits umsetzen, ohne darüber nachzudenken. Dass grüner Text auf rotem Hintergrund keine gute Idee ist, ist offensichtlich. Auch andere Tipps sind gar nicht so schwer zu realisieren, beispielsweise wenn es um die Vergrößerbarkeit von Text geht. Eine Vergrößerung von 200 Prozent ohne Verluste gehört sogar schon zur Mittelstufe der Barrierefreiheit! Perfekt muss also niemand sein, um seine Website ein wenig mehr darauf abzustimmen, dass wirklich jeder Nutzer damit interagieren kann.

Inklusion fördern

Mehr als jedes andere Medium hat das Internet das Potential dazu, ein wirklich inklusiver Raum für alle Nutzer zu sein. Mit Braille-Zeilen und Screenreadern, Touchscreens und Tastatur-Navigation; mit blickgesteuerten Cursor-Bewegungen und künftig vielleicht sogar mit Hilfe von Lorm Gloves (Handschuhen, die Textinhalte in das haptische Alphabet umsetzen, das taubblinde Menschen zur Kommunikation verwenden) können unzählige Menschen im Web aktiv werden. Dafür braucht es aber natürlich ein wenig Einsatz seitens derjenigen, die das Internet gestalten und mit Inhalten füllen. Das ist mit den richtigen Tools und Plugins allerdings gar nicht so schwer. Wenn die Bereitschaft dazu steigt, geht es im Web vielleicht bald nicht mehr darum, ob jemand blind, taub oder auf andere Art anders ist als andere Menschen. Dann macht das einfach keinen Unterschied mehr für die Verwendung virtueller Inhalte.

 

Go for PHP Developers

mit Terrence Ryan (google)

Everything you need to know about PHP 7.2

mit Sebastian Bergmann (thePHP.cc)

Aufmacherbild: vintage image of padlock with chain on mobile via Shutterstock / Urheberrecht: somrak jendee

Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -