Barrierefreiheit und BFSG: Was Auftraggeber bei Webanwendungen im Lastenheft festhalten sollten

Seit dem 28. Juni 2025 gilt in Deutschland das Barrierefreiheitsstärkungsgesetz (BFSG). Es setzt die europäische Richtlinie (EU) 2019/882, den European Accessibility Act, in nationales Recht um. Wenn du eine Webanwendung, einen Onlineshop oder eine App für Verbraucher entwickeln lässt, kann das Gesetz auch dich als Anbieter betreffen. Der Entwicklungspartner setzt Barrierefreiheit aber nur um, wenn sie im Lastenheft steht. Dieser Artikel zeigt, wie du das einordnest und festhältst.

Wen das BFSG betrifft

Das BFSG gilt für bestimmte Produkte und Dienstleistungen, die Verbraucherinnen und Verbraucher nutzen. Dazu zählen unter anderem:

Dienstleistungen im elektronischen Geschäftsverkehr, also Onlineshops und andere Angebote, über die Verbraucher Verträge abschließen
Bankdienstleistungen für Verbraucher
Messenger-Dienste und andere elektronische Kommunikationsdienste
E-Books und dazugehörige Lesesoftware
Personenverkehrsdienste, soweit sie über Websites oder Apps buchbar sind

Rein interne Software für deine Mitarbeitenden und reine Business-to-Business-Angebote fallen nicht in diesen Anwendungsbereich. Für Kleinstunternehmen, also Unternehmen mit weniger als zehn Beschäftigten und höchstens zwei Millionen Euro Jahresumsatz oder Jahresbilanzsumme, sieht das Gesetz bei Dienstleistungen eine Ausnahme vor.

Ob dein konkretes Vorhaben unter das Gesetz fällt, hängt von Angebot, Zielgruppe und Unternehmensgröße ab. Lass das im Zweifel rechtlich klären, bevor du den Umfang festlegst.

Welcher Standard gilt

Das Gesetz selbst nennt keine Zeilen von Code, sondern Anforderungen. Die technische Konkretisierung für Webinhalte liefert die europäische Norm EN 301 549, die ihrerseits auf den Web Content Accessibility Guidelines (WCAG) 2.1 der W3C aufbaut. Als Zielvorgabe in Lastenheften hat sich daher "WCAG 2.1, Konformitätsstufe AA" etabliert.

Die WCAG gliedern sich in vier Prinzipien: Inhalte müssen wahrnehmbar, bedienbar, verständlich und robust sein. Konkret bedeutet das zum Beispiel:

Bilder haben Textalternativen für Screenreader.
Alle Funktionen sind per Tastatur bedienbar, ohne Maus.
Texte erreichen ausreichenden Farbkontrast zum Hintergrund.
Formulare beschriften jedes Eingabefeld und melden Fehler in Textform.
Inhalte bleiben bei 200 Prozent Vergrößerung nutzbar.

Barrierefreiheit im Lastenheft verbindlich machen

Der Satz "Die Anwendung soll barrierefrei sein" lässt sich nicht abnehmen. Verbindlich wird die Anforderung durch diese Bausteine:

Norm und Stufe benennen. Schreibe "Die Webanwendung erfüllt WCAG 2.1 Level AA" mit Verweis auf die Version. Eine neuere WCAG-Version kannst du ausdrücklich fordern, wenn du sie brauchst.
Geltungsbereich festlegen. Nenne, welche Bereiche erfasst sind: der Kaufprozess, das Kundenkonto, das Kontaktformular. Bei Verbraucherangeboten sollte der gesamte Weg vom Einstieg bis zum Vertragsabschluss gemeint sein.
Prüfverfahren vereinbaren. Lege fest, wie die Einhaltung nachgewiesen wird: automatisierte Tests mit einem Prüfwerkzeug, manuelle Tests mit Tastatur und Screenreader, gegebenenfalls ein externes Audit. Automatisierte Werkzeuge erkennen nur einen Teil der möglichen Barrieren, deshalb gehört mindestens eine manuelle Prüfung dazu.
Abnahmekriterium definieren. Halte fest, dass festgestellte Verstöße gegen die vereinbarte Stufe als Mangel gelten und vor der Abnahme behoben werden. So greift die normale Mängelregelung aus dem Abnahmeprozess.
Barrierefreiheitserklärung klären. Wer verpflichtet ist, muss Informationen zur Barrierefreiheit bereitstellen. Kläre, ob dein Dienstleister Texte und Angaben dafür zuliefert.

Barrierefreiheit früh einplanen

Nachträglicher Umbau ist aufwendiger als Berücksichtigung von Anfang an. Der Grund liegt in der Architektur: Wer Navigation, Formulare und Farben ohne Barrierefreiheit entworfen hat, muss beim Nachrüsten Bausteine neu gestalten, die bereits in der ganzen Anwendung verwendet werden. Plane deshalb Barrierefreiheit schon beim Design ein und nicht erst im Test vor dem Launch.

Auch die Wahl der Bausteine zählt. Bibliotheken für Oberflächen-Komponenten unterscheiden sich darin, wie gut sie Tastaturbedienung und Screenreader unterstützen. Frag deinen Entwicklungspartner, welche Komponenten er einsetzt und wie er deren Barrierefreiheit prüft.

Was bei Verstößen droht

Die Marktüberwachung liegt bei den Ländern. Sie können Maßnahmen anordnen, um Verstöße abzustellen, und Bußgelder verhängen. Hinzu kommt, dass Verbände Verstöße beanstanden können. Als Auftraggeber trägst du die Verantwortung für dein Angebot gegenüber Nutzern und Behörden. Ob und wie weit der Dienstleister dir gegenüber haftet, regelt der Vertrag. Auch deshalb gehört die Anforderung ins Lastenheft.

Fazit

Das BFSG gilt seit dem 28. Juni 2025 für bestimmte Verbraucherangebote. Wenn dein Vorhaben darunter fällt, brauchst du im Lastenheft eine konkrete Norm (WCAG 2.1 AA), einen definierten Geltungsbereich, ein Prüfverfahren und ein Abnahmekriterium. Plane Barrierefreiheit von Anfang an in Design und Komponentenwahl ein.

Häufig gestellte Fragen

Gilt das BFSG auch für interne Software?

Das Gesetz richtet sich an Produkte und Dienstleistungen für Verbraucher. Rein interne Software für Mitarbeitende fällt nicht in den Anwendungsbereich. Arbeitsrechtliche Anforderungen an barrierefreie Arbeitsplätze können unabhängig davon bestehen.

Reicht ein automatischer Barrierefreiheits-Test?

Automatisierte Werkzeuge finden nur einen Teil der Barrieren. Ob eine Alternativbeschreibung für ein Bild inhaltlich passt oder ob die Tab-Reihenfolge sinnvoll ist, lässt sich nur manuell beurteilen. Plane deshalb eine manuelle Prüfung ein.

Welche WCAG-Version soll ich fordern?

Die europäische Norm EN 301 549 verweist für Webinhalte auf WCAG 2.1 Level AA. Das ist die übliche Mindestanforderung. Neuere WCAG-Versionen kannst du zusätzlich fordern.

Muss ich bestehende Software nachrüsten?

Das hängt von Art des Angebots und Übergangsregelungen ab. Eine pauschale Antwort ist hier nicht möglich. Lass den Einzelfall rechtlich prüfen.