Als Website-Betreiber:in, Entwickler:in oder Auftraggeber:in bemühen Sie sich darum, Ihre Website barrierefrei zu machen. Vielleicht haben Sie wie ich hierfür zahllose Artikel und Anleitungen zum Thema gelesen und mittels Learning-by-Doing versucht, die Sache richtig anzugehen und Barrieren für alle Nutzer:innen zu senken. 

Um herauszufinden, ob sich Ihre Bemühungen gelohnt haben oder ob Sie aus Versehen etwas verschlimmbessert haben, eignet sich das Ad-hoc Testing sehr gut. 

In diesem Blogbeitrag erzähle ich Ihnen, wie ich das Ad-hoc Testing aus der Perspektive eines Entwicklers erlebe und wie Sie den grösstmöglichen Nutzen daraus ziehen.

Was ist Ad-hoc Testing?

Bei einem klassischen Review oder Audit testet ein gemischtes Team aus Expert:innen mit und ohne Behinderungen eine Website oder eine Applikation. Als Auftraggeber:in erhalten Sie anschliessend einen ausführlichen Ergebnisbericht mit umfassenden Beschreibungen der Mängel und der möglichen Verbesserungsmassnahmen. 

Das Ad-hoc Testing läuft ganz anders ab. Während einer solchen Testsession erleben Sie live, wie jemand mit eingeschränktem Sehvermögen durch Ihre Website navigiert. Sie hören direkt, was der Screenreader dabei vorliest und ob das Vorgelesene verständlich ist. Dadurch erfahren Sie unmittelbar, wo die Testperson auf Barrieren stösst und was Sie an Ihrer Website verbessern müssen. 

Für mich als Sehenden ist es immer wieder beeindruckend zu erleben, wie sich jemand mittels Screenreaderauf einer Website bewegt. Anders als bei einem statischen Testbericht erlebe ich zusammen mit der Testperson dieselbe User Experience und kann die Barrieren besser verstehen. Das wiederum hilft mir zu erkennen, worauf ich bei der Web-Entwicklung achten sollte. Was ich zudem besonders schätze am Ad-hoc Testing, ist die Möglichkeit, verschiedene Lösungsideen zu diskutieren und auszuprobieren. 

Ad-hoc Testing: Entwicklungsumgebung und Durchführung

Beim Ad-hoc Testing ist das spontane Feedback der Testpersonen von besonderer Bedeutung. Deshalb bedarf es keiner grossen Vorbereitung, weder von Seite Auftraggeber:in, noch vom Test-Team. Die Testpersonen brauchen lediglich Zugang auf die Webseite, welche auf der Maschine vom Entwickler gehostet wird, denn das Testen findet auf dem eigenen Computer des Screenreader-Anwenders statt. 

Warum eine Entwicklungsumgebung nutzen?

In den Testsessions wird die Entwicklungsumgebung genutzt und nicht etwa die Staging- oder die Produktionsumgebung. 

Die Entwicklungsumgebung hat den Vorteil, dass Sie unmittelbar auf das User-Feedback reagieren können. Noch während der Testsession können Sie verschiedene Lösungsansätze ausprobieren und den Code live ändern, bis Sie die richtige Lösung gefunden haben.

Das Ad-hoc Testing ist zeitlich begrenzt, weshalb sich selbstverständlich nicht alle Probleme so einfach und schnell lösen lassen. Einige erfordern eine komplexe Lösung oder sogar eine konzeptionelle Überarbeitung. In diesen Fällen ist es sinnvoll, dass Sie sich Notizen dazu machen, Fragen stellen und sich später darum kümmern. In vielen Projekten ist es sinnvoll, das Ad-hoc Testing mehrmals über einen Zeitraum von mehreren Wochen zu wiederholen, bis Sie alle vorhandenen Barrierefreiheitsmängel behoben haben.

Online via Videokonferenz testen

Für ein erfolgreiches Ad-hoc Testing ist es wichtig, dass Sie sehen und hören können, was die Testperson sieht und hört. Wenn die Testperson die Website mithilfe eines Screenreaders bedient und Sie live mithören können, was der Screenreader vorliest, verstehen Sie besser, wie die Software die Inhalte interpretiert. In unseren Live-Tests haben wir mit Microsoft Teams gute Erfahrungen gemacht: Die Testperson kann in MS Teams sowohl den Ton des Screenreaders als auch den Bildschirm mit Ihnen teilen. 

Vorteile des Ad-hoc Testings

Meiner Meinung nach ist das Ad-hoc Testing eine wirklich effiziente Methode, um die Barrierefreiheit einer Website zu testen. Es erfordert nur minimale Vorbereitung und das Testing selber dauert nicht lange – unsere Test-Sitzungen dauerten in der Regel eine bis zwei Stunden. 

Da Sie den Test live durchführen, braucht es keinen ausführlichen Testbericht mit Screenshots und detaillierten Beschreibungen. Als Auftraggeber sind Sie live dabei und erleben mit, was die Testperson erlebt. Alle benötigten Informationen halten Sie direkt in Ihren eigenen Notizen fest. 

Ein weiterer Vorteil ist, dass Sie beim Beobachten des Screenreader-Users viel lernen können. Es ist mir schon öfters passiert, dass ich eine Funktion implementierte und dachte, ich hätte alles richtig gemacht in Bezug auf die Barrierefreiheit. Beim Live-Test zeigte sich jedoch, dass genau diese Funktion die User Experience der Testperson stört. 

Gerne zeige ich dies an einem konkreten Beispiel auf: Ein Hamburger-Menü soll über die Tastatur zugänglich sein. Bei diesem Element fügte ich einen Focustrap hinzu, damit der Fokus nicht versehentlich das Menü verlässt. Wenn man das Hamburger-Menü öffnete, erhielt das erste Element automatisch den Fokus und man konnte mit den Pfeil- und Tabulatortasten durch die Elemente navigieren. Wenn Sie die Pfeil- oder Tabulatortaste am Ende der Liste drückten, wurde der Fokus wieder auf das erste Element gesetzt. Durch Drücken der Escape-Taste konnte man das Menü wieder verlassen. Das funktionierte alles sehr gut. Was mir nicht klar war: Dies ist nicht das Standardverhalten, das Screenreader-Anwender erwarten würden. Die Testperson blieb im Menü stecken, weil die Tabulatortaste immer wieder durch das Menü rotierte, anstatt zum nächsten fokussierbaren Element zu wechseln. Der Testperson war es nicht bewusst, dass sie das Menü mithilfe der Escape-Taste verlassen musste. 

Fazit

Ich bin überzeugt, dass Ad-hoc Testing eine gute Möglichkeit ist, um sicherzustellen, dass Funktionen einer Website, die der Barrierefreiheit dienen sollen, in der realen Welt tatsächlich funktionieren.

Das Aufsetzen und die Durchführung eines solchen Live-Tests sind einfach und die Sessions nehmen nicht zu viel Zeit in Anspruch. Sie erhalten von den Testpersonen ein unmittelbares Feedback und können viele kleinere Probleme noch während der Sitzung aus dem Weg räumen. Was Sie durch das Beobachten lernen, ist von unschätzbarem Wert für künftige Projekte. 

Über den Autor

Corsin Conzett schloss 2017 seine Lehre als Applikationsentwickler ab. Danach begann er als Webentwickler bei der LAB360 GmbH mit dem Fokus auf Frontend-Entwicklung. Er ist motiviert, mehr über Barrierefreiheit zu lernen, und hofft, dass er sein erworbenes Wissen bei künftigen Website-Projekten vermehrt anwenden kann.