Barrierefreiheit scheitert selten am Konzept und fast immer an der Umsetzung. Der Accessibility-Berater Nic Steenhout prüft Entwürfe vor Beginn der Entwicklung und hört dabei oft denselben beruhigenden Satz: Dieser Entwurf lässt sich barrierefrei umsetzen.[1] Monate später fehlt dem fertigen Feature der Alternativtext, die Tastaturbedienung greift nicht, der Screenreader meldet keine Änderungen.
drweb.de als bevorzugte Quelle auf Google hinzufügenQualitätsgeprüfte Inhalte direkt in Google News & DiscoverJetzt hinzufügen
Das Wichtigste in Kürze
- Ein barrierefreier Entwurf beweist nur die Möglichkeit, nicht das Ergebnis. Über die Umsetzungsdetails entscheidet erst die Entwicklung.
- Barrierefreiheit verliert bei jeder Übergabe ihren Eigentümer, weil Design, Entwicklung, Test und Audit je einen Abschnitt besitzen, aber niemand den Übergang.
- Ein Audit am Projektende deckt Wochen ungeprüfter Entscheidungen auf, statt sie zu verhindern.
- Das Barrierefreiheitsstärkungsgesetz macht daraus ein Haftungsrisiko: bis zu 100.000 Euro Bußgeld, Maßstab ist WCAG 2.1 AA.
Warum ein barrierefreier Entwurf noch kein barrierefreies Produkt ist
Ein Design-Review und ein Accessibility-Audit beantworten verschiedene Fragen. Das Review klärt, ob sich ein Muster barrierefrei umsetzen lässt, also nur die Möglichkeit. Wie der Fokus wandert, welche Statusänderung ein Screenreader ansagt, wie eine Komponente ihre Semantik preisgibt, all das entscheidet erst die Entwicklung. So kann ein Review ehrlich bescheinigen, dass ein Feature barrierefrei werden kann, ohne etwas darüber zu sagen, ob es das am Ende wird.
Wissen über Barrierefreiheit führt nicht automatisch zu barrierefreiem Code. Entwickler jonglieren mit Geschäftslogik, Schnittstellen, Zustand, Tests und Fristen; Barrierefreiheit konkurriert mit all dem um Aufmerksamkeit. Auch das verbreitete Argument, geübte Tastaturnutzer bräuchten kein zusätzliches Wissen, trägt nicht: Code mit der Tastatur zu schreiben und eine Oberfläche ohne Maus zu bedienen sind zwei verschiedene Fertigkeiten.
Wo verschwindet die Barrierefreiheit im Projekt?
Niemand entscheidet bewusst, Barrierefreiheit zu ignorieren. Verloren geht sie in den Übergängen. Das Designteam besitzt den Entwurf, die Entwicklung den Code, die Qualitätssicherung den Test, das Audit die Prüfung. Was keinen Eigentümer hat, ist der Transport der Barrierefreiheit von einem Schritt zum nächsten.
Der zweite Fehler steckt im Timing. Fällt die erste Kontrolle nach dem Entwurf mit einem umfassenden Audit kurz vor dem Launch zusammen, legt sie Wochen ungeprüfter Entscheidungen offen, statt neue Arbeit zu schaffen. Kein Team würde die ersten Performance-Probleme eine Woche vor Release suchen oder das erste Sicherheitsreview nach dem letzten Commit ansetzen. Barrierefreiheit verdient dieselbe Behandlung.
Vier Eigentümer, kein Übergeber
Was das BFSG daraus macht
Ein barrierefreier Entwurf ist ein Versprechen, kein Nachweis. Ohne feste Abnahmekriterien an jeder Übergabe entsteht am Ende ein Produkt, das vor dem BFSG nicht besteht.
— Michael Dobler, Herausgeber Dr. Web
Was das BFSG aus dem Prozessfehler macht
Seit dem 28. Juni 2025 gilt das Barrierefreiheitsstärkungsgesetz und verpflichtet viele Anbieter digitaler Produkte und Dienstleistungen auf den Maßstab EN 301 549 und WCAG 2.1 AA.[2] Verstöße kosten bis zu 100.000 Euro Bußgeld; zusätzlich darf die Marktüberwachung ein Produkt vom Markt nehmen. Ausgenommen sind bei Dienstleistungen nur Kleinstunternehmen mit weniger als zehn Beschäftigten und höchstens zwei Millionen Euro Jahresumsatz.
Der Ausweg ist kein strengeres Audit, sondern ein Eigentümer an jeder Übergabe. Fokusreihenfolge, Tastaturverhalten und Ansagen gehören schon in die Entwurfsspezifikation und werden von dort zu testbaren Abnahmekriterien. Eine gemeinsame Bibliothek barrierefreier Komponenten spart die immer gleiche Fokus-Arbeit; automatisierte Prüfungen in der Build-Pipeline fangen häufige Fehler früh; ein kurzer Zwischencheck vor dem Launch ersetzt das späte Rundum-Audit.
Der erste Schritt kostet wenig: Halten Sie im nächsten Entwurf die Barrierefreiheits-Anforderungen schriftlich fest und machen Sie daraus Abnahmekriterien. Prüfen Sie danach jede Übergabe, nicht erst das Endprodukt.
Quellen
[1] Nic Steenhout: „Accessibility getting dropped in the process“
[2] Bundesministerium der Justiz: Barrierefreiheitsstärkungsgesetz (BFSG)
Mehr Newshunger?
- Barrierefreiheit per KI-Scanner: Was A11yEngine leistet und wo das BFSG mehr verlangt
- Wie ein blinder Kunde unsichtbare Barrierefreiheits-Lücken sichtbar machte
- Barrierefreiheitsstärkungsgesetz: Schreibt Ihre KI barrierefreien Code?
- Digitale Barrierefreiheit: So machen Sie Ihren Shop fit für alle Nutzer
- Barrierefreie Dokumente: Was Sie jetzt umsetzen müssen
