Das Barrierefreiheitsstärkungsgesetz (BFSG) gilt seit dem 28. Juni 2025. Wer jetzt noch nicht compliant ist, hat ein Problem.
Mit Inkrafttreten des Gesetzes haben die zuständigen Marktüberwachungsbehörden begonnen, Barrierefreiheitsanforderungen im Markt zu prüfen und bei Verstößen einzuschreiten. Erste BFSG-Verwarnungen im E-Commerce wurden bereits 2025 bekannt. Bußgelder bis 100.000 Euro sind möglich.
Dieser Artikel zeigt, wie Projektverantwortliche im Mittelstand Barrierefreiheit systematisch testen, welche Acceptance Criteria für Entwicklungsteams gelten und wie sich das Risiko realistisch einschätzen lässt.
Inhaltsübersicht
BFSG: Was jetzt gilt
Das BFSG setzt die EU-Richtlinie 2019/882 (European Accessibility Act) in deutsches Recht um.
Zuständig für die Durchsetzung ist die Marktüberwachungsstelle der Länder für die Barrierefreiheit (MLBF) in Magdeburg, die für die bundesweite Koordination verantwortlich ist.
Welche Websites betroffen sind
Das Gesetz erfasst Dienstleistungen im elektronischen Geschäftsverkehr. Das bedeutet: Websites und Apps, über die Verbraucher Verträge abschließen können.
Konkret betrifft das:
- Online-Shops
- Buchungsplattformen
- Vergleichbare B2C-Angebote
- Bankdienstleistungen
- Telekommunikation
- E-Book-Plattformen
Sie möchten wissen, wo Ihre Website steht?
Die B2B-Frage
Das BFSG gilt nur für Verbrauchergeschäfte. Aber: Schon die bloße Möglichkeit, dass Verbraucher eine Dienstleistung in Anspruch nehmen könnten, reicht aus. Im Zweifel wird eine B2C-Tätigkeit angenommen.
Wer sich auf B2B berufen will, muss das technisch und organisatorisch absichern.
Bußgelder nach § 37 BFSG
100.000 € maximales Bußgeld:
- Nicht barrierefreie Produkte in Verkehr bringen
- Nicht barrierefreie Dienstleistungen anbieten
- CE-Kennzeichnungsverstöße
10.000 € maximales Bußgeld:
- Dokumentationsmängel
- Fehlende Produktkennzeichnung
Zusätzlich drohen Produktrückrufe, Vertriebsverbote und wettbewerbsrechtliche Abmahnungen.
Ausnahme für Kleinstunternehmen
Unternehmen mit weniger als 10 Beschäftigten und entweder unter 2 Millionen Euro Jahresumsatz oder unter 2 Millionen Euro Bilanzsumme sind von den Anforderungen an Dienstleistungen befreit.
Für Produkte gilt diese Ausnahme nicht.
WCAG 2.2: Die neuen Kriterien
Die Web Content Accessibility Guidelines 2.2 wurden am 5. Oktober 2023 als W3C-Empfehlung veröffentlicht und umfassen insgesamt 87 Erfolgskriterien auf den Konformitätsstufen A (32 Kriterien), AA (24 Kriterien) und AAA (31 Kriterien). Für Level AA sind somit 56 Kriterien relevant.
Für digitale Dienstleistungen nach BFSG ist in der Praxis WCAG 2.1 Level AA maßgeblich, da die harmonisierte Norm EN 301 549 aktuell auf WCAG 2.1 AA verweist.
Eine Aktualisierung der EN 301 549 (Version 4.1.1) mit Bezug zu WCAG 2.2 ist für 2026 angekündigt. Die Bundesfachstelle Barrierefreiheit empfiehlt, WCAG 2.2 bereits jetzt umzusetzen.
Die vier neuen AA-Kriterien
2.4.11 Focus Not Obscured (Minimum)
Wenn ein Element den Tastaturfokus erhält, darf es nicht vollständig von anderen Inhalten verdeckt werden.
Das betrifft vor allem:
- Sticky Header
- Cookie-Banner
- Chat-Widgets
Diese Elemente dürfen fokussierte Bereiche nicht überlagern.
2.5.7 Dragging Movements
Funktionen, die Ziehbewegungen erfordern, müssen auch mit einfachen Zeigergesten bedienbar sein.
Das betrifft:
- Kanban-Boards
- Datei-Uploads per Drag-and-Drop
- Schieberegler
Alternative: Buttons oder Eingabefelder.
2.5.8 Target Size (Minimum)
Interaktive Elemente müssen mindestens 24 × 24 CSS-Pixel groß sein.
Ausnahmen gelten für:
- Inline-Links im Fließtext
- Elemente mit ausreichendem Abstand zu anderen Zielen
3.3.8 Accessible Authentication (Minimum)
Authentifizierungsprozesse dürfen keine kognitiven Funktionstests verlangen.
Das bedeutet:
- Keine Bild-CAPTCHAs ohne Alternative
- Passwörter müssen per Passwort-Manager eingefügt werden können
- Codes müssen per Copy-Paste übertragbar sein
Häufige Stolperfallen in Projekten
Die meisten Probleme entstehen bei:
- Sticky Headern, die den Fokus verdecken
- Drag-and-Drop-Komponenten ohne Tastaturalternative
- Kleinen Schließen-Buttons und Checkboxen unter 24 Pixel
- Captchas, die Screenreader-Nutzer ausschließen
„Das BFSG ist kein technisches Randthema. Es ist ein Geschäftsrisiko, das in die strategische Planung gehört. Wer jetzt handelt, spart später Geld und Ärger.“
"Barrierefreiheit beginnt im Design, nicht im Code. Wenn Kontraste, Zielgrößen und Fokuszustände von Anfang an stimmen, spart das im Development enorm viel Zeit."
Wusstet Du, dass ... ?
BITV 2.0 und BFSG: Was gilt wann?
Die BITV 2.0 (Barrierefreie-Informationstechnik-Verordnung) gilt für den öffentlichen Sektor. Das BFSG gilt für die Privatwirtschaft im B2C-Bereich.
Beide Regelwerke verweisen auf die europäische Norm EN 301 549, die aktuell WCAG 2.1 Level AA referenziert.
WCAG 2.2 soll analog zu WCAG 2.0 als internationale ISO/IEC-Norm übernommen werden; entsprechende Arbeiten laufen. Eine Aktualisierung der EN 301 549 (Version 4.1.1) mit Bezug zu WCAG 2.2 ist für 2026 angekündigt.
Vergleich BITV 2.0 vs. BFSG
BITV 2.0 (Öffentlicher Sektor)
- Technischer Standard: WCAG 2.1 AA
- Zusatzanforderungen: DGS-Videos, Leichte Sprache
- Durchsetzung: Monitoring, Beschwerden
BFSG (Privatwirtschaft B2C)
- Technischer Standard: WCAG 2.1 AA
- Zusatzanforderungen: Keine
- Durchsetzung: Marktüberwachung, Bußgelder
Sie betreiben eine Corporate Website oder einen Online-Shop?
Barrierefreiheit testen: Automatisiert vs. manuell
Automatisierte Testing-Tools finden je nach Studie zwischen 30 und 57 Prozent der Barrierefreiheitsprobleme.
Die Spanne erklärt sich durch unterschiedliche Messmethoden:
Nach einer Testreihe des UK Government Digital Service (GDS) zu automatisierten Accessibility-Tools erkannten selbst die besten Tools nur etwa 30 bis 40 Prozent der gezielt eingebauten Accessibility-Issues.
Eine Analyse von Deque Systems über mehr als 300.000 reale Issues kam auf rund 57 Prozent Erkennungsrate.
Wichtig: Kein einziges WCAG-Kriterium lässt sich vollständig automatisiert prüfen. Selbst bei Farbkontrasten, wo die Automatisierung am besten funktioniert, zeigen Evaluationsstudien, dass die Erkennungsrate deutlich unter 100 Prozent liegt und manuelle Nachprüfung notwendig bleibt.
Automatisierte Tools im Überblick
axe DevTools (Deque)
Stärken: Keine False Positives, 70+ Regeln, CI/CD-Integration
Einsatz: Entwicklungsteams
Kosten: Kostenlos (Basis), Pro kostenpflichtig
WAVE (WebAIM)
Stärken: Visuelles Feedback direkt auf der Seite
Einsatz: Designer, Content-Reviews
Kosten: Kostenlos
Lighthouse (Google)
Stärken: In Chrome integriert, nutzt axe-core
Einsatz: Schnelle Checks
Kosten: Kostenlos
Pa11y
Stärken: Kommandozeile, CI/CD-optimiert, Open Source
Einsatz: DevOps, Regressionstests
Kosten: Kostenlos
Was nur manuell geprüft werden kann
Automatisierte Tools erkennen, ob ein Alternativtext vorhanden ist. Ob der Alternativtext sinnvoll ist, können sie nicht beurteilen.
Das Gleiche gilt für:
- Die Qualität von Untertiteln
- Die logische Lesereihenfolge
- Das Verhalten bei dynamischen Inhaltsänderungen
- Die tatsächliche Nutzbarkeit mit Screenreadern
Screenreader-Tests
Für Tests sind NVDA mit Firefox sowie VoiceOver mit Safari besonders relevant, da diese Kombinationen laut WebAIM Screen Reader Survey #10 zu den meistgenutzten Screenreader-Setups gehören.
Der Survey zeigt, dass NVDA von 65,6 Prozent der Befragten genutzt wird und als kostenlose Alternative zunehmend an Bedeutung gewinnt.
Prüfen Sie:
- Navigation per Überschriften (H-Taste)
- Navigation per Landmarks (D-Taste)
- Navigation durch Formularfelder (F-Taste)
Acceptance Criteria für Entwicklungsteams
Barrierefreiheit funktioniert nur, wenn sie von Anfang an in den Entwicklungsprozess integriert wird.
Von WCAG-Kriterien zu User Stories
Jedes relevante WCAG-Kriterium sollte als testbare Abnahmebedingung in User Stories übersetzt werden.
Format:
- User Story: Als [Rolle] möchte ich [Funktion], damit [Nutzen]
- Abnahmekriterien: Spezifisches WCAG-Kriterium erfüllt [SC-Referenz], testbare Bedingung verifiziert
Priorisierung nach MoSCoW
MUST (Pflicht):
Level-A-Kriterien plus kritische AA-Kriterien wie Tastaturbedienbarkeit, Formularbeschriftungen, keine Tastaturfallen
SHOULD (Soll):
Verbleibende Level-AA-Kriterien
COULD (Kann):
Level-AAA-Kriterien und Verbesserungen
WON’T (Nicht jetzt):
Elemente, die eine dokumentierte unverhältnismäßige Belastung darstellen
Shift-Left-Ansatz
Studien und Praxisberichte aus der Software-Entwicklung zeigen, dass es erheblich günstiger ist, Accessibility-Anforderungen früh in Konzept und Design zu berücksichtigen, als sie nachträglich einzubauen.
Die Behebung von Barrierefreiheitsproblemen in der Entwicklungsphase ist deutlich schneller und kostengünstiger als in der QA oder nach dem Launch.
"Wir bauen Accessibility-Tests direkt in unsere CI/CD-Pipeline ein. So fangen wir Regressionen ab, bevor sie in Produktion gehen. Das automatisierte Testing ersetzt aber nie den manuellen Check."
"Der größte Fehler ist, Barrierefreiheit als Checkbox am Ende zu behandeln. Wenn wir von Anfang an semantisches HTML und ARIA-Labels richtig einsetzen, ist der Mehraufwand minimal."
Risikobewertung und ROI
Nach dem WebAIM Million Report 2025 weisen 94,8 Prozent der untersuchten Websites erkennbare WCAG-Verstöße auf. Durchschnittlich 51 Fehler pro Startseite.
Die sechs häufigsten Fehler
Diese sechs Fehlertypen verursachen 96 Prozent aller erkannten Fehler.
Regionale Auswertungen und Branchensplit zeigen, dass E-Commerce-Seiten im Schnitt mehr Accessibility-Fehler aufweisen als der Gesamtdurchschnitt.
Marktpotenzial
Laut Statistischem Bundesamt leben in Deutschland rund acht Millionen Menschen mit anerkannter Schwerbehinderung (GdB ≥ 50). Das sind knapp zehn Prozent der Bevölkerung.
Nach WHO-Daten haben weltweit rund 1,3 Milliarden Menschen eine Behinderung, etwa 16 Prozent der Weltbevölkerung.
Schätzungen wie der Bericht „The Disability Market“ gehen von einer jährlichen Kaufkraft von knapp sieben Billionen US-Dollar aus.
Abbruchraten
Untersuchungen zeigen, dass viele Nutzer mit Behinderungen Websites mit Barrieren sehr schnell verlassen.
Studien zu E-Commerce (u.a. Click-Away Pound) belegen deutlich höhere Abbruchraten in nicht barrierefreien Shops im Vergleich zu optimierten Angeboten.
Kostenvergleich
Studien und Praxisberichte zeigen, dass es erheblich günstiger ist, Accessibility-Anforderungen früh in Konzept und Design zu berücksichtigen, als sie nachträglich einzubauen.
Forrester und andere Analysten berichten in Fallstudien von sehr hohen Returns on Investment für Barrierefreiheitsmaßnahmen, teils im Bereich eines Vielfachen der ursprünglichen Investition.
Übergangsfristen
Produkte und Dienstleistungen, die nach dem 28. Juni 2025 auf den Markt gebracht werden, müssen sofort vollständig konform sein.
Begrenzte Übergangsfristen
- Dienstleistungen mit bestehenden Produkten:
Bis 27. Juni 2030 (gilt nicht für Webshops) - Selbstbedienungsterminals:
Bis zum Ende der wirtschaftlichen Nutzungsdauer, maximal 15 Jahre - Archiv-Inhalte:
Inhalte, die vor dem 28. Juni 2025 veröffentlicht und seitdem nicht aktualisiert wurden: bis 28. Juni 2030
FAQ - Häufig gestellte Fragen
Wie teste ich meine Website auf Barrierefreiheit?
Mit einer Kombination aus automatisierten Tools (axe DevTools, WAVE, Lighthouse) und manuellen Tests (Tastaturnavigation, Screenreader-Prüfung).
Nach aktuellen Studien finden automatisierte Tools 30 bis 57 Prozent der Probleme. Der Rest erfordert manuelle Prüfung.
Welche Acceptance Criteria gelten für WCAG 2.2?
WCAG 2.2 Level AA umfasst 56 Erfolgskriterien (32 Level A + 24 Level AA). Gegenüber WCAG 2.1 wurden vier neue AA-Kriterien eingeführt:
- 2.4.11 Focus Not Obscured (Minimum): Fokussierte Elemente dürfen nicht vollständig verdeckt werden
- 2.5.7 Dragging Movements: Drag-and-Drop-Funktionen brauchen Tastatur-Alternativen
- 2.5.8 Target Size (Minimum): Interaktive Elemente ≥ 24×24 CSS-Pixel
- 3.3.8 Accessible Authentication (Minimum): Keine kognitiven Tests bei Login
Jedes Kriterium sollte als testbare Abnahmebedingung in User Stories formuliert werden.
Welche WCAG 2.2 AA-Kriterien gibt es insgesamt?
Neben allen Level-A-Kriterien umfassen die 24 WCAG 2.2 AA-Kriterien Anforderungen zu:
- Perceivable: Untertitel Live (1.2.4), Audiodeskription (1.2.5), Kontrast Minimum (1.4.3), Reflow (1.4.10), Nicht-Text-Kontrast (1.4.11)
- Operable: Mehrere Wege (2.4.5), Überschriften/Labels (2.4.6), Fokus sichtbar (2.4.7), Fokus nicht verdeckt (2.4.11 neu)
- Understandable: Sprache Teile (3.1.2), Konsistente Navigation (3.2.3), Fehlervorschlag (3.3.3)
- Robust: Dragging Movements (2.5.7 neu), Target Size (2.5.8 neu), Accessible Authentication (3.3.8 neu)
Die vollständige Liste finden Sie in der W3C Quick Reference: filterbar nach Level, gut zum schnellen Nachschlagen.
Kann man Barrierefreiheit automatisiert testen?
Teilweise. Automatisierte Tools erkennen strukturelle Probleme wie fehlende Alt-Texte oder Kontrastfehler.
Sie können aber nicht beurteilen, ob ein Alt-Text sinnvoll ist oder ob die Seite tatsächlich mit einem Screenreader nutzbar ist.
Was passiert, wenn eine Website nicht barrierefrei ist?
Bußgelder bis 100.000 Euro, Vertriebsverbote, Produktrückrufe und wettbewerbsrechtliche Abmahnungen.
Mit Inkrafttreten des BFSG am 28. Juni 2025 haben die zuständigen Marktüberwachungsbehörden begonnen, Barrierefreiheitsanforderungen zu prüfen und bei Verstößen einzuschreiten.
Wie messe ich Barrierefreiheit und welchen ROI erzielt sie?
Messbar sind die Anzahl der WCAG-Verstöße (automatisiert), die Abdeckung manueller Tests und die Konformitätsstufe (A, AA, AAA).
Der ROI zeigt sich in niedrigeren Abbruchraten, breiterer Zielgruppenreichweite und vermiedenen Rechtskosten. Analysten berichten von hohen Returns on Investment für Barrierefreiheitsmaßnahmen.
Welche Quick-Wins gibt es, um Barrierefreiheit schnell zu verbessern?
Die sechs häufigsten Fehler (Kontrast, Alt-Texte, Formularlabels, leere Links und Buttons, Dokumentsprache) verursachen laut WebAIM 96 Prozent aller erkannten Probleme.
Diese lassen sich oft innerhalb weniger Tage beheben.
Wie integriere ich Barrierefreiheit in den agilen Entwicklungsprozess?
Barrierefreiheit gehört in die Definition of Done. Automatisierte Tests in der CI/CD-Pipeline fangen Regressionen ab. Manuelle Tests erfolgen sprintweise.
User Stories enthalten spezifische WCAG-Kriterien als Abnahmekriterien.
Nächste Schritte
Schnell-Assessment
Führen Sie einen automatisierten Scan mit axe DevTools oder WAVE durch. Die sechs häufigsten Fehlertypen zeigen den größten Handlungsbedarf.
Quick Wins umsetzen
- Kontraste anpassen
- Alt-Texte ergänzen
- Formularlabels korrigieren
- Leere Links und Buttons befüllen
- Dokumentsprache setzen
Prozesse anpassen
- Barrierefreiheit in die Definition of Done aufnehmen
- Automatisierte Tests in die Pipeline integrieren
- Manuelle Prüfungen einplanen
Sie möchten Barrierefreiheit in Ihrem Projekt systematisch angehen?
Quellen und Referenzen
Gesetze und Normen
- Bundesfachstelle Barrierefreiheit
- BFSG Gesetzestext
- W3C WCAG 2.2
- W3C – What’s New in WCAG 2.2
- W3C WCAG 2.2 Quick Reference
- EN 301 549 (Wikipedia)
Studien und Reports
- WebAIM Million Report 2025
- WebAIM Screen Reader Survey #10
- UK Government Digital Service (GDS) – Testreihe zu automatisierten Tools
- Deque Systems – Automated Accessibility Testing Coverage
- Click-Away Pound Report
Statistiken
- Statistisches Bundesamt – Schwerbehinderte Menschen
- World Health Organization (WHO) – Disability Report
