Rechtslage, Architekturentscheidungen und vermeidbare Folgekosten
Digitale Barrierefreiheit in Deutschland: Wer muss ab wann was?
Jürgen Michael Kindler | 27.02.2026
Die rechtlichen Anforderungen an digitale Barrierefreiheit sind klarer geworden. Unklar bleibt jedoch häufig, was das konkret für Architektur, Komponentenwahl und Projektsteuerung bedeutet.
Barrierefreiheit ist kein nachgelagerter Qualitätscheck, sondern ein Indikator struktureller Reife.
Dieser Beitrag ordnet die aktuelle Rechtslage in Deutschland ein und zeigt, warum Barrierefreiheit weniger eine Frage einzelner Kriterien als eine Frage frühzeitiger Weichenstellungen ist.
Worum es hier geht – und worum nicht
Barrierefreiheit wird oft als Sammlung technischer Einzelmaßnahmen verstanden. In der Praxis entscheidet jedoch zuerst die Einordnung: Welche Pflichten gelten – und welche Folgen hat das für Scope, Abnahme und Betrieb?
- Worum es hier geht: Rechtslage in Deutschland, betroffene Bereiche, maßgebliche Standards sowie typische Projektfolgen (Artefakte, Prozesse, Abnahme).
- Worum es hier nicht geht: vollständige WCAG-Checklisten, Tool-Reviews, „Quick Fix“-Rezepte oder moralische Appelle.
Die zentrale Unterscheidung: Öffentlicher Sektor vs. Privatwirtschaft
Öffentlicher Sektor
Für öffentliche Stellen ist digitale Barrierefreiheit seit Jahren verbindlich. Neben der technischen Umsetzung gehören formale Anforderungen dazu, etwa eine Erklärung zur Barrierefreiheit sowie ein nachvollziehbarer Feedbackmechanismus.
Barrierefreiheit ist hier keine projektbezogene Option, sondern Bestandteil des laufenden Betriebs.
Privatwirtschaft
Seit dem 28.06.2025 ist Barrierefreiheit über das Barrierefreiheitsstärkungsgesetz (BFSG) für bestimmte Produkte und Dienstleistungen verpflichtend. Maßgeblich ist nicht „jede Website“, sondern der konkrete Anwendungsbereich.
Typisch betroffen sind verbrauchernahe digitale Dienstleistungen und E-Commerce-Angebote.
Wer muss ab wann was?
Die folgende Übersicht dient der schnellen Einordnung. Sie ersetzt keine Rechtsberatung, zeigt jedoch die wesentlichen Anwendungsbereiche und Stichtage.
- Wer? Öffentliche Stellen des Bundes und deren digitale Angebote.
- Ab wann? laufend (bestehende Verpflichtungen).
- Was praktisch vorhanden sein muss: barrierefreies Angebot + Erklärung + Feedbackweg + laufender Verbesserungsprozess.
- Typische Projektfalle: Audit als „Abschluss“ statt Backlog, Budget, Zuständigkeit.
- Wer? Je nach Landesrecht angebunden; Grundlogik wie beim Bund.
- Ab wann? laufend.
- Was praktisch vorhanden sein muss: wie oben; Details können je Land variieren.
- Typische Projektfalle: „betrifft nur Bundesbehörden“ – bis die erste Beschwerde kommt.
- Wer? Anbieter betroffener Produkte/Dienstleistungen (häufig verbrauchernah).
- Ab wann?seit 28.06.2025.
- Was praktisch vorhanden sein muss: barrierefreie betroffene Services + nachvollziehbare QA/Abnahme + Prozess im Betrieb.
- Typische Projektfalle: „ein bisschen UI-Fix“ ohne Scope-Klärung und ohne QA-Gates.
Maßstäbe und Standards: WCAG, EN 301 549 und das Zielniveau
Maßgeblich für die Bewertung digitaler Barrierefreiheit sind internationale Richtlinien und europäische Normen. In der Praxis wird dabei häufig auf WCAG 2.1 AA Bezug genommen.
Entscheidend ist weniger die Detaildiskussion einzelner Kriterien als eine klare Projektfestlegung: Welches Zielniveau gilt für Abnahme und Betrieb – und wie wird es nachvollziehbar dokumentiert?
Was das im Projekt konkret bedeutet
Barrierefreiheit wird handhabbar, wenn sie wie andere Qualitätsziele strukturiert behandelt wird: Scope klären, Artefakte definieren, Abnahme sichern.
1) Scope klären
- Welche Teile des Angebots sind betroffen? (z. B. Formulare, Suche, Login, Checkout, Downloads)
- Welche Nutzungsszenarien sind kritisch? (z. B. Antrag, Bewerbung, Bestellung, Terminbuchung)
- Welche Drittanbieter-Komponenten sind eingebunden? (z. B. Cookie-Banner, Video-Player, Captchas, Karten)
2) Artefakte definieren
- Erklärung zur Barrierefreiheit als Bestandteil des Qualitätsmodells
- Feedbackweg mit klarer Zuständigkeit
- A11y-Backlog (Findings, Prioritäten, Releases)
- Teststrategie (automatisiert und manuell, Verantwortlichkeiten geklärt)
3) Abnahme und Regressionsschutz
- Definition of Done mit klaren Mindestkriterien
- Release-Gates mit manuellen Prüfungen und ergänzenden Tools
- Wiederverwendbare, geprüfte Komponenten zur Reduktion von Varianz
Typische Stolperfallen
- Barrierefreiheit als Endkontrolle: Anforderungen werden erst spät geprüft, statt frühzeitig in Architektur und Komponentenstrategie verankert zu sein.
- Tool-Gläubigkeit: Automatisierte Prüfungen sind hilfreich, ersetzen jedoch keine strukturierte Einordnung und keine manuellen Tests.
- Unklarer Scope: Drittanbieter-Komponenten oder Randbereiche bleiben unbewertet und werden erst im Review sichtbar.
- Fehlende Zuständigkeit im Betrieb: Ohne definierte Verantwortlichkeiten entstehen wiederkehrende Befunde bei späteren Releases.
Fazit
Digitale Barrierefreiheit ist in Deutschland eine klar geregelte Anforderung mit definierten Maßstäben.
Entscheidend ist nicht die nachträgliche Fehlerkorrektur, sondern die frühzeitige Einordnung von Scope, Zielniveau und Verantwortlichkeiten. Wer diese Grundlagen klärt, reduziert Unsicherheit – und vermeidet unnötige Korrekturschleifen.
