Der FlixBus-Test – Ein Test-Szenario, viele Erkenntnisse

Nutzertests haben das Ziel, Praxiserfahrungen bei der Nutzung von Internetangeboten zu ermitteln und diese dann auf der Basis der Ergebnisse zu optimieren. Sie orientieren sich dabei in der Regel an Durchschnittsnutzern ohne besondere Einschränkungen. Die Probleme von Menschen mit Einschränkungen bleiben dadurch unberücksichtigt. Im Projekt Team Usability entwickeln wir Verfahren, bei denen Menschen mit Behinderungen die Nutzbarkeit von Webangeboten testen. Dafür werden im Projekt verschiedene Testszenarien erprobt und analysiert.

Ein solches Testszenario erprobten wir mit Patrick Dembinski. Er ist angehender IT-Kaufmann, ein versierter Screenreader-Nutzer und täglich online. Er nutzt den Screenreader JAWS und eine Braillezeile, hat aber bislang keine Expertise in der Prüfung der Barrierefreiheit von Webangeboten gemäß Standards wie den Web Content Accessibility Guidelines (WCAG).

Weil er gerne reist und dabei häufig verschiedene Beförderungsdienstleistungen, vom Bus über die Bahn bis zum Taxi, in Anspruch nimmt, haben wir uns für die Erprobung das Online-Angebot des Fernbusanbieters FlixMobility GmbH entschieden.

Die Aufgabe

Patrick sollte auf www.flixbus.de eine möglichst alltägliche Aufgabe durchführen. Er sollte einen Bus von Hamburg nach Paris buchen. Inbegriffen war der gesamte Buchungsprozess von der Verbindungssuche über die Auswahl einer Verbindung bis zum Bezahlvorgang.

Blinder Nutzer am Computer, unter seiner Tastatur befindet sich eine Braillezeile
Patricks erfasst Webinhalte mithilfe eines Screenreaders, einer Sprachausgabe und einer Braillezeile.

Wie sind wir vorgegangen?

Im ersten Schritt sollte unsere Testperson weitgehend selbstständig testen. Die vorgegebene Aufgabenstellung lautete lediglich: Buche eine FlixBus-Verbindung von Hamburg nach Paris und dokumentiere, wie das klappt, was Dir gut gefällt bzw. was Dir Schwierigkeiten bereitet. Der erste Test fand also selbständig statt, ein Szenario, das in Entwicklungsprozessen von Digitalprojekten sicherlich einen möglichen Bedarf abbildet. Agenturen könnten auf diese Art und Weise Menschen mit Behinderungen remote einbinden.

Die erste Analyse der Testergebnisse

Die Testergebnisse machten auf den ersten Blick den Eindruck, dass die FlixBus-Seite hinsichtlich Barrierefreiheit wohl schon ziemlich gut ist.

Um möglichst viele Erkenntnisse aus diesem Test-Szenario zu gewinnen, wurden die Testergebnisse genauer analysiert. Die Ergebnisse wurden mit den Augen eines Barrierefreiheits-Analysten betrachtet, d.h. sie wurden strukturierter mit den Anforderungen der WCAG abgeglichen bzw. nachvollzogen. Es fiel auf, dass unsere Testperson die Zugänglichkeit des Webangebots recht wohlwollend dokumentiert hatte. Möglicherweise ist es auch nicht einfach, Kritik zu üben?

Schwierigkeiten, die Patrick durch Hilfslösungen und Umwege beherrschen konnte, hatte er nicht benannt. Dokumentiert hatte er nur Barrieren, die die Nutzbarkeit sehr stark einschränkten. Sein Vorgehen entsprach also mehr dem eines geübten Screenreader-Nutzers, der im Weballtag Umwege und Kompensationsmechanismen gelernt hat, um - trotz Schwierigkeiten - irgendwie zum Ziel zu kommen.

Der zweite Test-Durchlauf

Als Grundlage für die Weiterentwicklung und Optimierung von Webseiten, wären detailliertere und kritischere Informationen von Vorteil.

Wir haben die Aufgabe nochmals durchgeführt: Die Testleiterin war beim Test anwesend, beobachtete die Testperson und machte vorab deutlich, dass es hilfreich ist, Auffälligkeiten zu benennen. Patrick sollte nun alles anmerken, was ihm Schwierigkeiten bereitet. Zudem versuchte die Testleiterin nachzuvollziehen, wie er sich hilft und welche Wege er findet.

Das Ergebnis: Mehr Zugänglichkeits-Probleme und bereichernde Usability-Erkenntnisse

Im zweiten Durchgang dokumentierten wir schon eine Menge mehr Zugänglichkeitsprobleme. Klare Barrieren – etwa Bereiche, die per Tastatur unzugänglich waren, wie die Buchung eines Sitzplatzes – bemerkte Patrick sofort. Zugänglichkeits-Probleme, die die Nutzung nicht so stark einschränkten, vermerkte in der Regel die beobachtende Testleiterin, die für Barrierefreiheits-Kriterien sensibilisiert ist.

Interessant waren die Erkenntnisse, die durch die praktische Nutzung auffielen. Zum Beispiel waren die Ergebnisse nach der Verbindungssuche nicht entsprechend der visuellen Darstellung korrekt mit semantischen HTML-Elementen als Tabelle strukturiert. Das bedeutete für den blinden Nutzer, dass er nicht mit den Möglichkeiten seines Hilfsmittels in den Ergebnissen navigieren konnte, sondern sich die Informationen mühsamer erschließen musste.

Spannend war auch zu sehen, welche Kompensationsmechanismen der Screenreader JAWS bereitstellt, d.h. wie die Software Barrieren zum Teil ausgleicht. Im Nachtest mit einem anderen Screenreader (nämlich NVDA) durch einen zweiten blinden Nutzer, konnten dieselben Kompensationsmechanismen nicht reproduziert werden. Die Screenreader gehen also mit Fehlern in Sachen Barrierefreiheit unterschiedlich um.

Die Testergebnisse finden Sie auf praxistest.de im Artikel Das Webangebot von FlixBus im Praxis-Test.

Fazit

  • Es ist wichtig, die Testperson vorab gut einzuführen und zu motivieren, dass sie alles benennen soll, was ihr auffällt, auch Negatives. Sie kann dazu beitragen, Schwachstellen aufzudecken und es ist deshalb sinnvoll und gewünscht, alles kritisch zu betrachten und Probleme aufzuzeigen.
  • Nutzertests ersetzen keine umfassende Barrierefreiheits-Prüfung. Auch wenn ein Nutzer auf der Site mit einer Aufgabenstellung zurechtkommt, bedeutet das nicht, dass das Webangebot den Barrierefreiheitsstandards entspricht.
  • Ein Nutzer vertritt nicht die ganze Nutzergruppe. Es handelt sich um eine individuelle Prüfung in einer bestimmten Umgebung (Browser, Hilfsmittel mit entsprechenden Einstellungen) und nicht zu vergessen mit einer bestimmten Hilfsmittelkompetenz. Es ist sinnvoll, auch Nutzer*innen mit weniger Hilfsmittelkompetenz einzubinden, da diese Probleme weniger „umschiffen“ können.
  • Was für eine Nutzergruppe nutzbar ist, kann für andere Nutzer*innen zu deutlicheren Problemen führen: Hier kam beispielsweise bei der Auswahl von Start- und Zielort der JAWS-Nutzer als Tastaturnutzer - wenn auch mit Schwierigkeiten – zurecht, wo hingegen sich die Eingabe für die sehende Tastaturnutzerin als völlig unzugänglich erwies.
  • Screenreader bieten verschiedene Kompensationsmechanismen; JAWS andere als etwa NVDA. Es ist daher wichtig, im Kopf zu behalten, mit welchen Hilfsmitteln der Tester arbeitet.
  • Bei der Durchführung von Nutzertests lernt man viel über „echte“ Nutzung mit Hilfsmitteln.
  • Die Ergebnisse von Nutzertests können hilfreich sein, um zu priorisieren und festzustellen, welche Barriere/Schwierigkeit am deutlichsten hervortritt und welche Auswirkungen sie hat. Beispielsweise kann eine Barriere die Durchführung einer wichtigen Aufgabe komplett blockieren, ein Grund sie präferiert zu beseitigen.