November 2026

Barrierefreiheit gilt in vielen Projekten als Thema für später, bis ein Gesetz wie das Barrierefreiheitsstärkungsgesetz (BFSG) sie zur Pflicht macht. In einem Projekt der öffentlichen Verwaltung ist die Umsetzung der gesetzlichen Vorgaben zur Barrierefreiheit nicht optional. Unser Kollege Armin, der dort das Testmanagement verantwortet, hat aus erster Hand erlebt, wie Barrierefreiheit von einer Randnotiz zu einer strategischen Aufgabe wird, und was Testteams daraus mitnehmen können.

Barrierefreiheit gerät oft ins Hintertreffen

Die Erfahrung aus dem Projekt ist eindeutig: Barrierefreiheit steht häufig hinter anderen fachlichen und technischen Prioritäten zurück und wird erst spät in den Entwicklungsprozess integriert. Dieses Muster ist branchentypisch. Genau hier setzt eine zentrale Erkenntnis an: Barrierefreiheit lässt sich deutlich einfacher umsetzen, wenn sie bereits bei der Konzeption einer Anwendung mitgedacht wird.

Shift Left: warum früh günstiger ist als spät

Nachträgliche Anpassungen bestehender Systeme kosten erheblichen Aufwand. Benutzeroberflächen, Navigationskonzepte und Interaktionen müssen oft grundlegend überarbeitet werden. Im beschriebenen Projekt bietet ein bevorstehendes Redesign die Chance, Barrierefreiheit direkt in die Neuentwicklung einzubauen statt sie später aufwendig nachzurüsten. Das deckt sich mit einer der zentralen Empfehlungen aus dem Projekt: Barrierefreiheit von Anfang an berücksichtigen, also Shift Left. Wenn Architektur, Navigation und Komponenten von Beginn an barrierefrei entstehen, wird Accessibility Teil der Definition of Done und bleibt kein nachträglicher Prüfpunkt.

Der Zielkonflikt: wie viel Barrierefreiheit ist genug?

Ohne Spannungsfeld geht es trotzdem nicht. Nutzergruppen haben unterschiedliche Anforderungen: Manche bedienen eine Anwendung ausschließlich mit der Maus, andere sind vollständig auf Tastatursteuerung oder assistive Technologien angewiesen. Jede zusätzliche Funktion zur Unterstützung einzelner Nutzergruppen erhöht den Pflegeaufwand der Anwendung. Es braucht bewusste Priorisierung statt eines pauschalen "so viel wie möglich".

Risikobasiert testen, auch bei Accessibility

Wie beim funktionalen Testen ist es kaum möglich, sämtliche Nutzungsszenarien vollständig abzudecken. Auch bei Barrierefreiheit hilft ein risikobasierter Ansatz: zuerst die kritischsten Bedienabläufe und Anforderungen validieren, dann den Umfang erweitern. Konkret bedeutet das:

• kritische User Journeys zuerst testen
• häufig genutzte Funktionen priorisieren
• den Testumfang schrittweise ausbauen

Akzeptanz entsteht durch Verständnis

Nachträgliche Anpassungen empfinden Teams oft als zusätzlichen Aufwand, die Motivation fällt dann gering aus. In neuen Projekten, in denen Barrierefreiheit von Anfang an Teil der Architektur ist, gelingt die Umsetzung leichter. Ein wirksames Mittel für mehr Verständnis: Entwickler und Tester erleben die Perspektive der späteren Nutzer selbst. Eine einfache Übung lautet "Versuch die Seite einmal ohne Maus zu bedienen." Solche praktischen Erfahrungen, etwa die Bedienung per Tastatur oder mit assistiven Technologien, schaffen ein Bewusstsein dafür, dass Barrierefreiheit zur Softwarequalität gehört und keine reine Pflichtübung ist.

Accessibility kontinuierlich testen statt einmalig vor dem Release

Eine der wichtigsten Empfehlungen aus dem Projekt: Accessibility darf kein einmaliger Check kurz vor dem Release sein. Sinnvoll ist ein kontinuierlicher Ansatz mit drei Bausteinen:

1. automatisierte Prüfungen in der CI
2. manuelle Accessibility Reviews
3. regelmäßige Regressionstests

Fazit

Das BFSG macht Barrierefreiheit für viele Projekte zur Pflicht. Die größere Chance liegt darin, sie als festen Bestandteil von Architektur, Testen und Teamkultur zu verstehen statt als lästige Auflage. Wer früh beginnt, risikobasiert priorisiert und Accessibility kontinuierlich prüft, vermeidet teure Nachbesserungen und liefert am Ende ein Produkt, das für alle Nutzergruppen funktioniert.