User-Testing mit Menschen mit Behinderungen durchführen

1. Warum automatisiertes Testing echtes Nutzerfeedback nicht ersetzt

Automatisierte Werkzeuge prüfen strukturelle und technische Regeln: Ist ein Alt-Attribut vorhanden, ist der Kontrast ausreichend, existiert ein Label für ein Formularfeld. Keines dieser Werkzeuge kann jedoch beurteilen, ob eine Person mit Sehbehinderung eine Produktseite tatsächlich versteht, ob eine Person mit motorischer Einschränkung den Checkout in angemessener Zeit abschließen kann, oder ob eine Person mit kognitiver Beeinträchtigung sich in der Navigation zurechtfindet. Diese Fragen lassen sich ausschließlich durch Beobachtung echter Menschen bei echten Aufgaben beantworten.

Hinzu kommt, dass Menschen mit Behinderungen Hilfsmittel oft auf eine Weise nutzen, die von der Standardkonfiguration eines Entwicklers erheblich abweicht, etwa mit einer stark erhöhten Sprachgeschwindigkeit im Screenreader, einer angepassten Schaltererkennung bei einer Switch-Steuerung oder einer individuell konfigurierten Spracherkennung. Ein Entwicklerteam, das nur mit der Standardkonfiguration testet, übersieht systematisch genau die Fälle, in denen reale Nutzung am stärksten von der Annahme im Testlabor abweicht.

2. Rekrutierung diverser Testgruppen

Eine sinnvolle Testgruppe deckt nicht nur eine einzige Behinderungsart ab, sondern bewusst mehrere Kategorien: blinde und stark sehbehinderte Personen, die primär mit Screenreadern arbeiten, Personen mit motorischen Einschränkungen, die ausschließlich per Tastatur, Switch-Steuerung oder Spracherkennung navigieren, Personen mit kognitiven Beeinträchtigungen, für die Komplexität und Konsistenz besonders relevant sind, sowie schwerhörige oder gehörlose Personen, für die untertitelte Videoinhalte und visuelle Alternativen zu akustischen Hinweisen entscheidend sind.

Für die Rekrutierung eignen sich spezialisierte Agenturen und Panels, die bereits über verifizierte, erfahrene Testpersonen mit unterschiedlichen Behinderungen verfügen, ebenso wie die direkte Zusammenarbeit mit Behindertenverbänden oder Selbsthilfeorganisationen, die häufig ein Interesse daran haben, digitale Barrierefreiheit aktiv mitzugestalten. Wichtig ist dabei, Testpersonen fair und angemessen zu vergüten, unabhängig davon, ob die Rekrutierung über eine Agentur oder direkt erfolgt, da professionelles Feedback auch professionell honoriert werden sollte.

3. Testaufbau: Remote-Testing versus Testing vor Ort

Remote-Testing über Videokonferenz mit Bildschirmfreigabe hat den entscheidenden Vorteil, dass Teilnehmende ihre eigene, gewohnte technische Umgebung nutzen, also genau die Hard- und Softwarekombination, mit der sie tatsächlich täglich im Web unterwegs sind, statt sich an eine im Testlabor bereitgestellte, möglicherweise fremde Konfiguration anpassen zu müssen. Für Screenreader-Nutzende ist das besonders relevant, weil individuelle Einstellungen wie Sprachgeschwindigkeit oder bevorzugte Ausführlichkeit der Ansagen die Interaktion erheblich beeinflussen.

Testing vor Ort bietet dagegen den Vorteil einer direkteren Beobachtung, etwa der genauen Handbewegung bei motorischen Einschränkungen oder nonverbaler Signale wie sichtbarer Frustration, die über eine Videoverbindung leichter verloren gehen. In der Praxis hat sich ein hybrider Ansatz bewährt, bei dem der überwiegende Teil der Sitzungen remote stattfindet, ergänzt um einzelne Vor-Ort-Sitzungen für besonders komplexe Interaktionen wie einen vollständigen Checkout-Durchlauf.

4. Eigene Hilfsmittel der Teilnehmenden statt Standardkonfiguration

Ein häufiger methodischer Fehler ist, Testpersonen einen vom Team vorbereiteten Laptop mit einer neu installierten, unkonfigurierten Version von NVDA oder JAWS zur Verfügung zu stellen, statt ihnen zu erlauben, ihr eigenes Gerät mit ihrer über Jahre eingerichteten, hochoptimierten Konfiguration zu nutzen. Diese individuelle Konfiguration, etwa eine Sprachgeschwindigkeit von über vierhundert Wörtern pro Minute bei erfahrenen Screenreader-Nutzenden, ist Teil der tatsächlichen Nutzungsrealität und muss im Test erhalten bleiben.

Gleiches gilt für Browser-Erweiterungen, angepasste Tastaturkürzel oder spezielle Eingabegeräte wie einen Trackball oder einen adaptiven Schalter, die eine Testperson gezielt für ihre eigenen Bedürfnisse eingerichtet hat. Wird stattdessen eine sterile Testumgebung vorgegeben, misst das Team im schlimmsten Fall die Bedienbarkeit einer fremden, nie zuvor genutzten Konfiguration, statt der tatsächlichen Alltagsnutzung der Zielgruppe.

5. Realistische Aufgabenstellungen und Szenarien gestalten

Testaufgaben sollten konkrete, für den jeweiligen Shop typische Handlungen abbilden, etwa ein bestimmtes Produkt über die Filterfunktion zu finden, es in den Warenkorb zu legen und den Checkout bis zur Bestellbestätigung abzuschließen, statt abstrakt formulierter Anweisungen wie Erkunden Sie die Seite, die kein konkretes Erfolgskriterium liefern. Konkrete Aufgaben erlauben es zudem, objektiv zu messen, ob und wie lange eine Aufgabe zur erfolgreichen Erledigung benötigt.

Wichtig ist außerdem, den Teilnehmenden während der Aufgabe keine Hinweise oder Hilfestellungen zu geben, selbst wenn eine Barriere offensichtlich zu Frustration führt, da genau dieses Scheitern die wertvollste Erkenntnis des gesamten Tests liefert. Ein moderierendes Team, das vorzeitig eingreift, verfälscht das Ergebnis und verschleiert eine Barriere, die im echten Alltag ohne Unterstützung genauso zum Abbruch führen würde.

6. Moderationstechnik: Vertrauen aufbauen statt Bewertung

Die Moderation eines Tests mit Menschen mit Behinderungen unterscheidet sich in einem entscheidenden Punkt von klassischem Usability-Testing: Es geht nie um eine Bewertung der Fähigkeiten der Testperson, sondern ausschließlich um die Bewertung der Anwendung, weshalb dies zu Beginn jeder Sitzung explizit und unmissverständlich kommuniziert werden sollte. Eine Testperson, die das Gefühl hat, selbst geprüft zu werden, agiert vorsichtiger und liefert damit weniger authentisches Verhalten.

Zusätzlich sollte ausreichend Zeit eingeplant werden, deutlich mehr als bei einem Test ohne Behinderung, weil bestimmte Interaktionen mit Hilfsmitteln grundsätzlich länger dauern und ein zeitlicher Druck während der Sitzung selbst zu einer Fehlerquelle wird, die nichts mit der eigentlichen Barriere in der Anwendung zu tun hat.

7. Auswertung: Beobachtung statt reiner Screenreader-Ausgabe

Bei der Auswertung reicht es nicht aus, allein die vom Screenreader vorgelesene Ausgabe zu protokollieren, weil eine technisch korrekte Ansage trotzdem zu Verwirrung führen kann, etwa wenn eine Ansage zwar vorhanden, aber an einer für den Nutzungsfluss ungünstigen Stelle platziert ist. Entscheidend ist die Kombination aus beobachtetem Verhalten, etwa wiederholtem Zurückspringen im Fokus, geäußerter verbaler Reaktion während des lauten Denkens, und der tatsächlichen Erfolgsquote der gestellten Aufgabe.

Für eine strukturierte Auswertung eignet sich eine Tabelle, die jede beobachtete Barriere mit betroffener Aufgabe, betroffener Nutzergruppe, konkretem Zitat oder konkreter Beobachtung sowie einer ersten Einschätzung der Schwere verknüpft, damit die Rohdaten aus mehreren Sitzungen im Anschluss vergleichbar zusammengeführt werden können, statt als unstrukturierte Einzelnotizen verloren zu gehen.

8. Priorisierung der Erkenntnisse für die Entwicklung

Nicht jede beobachtete Schwierigkeit hat dasselbe Gewicht: Eine Barriere, die bei mehreren Testpersonen unabhängig voneinander zum vollständigen Abbruch der Aufgabe führte, etwa ein nicht fokussierbarer Bestätigen-Button im Checkout, hat oberste Priorität, während eine einzelne, subjektiv als unangenehm empfundene, aber überwindbare Unstimmigkeit niedriger priorisiert werden kann. Die Häufigkeit über mehrere Sitzungen hinweg ist dabei ein deutlich verlässlicherer Indikator als der erste Eindruck einer einzelnen Sitzung.

Diese priorisierten Erkenntnisse fließen anschließend in denselben Ticketing-Prozess ein, der auch für andere Accessibility-Findings genutzt wird, wobei ein Befund aus echtem Nutzertesting typischerweise mit höherer Priorität behandelt werden sollte als ein rein automatisiert gefundener Verstoß, weil er belegt nachgewiesenermaßen zu einem tatsächlichen Abbruch bei einer echten Person führte.

9. User-Testing als wiederkehrenden Prozess etablieren

Ein einzelner Testdurchlauf, egal wie sorgfältig durchgeführt, deckt nur den zum Testzeitpunkt bestehenden Zustand der Anwendung ab und verliert mit jedem größeren Redesign an Aussagekraft. Deshalb lohnt sich, User-Testing mit Menschen mit Behinderungen als wiederkehrenden Termin zu etablieren, etwa zweimal jährlich oder gezielt vor jedem größeren Relaunch einer zentralen Seite wie dem Checkout, statt es als einmaliges Projekt zu betrachten.

Über die Zeit entsteht so außerdem eine feste, wiederkehrende Gruppe vertrauter Testpersonen, die den Shop bereits kennen und dadurch gezielter auf konkrete Veränderungen zwischen zwei Testrunden eingehen können, was die Aussagekraft jeder einzelnen Runde zusätzlich erhöht.

10. Zusammenfassung

11. FAQ: User-Testing mit Behinderungen: Das Wichtigste auf einen Blick