Barrierefreie Website: Was das BFSG seit 2025 verlangt

1) Was regeln BFSG & EAA – und wen betrifft das?

Das Barrierefreiheitsstärkungsgesetz (BFSG) setzt den European Accessibility Act (EAA) in Deutschland um. Es adressiert vor allem verbrauchergerichtete digitale Produkte und Dienste: E-Commerce-Websites/Apps, E-Book-Leser, Banking, Kommunikationsdienste, Selbstbedienungsterminals u. a. Ziel ist, Barrieren abzubauen, damit Menschen mit Behinderungen digitale Angebote gleichberechtigt nutzen können – ohne Speziallösungen. Für neue Produkte und Dienste gelten die Anforderungen ab dem 28. Juni 2025; es gibt Übergangsregelungen für ältere Verträge/Bestandsgeräte.

Entscheidend ist, ob über deine Website oder App ein Vertrag mit Verbrauchern zustande kommen soll. Das Gesetz spricht von Dienstleistungen im elektronischen Geschäftsverkehr (§ 2 Nr. 26 BFSG): Onlineshops, Buchungen und Terminvereinbarungen mit Vertragsabschluss, Ticketverkauf oder Kundenportale. Eine reine Informationsseite ohne Bestell- oder Buchungsfunktion ist von dieser Definition in der Regel nicht erfasst. Im Zweifel klärt das eine Rechtsberatung. Technisch orientiert man sich an EN 301 549 und den WCAG-Erfolgskriterien (wahrnehmbar, bedienbar, verständlich, robust).

Ausnahme für Kleinstunternehmen

Wer Dienstleistungen anbietet und ein Kleinstunternehmen ist, muss die Anforderungen nicht erfüllen (§ 3 Abs. 3 BFSG). Als Kleinstunternehmen gilt, wer weniger als 10 Personen beschäftigt und höchstens 2 Millionen Euro Jahresumsatz oder Jahresbilanzsumme hat (§ 2 Nr. 17 BFSG). Für Hersteller, Importeure und Händler von Produkten gilt diese Ausnahme nicht. Barrierefreiheit lohnt sich trotzdem: Eine gut bedienbare Website bringt mehr Anfragen und wird von Suchmaschinen besser verstanden.

Übergangsfristen

Dienstleister dürfen Produkte, die sie schon vor dem 28. Juni 2025 rechtmäßig eingesetzt haben, noch bis zum 27. Juni 2030 weiter nutzen. Vor diesem Stichtag geschlossene Verträge laufen unverändert weiter, längstens ebenfalls bis zum 27. Juni 2030. Selbstbedienungsterminals dürfen bis zum Ende ihrer wirtschaftlichen Nutzungsdauer betrieben werden, höchstens 15 Jahre ab Inbetriebnahme (§ 38 BFSG).

Pflichtangaben zur Barrierefreiheit

Betroffene Anbieter müssen in ihren AGB oder auf andere deutlich wahrnehmbare Weise erklären, wie ihr Angebot die Anforderungen erfüllt, und die zuständige Marktüberwachungsbehörde nennen (§ 14 und Anlage 3 BFSG). In der Praxis ist das eine eigene, gut auffindbare Seite „Informationen zur Barrierefreiheit“.

2) WCAG/EN 301 549 in der Praxis: Was bedeutet „AA-Niveau“ konkret?

Die WCAG strukturieren Barrierefreiheit in Prinzipien und Erfolgskriterien. Für Websites heißt AA grob: gute Kontraste (Text/Bilder), skalierbare Textgrößen, Tastaturbedienung ohne Fallen, sichtbare Fokus-Stati, verständliche Formulare (Labels, Fehlermeldungen, Hilfen), Alternativen für Medien (Alt-Texte, Untertitel, Transkripte) und robustes HTML (semantische Elemente, sinnvolle ARIA). Dazu kommen Anforderungen wie reflow, timeouts, orientation und – in WCAG 2.2 – focus appearance und dragging.

Wichtig ist der Prozess: Barrierefreiheit ist kein Sprint, sondern Teil der Produktentwicklung. Styleguide/Design-Tokens, Komponentenbibliothek, Code-Reviews, Test-Setups und Schulungen sorgen dafür, dass Standards nicht nur einmalig, sondern dauerhaft eingehalten werden.

3) Accessibility-by-Design: Rollen, Abläufe, Dokumentation

Setze Barrierefreiheit bereits im Briefing auf die Agenda. Definiere Rollen (Produkt, Design, Dev, QA), vereinbare Definition of Done mit A11y-Kriterien und pflege einen lebenden Styleguide. Bibliotheken mit zugänglichen Komponenten (Buttons, Form Controls, Dialoge, Tabs, Tabellen) sind der Turbo: Einmal sauber gebaut, überall sicher genutzt. Dokumentiere Muster (Keyboard-Flow, Fokusreihenfolgen, ARIA-Zustände) und halte sie in Code-Beispielen fest.

Plane Schulungen für Redaktion/Support: Alternativtexte, Überschriften, Tabellen, Linktexte, Untertitel/Transkripte. Gute Inhalte sind ein A11y-Hebel – schon vor dem ersten Zeile Code.

4) Quick Wins: Semantik, Formulare, Medien

Semantik: Nutze echte HTML-Elemente (h1–h6, p, ul/ol/li, table, button). Überschriften-Hierarchie muss logisch sein; keine Sprünge. Formulare: Jedes Input benötigt ein , Fehler müssen verständlich und programmatisch erkennbar sein (ARIA-Deskriptoren), Hilfetexte gehören in die Nähe des Felds. Medien: Sinnvolle Alt-Texte (keine Keyword-Füllung), Untertitel/Transkripte für Videos, Audio-Beschreibungen, falls nötig.

Keyboard: Fokusreihenfolge logisch, sichtbare Fokus-Stati, keine „Keyboard-Fallen“. Kontraste: Tokens in der Design-System-Palette definieren, damit kein „grau auf hellgrau“ passiert. Tabellen: Kopfzellen mit scope auszeichnen, Zusammenfassungen/Caption sinnvoll nutzen.

5) E-Commerce & Spezialfälle: Filter, Produktinfos, Checkout

Filter/Facetten: Steuerung per Tastatur, States programmatisch erkennbar (ARIA-Pressed/Selected), Live-Regionen für Ergebnisänderungen. Produktseiten: Strukturierte Infos (Preis, Varianten, Lieferzeiten), eindeutige Buttons (Add to Cart), sinnvolle Alternativtexte, Zoom/Ansicht ohne Maus nutzbar. Checkout: klare Reihenfolge, evidente Labels, Fehlerhinweise in Klartext (nicht kryptisch), Eingaben persistent halten, wenn ein Schritt fehlschlägt, und ausreichend Zeit geben.

Bonuspunkte: Wunschlisten/Später-kaufen, barrierearme Promotions (keine animierten Overlays ohne Steuerung), performante Seiten (CWV helfen auch A11y), und transparente Kundenkommunikation (z. B. Versand/Retouren).

6) Dokumente & PDFs: Häufiger Knackpunkt – so löst du ihn

PDFs sind oft nicht barrierefrei. Lösungswege: Web-First (Content als HTML), nur wenn nötig PDF – dann mit Tags, Lese-Reihenfolge, Alternativtexten, richtigen Überschriften und Formularfeldern. Für bestehende PDFs: priorisiere die „kritischen“ (z. B. Preisinformationen), stelle Übergangsweise HTML-Versionen bereit und plane mittelfristig eine Reduktion der PDF-Flut.

Denke an Medien-Alternativen (Untertitel/Transkripte) und an barrierearme Downloads (Dateinamen, Größen, Format-Hinweise). Dokumentiere, was schon compliant ist – und was wann umgestellt wird.

7) Test-Stack: Automatisiert, manuell, Assistive Technologien

Automatisiert: Linter/Build-Checks (HTML-Validität), Lighthouse/Axe für schnelle Hinweise. Manuell: Tastatur-Rundgang, Fokus-Verfolgung, Screenreader-Smoke-Tests (NVDA, VoiceOver). Assistive Technologien: Tests in typischen Browser/AT-Kombinationen. Wichtig: keine Checkbox-Mentalität – die Kriterien sind Leitplanken, entscheidend ist die reale Nutzbarkeit.

Dokumentiere Tests als lebende Artefakte (Checklisten, Screencasts, Tickets) und verknüpfe sie mit deiner Komponentenbibliothek. So bleibt Wissen im Team – und neue Kolleg:innen sind schneller produktiv.

8) Recht, Risiko & Kommunikation: So bleibst du gelassen

Halte fest, was du tust: Konzept, Styleguide, Komponenten, Testprotokolle, Release Notes. Transparenz hilft intern wie extern. Kommuniziere Verbesserungen auch öffentlich (Change-Logs, A11y-Seite) – das baut Vertrauen auf und motiviert dein Team. Bei unvermeidlichen Übergangsphasen (z. B. PDF-Altlasten) hilft ein Plan mit Terminen.

Wer kontrolliert? Seit dem 26. September 2025 ist die gemeinsame Marktüberwachungsstelle der Länder für die Barrierefreiheit von Produkten und Dienstleistungen (MLBF) in Magdeburg zuständig. Sie prüft auf Beschwerden hin oder stichprobenartig und fordert bei Mängeln zunächst zur Nachbesserung auf. Bei Verstößen drohen Bußgelder bis zu 100.000 Euro (§ 37 BFSG).

Rechtliche Beratung ersetzt das nicht – aber eine solide Dokumentation und sichtbare Fortschritte senken das Risiko deutlich. Und: Barrierefreiheit ist kein „Pflichtprogramm“. Sie verbessert die User Experience insgesamt – und macht deine Seite schneller, klarer und inklusiver.

9) 30/60/90-Tage-Plan: Struktur statt Stress

30 Tage: Audit (Kontraste, Tastatur, Formulare, Medien), Quick-Wins, Styleguide-Tokens, Komponenten-Prioritäten, PDF-Bestandsaufnahme.

60 Tage: Komponenten hart machen (Dialoge, Tabs, Tabellen), Schulungen, Test-Stack (autom./manuell/AT) einführen, E-Commerce-Spezialfälle anpacken.

90 Tage: PDFs reduzieren/nachrüsten, Monitoring etablieren, A11y in DoD integrieren, öffentlich kommunizieren (A11y-Seite/Changelog).

Häufige Fragen (FAQ)