Ein Buchungsformular kann unkompliziert wirken und trotzdem jemanden daran hindern, es auszufüllen. Eine Datumsauswahl erfordert vielleicht eine Maus, ein Fehler wird eventuell nur über Farben vermittelt oder ein Timeout löscht Eingaben, bevor die Person fertig ist. Barrierefreiheit betrachtet solche Hürden als festen Bestandteil der Funktionsweise eines Produkts.
Die Einführung des W3C in die Web-Barrierefreiheit stellt Menschen mit Behinderungen in den Mittelpunkt und berücksichtigt gleichzeitig den breiteren Nutzen. Die Arbeit erstreckt sich über Inhalte, Interaktionen, die Implementierung und die Technologien, mit denen Menschen darauf zugreifen.
Sowohl die Umsetzung als auch das Nutzungserlebnis evaluieren
Technische Prüfungen können Probleme wie fehlende barrierefreie Namen, unzureichenden Kontrast oder fehlerhafte Strukturen aufdecken. Tests mit Menschen mit Behinderungen zeigen, wie sich das Ganze unter realen Nutzungsbedingungen verhält. Diese Ansätze ergänzen sich: Eine kleine Studie kann nicht jede Anforderung abdecken, und ein automatisierter Scan kann nicht belegen, dass der gesamte Ablauf nutzbar ist.
Die Web Content Accessibility Guidelines bieten überprüfbare Kriterien rund um wahrnehmbare, bedienbare, verständliche und robuste Inhalte. Legen Sie den passenden Standard und Umfang für eine Evaluierung fest und kombinieren Sie dann automatisierte Checks mit gezielten manuellen Prüfungen. Rechtliche Vorgaben variieren je nach Kontext und müssen gesondert geprüft werden.
Für das Beispiel des Buchungsformulars kann dies die Tastaturbedienung, die Screenreader-Ausgabe, den Zoom, das Fokusverhalten, die Fehlerbehebung und das Zeitlimit für die Aufgabe umfassen. Wer nur den Startbildschirm testet, übersieht Hürden, die erst später im Prozess auftauchen.
Gezielt für das jeweilige Nutzungserlebnis rekrutieren
Menschen mit der gleichen Behinderung nutzen oft unterschiedliche Geräte, Einstellungen, Strategien und assistive Technologien. Richten Sie die Rekrutierung am Produkt und der Forschungsfrage aus und vermeiden Sie es, eine einzelne Person als stellvertretend für alle mit dieser Behinderung zu betrachten.
Gestalten Sie auch das Research-Setting selbst barrierefrei. Einladungen, Einwilligungserklärungen, Terminplanung, Testmaterialien und Kommunikationsformate können die Teilnahme beeinflussen. Fragen Sie nach individuellen Bedarfen und ermöglichen Sie es den Teilnehmenden, ihre gewohnten Einstellungen und Hilfsmittel zu nutzen, wo immer es die Studie zulässt.
Ein Prototyp bildet die Semantik oder das Interaktionsverhalten des späteren Produkts oft noch nicht vollständig ab. Machen Sie transparent, was sich mit dem jeweiligen Detaillierungsgrad sinnvoll bewerten lässt, und testen Sie die tatsächlich implementierte Version, sobald diese Details eine Rolle spielen.
Hürden bis zur bestätigten Lösung begleiten
Dokumentieren Sie genau, was den Fortgang blockiert hat, die jeweilige Umgebung und die konkreten Folgen für die Testperson. „Datumsauswahl konnte nicht per Tastatur bedient werden“ liefert dem Team deutlich mehr Anhaltspunkte als ein pauschales „Barrierefreiheitsproblem“.
Überprüfen Sie den Fix erneut und halten Sie an anderen Stellen nach ähnlichen Mustern Ausschau. Ein korrigiertes Element teilt seinen Aufbau womöglich mit vielen anderen, während ein kompletter Ablauf dennoch separate Hürden enthalten kann. Barrierefreiheit wird durch solche Design- und Entwicklungsentscheidungen dauerhaft gesichert – und Research hilft dem Team zu verstehen, welche ganz realen Folgen es hat, wenn hier Fehler passieren.