Nach oben

Fallstricke der Web-Accessibility: Beispiele aus der Praxis

Es mangelt nicht an Informationen, wie man barrierefreie Websites programmiert. Wir haben seit HTML 5 semantisches HTML. Dank der WAI-ARIA Initiative (Web Accessibility Initiative – Accessible Rich Internet Applications) haben wir Landmark Roles, ARIA-Attribute, Live Regions, States und Properties. Der unaufhaltsame Siegeszug von Javascript und AJAX führte dazu, dass immer komplexere Seiten programmiert werden konnten. Ohne ARIA (seit 2014 empfohlener Standard des W3C) sähe es für die Accessibility schlecht aus.

Wir gehen hier davon aus, dass Sie die meisten Accessibility-Sünden bereits kennen:

  • Bilder ohne Alternativtext
  • Formular-Elemente ohne Label
  • Überschriften-Struktur nicht korrekt (h1-h6)
  • Keine Fokus-Auszeichnung (outline)
  • Mangelnder Farbkontrast
  • Klickflächen zu klein
  • Schrift zu klein
  • Seite lässt sich nicht problemlos zoomen, ohne dass Layout zusammenbricht
  • Custom-designed Formular-Elemente, die ohne Maus nicht bedienbar sind
  • Kein semantisches HTML (sondern “DIV-Suppe”)
  • Wenig aussagekräftige Linktexte (“Mehr”, “Hier”)
  • Keine Quick-Jump Navigation (“jump to content” usw.)
  • Akkordeons und Tabs (Reiter), die nur mit der Maus bedienbar sind

Wir möchten Sie daher in diesem Artikel eher auf spezifische Stolpersteine aufmerksam machen.

Eine kleine Auswahl von typischen Accessibility-Fallstricken:

Frameworks ungeprüft einsetzen

Frontend-Frameworks können uns das Arbeiten wesentlich vereinfachen. Kein Programmierer, der etwas auf sich hält, möchte in jedem neuen Projekt das Rad neu erfinden (und kein Kunde der Welt ist bereit, dafür das nötige Budget locker zu machen). Es ist legitim (und gängige Praxis), bewährte Tools/Libraries/Frameworks einzusetzen. Das kann eine Frontend-Komponente sein wie eine Lightbox, eine Slideshow oder ein Akkordeon.

Zum Problem wird das, wenn solch eine 3rd-party Komponente nicht barrierefrei-optimiert worden ist, und Ihr Programmierer auch keinerlei Verbesserungen daran vornimmt. Oder wenn man einfach annimmt, dass dies automatisch schon der Fall sein muss, nur weil diese Library schon millionenfach heruntergeladen worden ist bei GitHub. Hier ist ein Beispiel aus der React-Welt.

Manche erinnern sich noch an das Accessibility-Plugin von Paypal, das Twitter Bootstrap 3 erst Accessibility-tauglich machte. Bootstrap 4 hat zwar Fortschritte gemacht, aber selbst gemäss Twitter’s eigenen Angaben muss man noch selbst nachhelfen, um Barrierefreiheit zu gewährleisten.

Getrost vergessen kann man Libraries wie Semantic UI. Daran ist gar nichts semantisch. Eine Frontend-Library, die 2019 Accessibility ignoriert, ist keine Frontend-Library. Dieses Akkordeon z.B. wird von der Tastatur komplett übersprungen.

Modals: typische Fokus-Fallen

Der Challenge hier liegt darin, dass der Fokus nicht verlorengeht, sobald sich das Modal öffnet. Stellen Sie sicher, dass man mit der Tastatur normal vorankommt. Was banal tönt, ist in der Praxis oft verheerend schlecht umgesetzt: Bei gewissen Browsern bleibt man einfach stecken, wenn man nur mit der Tastatur navigiert (kann weder vorwärts noch rückwärts navigieren) und kann das Modal auch nicht schliessen (üblicherweise mit der ESC-Taste).

Leute, die auf die Tastatur angewiesen sind, haben im Worst Case Scenario sonst Pech: Sie können sich weder registrieren noch einen Kauf im Online-Shop abschliessen (zwei häufige Anwendungsfälle von Modals).

Das beliebte Javascript Plugin Magnific Popup z.B. hat bis heute «out of the box» keine befriedigende Accessibility. Hier ist eine optimierte Version. Dieser Artikel erklärt die nötigen Anpassungen.

Weitere Beispiele aus dem Accessibility Developer Guide.

Flexbox Order

Flexbox ist eine CSS-Technologie, die zu recht sehr populär ist. Sie erweitert die Gestaltungsmöglichkeiten enorm. Nebst vielen anderen Features lässt sich z.B. die Reihenfolge von Elementen innerhalb eines Containers definieren. Ohne Flexbox wäre dies weit aufwändiger, und es überrascht denn auch nicht, dass davon rege Gebrauch gemacht wird.

Das Problem ist jedoch der Flexbox & keyboard navigation disconnect.

Screenreader foutieren sich um CSS Flex-Order. Sie lesen stur einen Inhaltsblock nach dem anderen vor, genau so wie der DOM-Baum es vorgibt. Das mag nun nicht sonderlich dramatisch anmuten. Aber dort, wo die Reihenfolge der Text-Informationen eine grosse Rolle spielt, kann es sehr verwirrend werden, wenn auf einmal die unwichtigsten Informationen zuerst erscheinen, und das wichtigste zuletzt. Oder noch schlimmer: wenn man Labels und Daten hat, die ihren Bezug zueinander verlieren (z.B. Email: +412477878).

Im Zweifelsfall sollten Sie in solchen Situationen auf Flexbox verzichten und andere Lösungen bevorzugen, z.B. Tabellen oder Listen.

Screen-Benachrichtigungen

Fast jede Website setzt hier und dort Benachrichtigungen ein in Form von kurz eingeblendeten Bannern. Das können Feedbacks sein, nachdem man ein Formular abgeschickt hat (Error / Success), oder Status-Meldungen («Artikel wurde dem Warenkorb hinzugefügt»). Oder auch das meistgehasste Web-Feature überhaupt: Cookie-Consent Popups.

Wenn solche Elemente unsauber programmiert sind, kann es sein, dass Screenreader keine Rückmeldung vorlesen. Dabei gibt es einfache Möglichkeiten, das korrekt umzusetzen: Eine aria-live Region genügt oft schon.

Formulare, Formulare, von der Wiege bis zur Bahre

Komplexe Formulare können eine Herausforderung sein für Entwickler. Das Frontend muss permanent mit dem Backend kommunizieren via AJAX, und ausserdem darauf achten, dass der User keine Falsch-Eingaben macht, oder Pflichtfelder leer lässt. Auch hier gibt es unterstützende Methoden: role=“alert“ kann z.B. bereits genügen, um dem User mitzuteilen, dass ein Pflichtfeld nicht ausgefüllt wurde. Leider sehen wir das viel zu wenig in der Praxis.

Beispiele aus dem Accessbility Developer Guide.

Karten, Infografiken, Charts

Wir alle lieben sorgfältig aufbereitete, farbige Karten, Infografiken, Charts und dergleichen. In der Regel werden sie eingesetzt, um reine Text-basierte Datenreihen (Listen, Tabellen) einfacher zu interpretieren und zu vergleichen. Solche oft hoch-komplexe, multidimensionale, dynamische Inhalte Sehbehinderten zugänglich zu machen, ist jedoch nicht immer trivial. Je nachdem welche Technologie man einsetzt, um solche Infografiken zu erstellen, kann das einen gewissen Mehraufwand in der Produktion bedeuten (z.B. falls das CMS das nicht schon automatisch erledigt im Hintergrund).

Problem Barrierefreiheit gelöst: Diagramme enthalten im Hintergrund versteckte Tabellen, die von Bildschirmleseprogrammen vorgelesen werden. (Bild: Bundesamt für Meteorologie und Klimatologie MeteoSchweiz)
Problem Barrierefreiheit gelöst: Diagramme enthalten im Hintergrund versteckte Tabellen, die von Bildschirmleseprogrammen vorgelesen werden. (Bild: Bundesamt für Meteorologie und Klimatologie MeteoSchweiz)

Chatbots

Sie werden immer beliebter. In Zeiten in denen Jugendliche gar nicht mehr wissen, was Email ist, wird snapchattet und whatsapped, was das Zeug hält. Die milliardenschweren Marktführer dieser Branche haben mittlerweile Accessibility-Mechanismen eingebaut in ihren Produkten. Die ganze Conversational Interface Start-Up-Branche, die wie Pilze aus dem Boden spriesst, sind hingegen noch weit davon entfernt, adäquate barrierefreie Produkte auf den Markt zu bringen. Die meisten von ihnen sind zu sehr damit beschäftigt, weiteres Venture Capital zu ergattern, um über das nächste Quartal zu kommen, als sich um die realen Bedürfnisse ihrer Kundschaft zu kümmern. So verwundert es auch nicht, dass die vorgefertigten Chatbot-Interfaces, die man sich in die eigene Website einbinden kann, in der Kategorie Accessibility die untersten Ränge belegen.

Ein Beispiel: Gewisse UI-Elemente werden von VoiceOver nicht vorgelesen, und Buttons werden nicht als solche wahrgenommen:

Unser Rat: Bevor Sie sich für eine Chatbot-Lösung entscheiden, testen Sie das Produkt ausgiebig auf Barrierefreiheit.

Vertrauen ist gut, testen ist besser.

Die Liste liesse sich beliebig verlängern. Kurzum: Je mehr Interaktivität und Javascript im Spiel sind, desto eher müssen Sie selber nachbessern und optimieren.

Wir haben kürzlich der SBB geholfen, ihre Website erfolgreich zertifizieren zu lassen (AA+). Seit die Stiftung Zugang für Alle den Accessibility Developer Guide in’s Leben rief, ist Zeix auch tatkräftig mit dabei.

Wichtig ist: Sie können sich nicht darauf verlassen, dass eine Komponente zuverlässig accessible ist. Um’s testen kommt man nicht herum: Mit gängigen Browsern, Smartphones und Tablets. Mit Screenreadern. Ohne die Maus zu benutzen, sondern ausschliesslich mit der Tastatur.

Dass dies aufwändig ist, muss nicht extra erwähnt werden. Ideal ist, wenn man Accessibility-Tests kontinuierlich macht, wenn es innerhalb der Abarbeitung der JIRA-Tickets, beim Code-Review oder wenigstens Ende eines Sprints passiert. Wenn Sie es hinausschieben bis 5 Minuten vor Going Live, kommt’s selten gut.

Manche Auftraggeber sind noch nicht so sensibilisiert in Sachen Barrierefreiheit. Daher kann es vorkommen, dass die Aufwände für Optimierungen und das Testing (wenn sie entsprechend ausgewiesen werden) nicht honoriert werden. Accessibility-Optimierungen auf die lange Bank schieben rächt sich jedoch irgendwann später: Nach einem Launch Code anpassen ist immer teurer, als wenn man sich vorher drum kümmert.

Projektverantwortliche auf Auftraggeberseite sollten sich bewusst sein, dass gute Accessibility nicht nur eine ethische Pflicht, sondern auch good business sense ist. Diesen Aspekt leuchten wir in diesem Artikel aus.


Werkzeuge und Methoden

Weitere Zeix-Artikel zum Thema Accessibility:

Externe Links:

Accessibility Insights – von Microsoft lanciertes Tool für Chrome, Windows, Edge:
https://accessibilityinsights.io/

The WebAIM Million: Eine Accessibility-Analyse der Top 1’000’000 Home Pages:
https://webaim.org/projects/million/

Inclusive Components – Accessible User Interface Komponenten / Pattern Library:
https://inclusive-components.design/

We need to talk about Accessibility on Chatbots: What happens when a blind person wants to use your chatbot?
https://uxdesign.cc/we-need-to-talk-about-accessibility-on-chatbots-98cf93c54963

Accessible chatbot design: 7 Prinzipien / Empfehlungen
https://www.canaxess.com.au/infocard/chatbots

Unsere Dienstleistungen für User-Centered Design

Wir bieten alle Dienstleistungen rund ums Frontend und sind vertraut mit verschiedenen Projekt-Management-Methoden wie Scrum oder Hermes.

Alle Phasen der Produktentwicklung mit User-Centered Design

Kommentare

Kommentar schreiben

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.