BFSG Checkliste 2026: Barrierefreie Website erstellen

Das Barrierefreiheitsstärkungsgesetz (BFSG) gilt seit dem 28. Juni 2025 verpflichtend für Websites und digitale Dienste, die an Verbraucher erbracht werden. Diese Checkliste enthält konkrete, prüfbare Anforderungen nach WCAG 2.2 AA – der technischen Grundlage des BFSG. Du kannst jeden Punkt selbst prüfen oder als Grundlage für ein professionelles Audit verwenden.

Was ist das BFSG – und was droht bei Verstoß?

Das BFSG (Barrierefreiheitsstärkungsgesetz) setzt die EU-Richtlinie 2019/882 (European Accessibility Act) in deutsches Recht um. Es schreibt vor, dass bestimmte Produkte und digitale Dienstleistungen für Menschen mit Behinderungen zugänglich sein müssen.

Bußgelder: Bis zu 100.000 Euro. Dazu kommt das Risiko von Abmahnungen durch Wettbewerber und Verbraucherschutzverbände.

Wer ist betroffen? Unternehmen, die digitale Dienstleistungen an Verbraucher (B2C) erbringen: E-Commerce-Shops, Online-Buchungsportale, Banken, Versicherungen, Streaming-Dienste und ähnliche Angebote. Kleinstunternehmen (weniger als 10 Mitarbeiter, weniger als 2 Mio. Euro Umsatz) sind von der Dienstleistungspflicht ausgenommen – nicht aber von Produktanforderungen.

Übergangsfrist: Für Bestandsverträge vor dem 28. Juni 2025 gilt eine Übergangsfrist bis zum 28. Juni 2030. Neuverträge und neue Angebote müssen sofort konform sein.

Die technische Referenz ist die EN 301 549, die für Websites auf die WCAG 2.1 verweist. WCAG 2.2 gilt als aktueller Stand der Technik und sollte angestrebt werden.

Checkliste: Wahrnehmbar

Alle Inhalte müssen für Nutzer wahrnehmbar sein, unabhängig davon, welche Sinne eingeschränkt sind.

Textalternativen für Bilder

Jedes inhaltstragende Bild hat ein alt-Attribut mit beschreibendem Text
Dekorative Bilder haben alt="" (leeres Alt-Attribut) oder sind als CSS-Hintergrundbild eingebunden
Komplexe Grafiken (Diagramme, Infografiken) haben eine ausführliche Textalternative im umliegenden Inhaltsbereich
Icon-Buttons ohne sichtbaren Text haben ein aria-label oder ein verstecktes <span> mit Text

Warum das zählt: Screen-Reader lesen Alt-Texte vor. Fehlt der Text, hört ein blinder Nutzer nur „Bild" oder den Dateinamen.

Kontrast

Textfarbe zu Hintergrundfarbe: Kontrastverhältnis mindestens 4,5:1 (normaler Text) bzw. 3:1 (großer Text ab 18pt / 14pt fett)
UI-Elemente und Grafiken: Mindestens 3:1 Kontrast gegen angrenzende Farben (WCAG 1.4.11)
Farbcodierung wird nicht als einziges Unterscheidungsmerkmal eingesetzt (z. B. Fehler nie nur durch rote Farbe signalisieren)
Hellgrauer Text auf weißem Hintergrund: Prüfen mit dem WebAIM Contrast Checker oder dem Chrome DevTools Accessibility-Panel

Praxis-Tipp: #767676 auf #ffffff entspricht exakt 4,5:1. Alles heller als dieser Grauton bei weißem Hintergrund fällt durch die WCAG-Prüfung.

Anpassbarkeit

Textgröße kann auf 200 % erhöht werden, ohne dass Inhalte abgeschnitten werden oder übereinanderlaufen
Inhalte sind nicht ausschließlich in einer Ausrichtung verfügbar (kein „Nur im Querformat")
Keine festen Pixel-Schriftgrößen (px) für Fließtext – rem oder em verwenden

Zeitbasierte Medien

Videos haben Untertitel (geschlossen oder eingebettet), die den gesprochenen Text und relevante Geräusche beschreiben
Reine Audioinhalte (Podcasts) haben ein Texttranskript
Autoplay-Videos ohne Ton sind kein Problem – Autoplay mit Ton muss pausierbar oder stumm schaltbar sein

Checkliste: Bedienbar

Die gesamte Website muss ohne Maus bedienbar sein. Das ist das häufigste Scheitern bei automatischen Audits.

Tastaturnavigation

Jede interaktive Funktion (Links, Buttons, Formulare, Menüs, Dialoge) ist per Tabulator-Taste erreichbar
Die Tab-Reihenfolge folgt dem visuellen Layout – kein Herumspringen auf der Seite
Es gibt keine Tastaturfallen: Der Fokus verlässt alle Bereiche (z. B. modale Dialoge öffnen und schließen sich korrekt per Esc)
Benutzerdefinierte Widgets (Accordions, Tabs, Dropdown-Menüs) folgen den ARIA Authoring Practices

Fokus-Indikatoren

Jedes fokussierte Element zeigt einen sichtbaren Fokus-Ring oder eine andere visuelle Hervorhebung
outline: none oder outline: 0 ohne Ersatz ist WCAG-konform verboten
Fokus-Indikatoren sind kontrastreich genug – mindestens 3:1 gegen den Hintergrund (WCAG 2.4.11, neu in 2.2)

Häufiger Fehler: Designer entfernen den Browser-Standard-Fokusring (blaue Outline) ohne Ersatz, weil er „unschön" aussieht. Das macht die Website für Tastaturnutzer unbrauchbar.

Ausreichend Zeit

Zeitlimits (z. B. Session-Timeout) können verlängert werden oder der Nutzer wird mindestens 20 Sekunden vorher gewarnt
Bewegte Inhalte, die länger als 5 Sekunden laufen, können angehalten, gestoppt oder ausgeblendet werden
Keine automatisch aktualisierende Inhalte, die nicht kontrollierbar sind

Anfälle und körperliche Reaktionen

Keine Inhalte, die mehr als drei Mal pro Sekunde blitzen (Gefahr für Menschen mit Epilepsie)

Checkliste: Verständlich

Inhalte und Bedienung müssen für Nutzer verständlich sein.

Sprache

Das lang-Attribut des <html>-Elements ist korrekt gesetzt (lang="de" für Deutsche)
Fremdsprachige Passagen im Text sind mit lang-Attribut ausgezeichnet (<span lang="en">privacy policy</span>)

Navigation ist auf allen Seiten konsistent – kein Umordnen von Menüpunkten je nach Seite
Komponenten mit gleicher Funktion haben überall denselben Namen (ein Button heißt nicht mal „Weiter" und mal „Nächster Schritt")
Keine Kontextänderung (Seitenwechsel, neues Fenster) wird ausgelöst, sobald ein Formularfeld den Fokus erhält

Formulare und Eingabehilfen

Jedes Eingabefeld hat ein sichtbares und programmatisch assoziiertes <label> (nicht nur Placeholder)
Pflichtfelder sind eindeutig markiert – nicht nur durch Farbe, sondern durch Text oder Symbol mit Erklärung
Fehlermeldungen benennen konkret, welches Feld fehlerhaft ist und wie der Fehler behoben werden kann
Bei Validierungsfehlern springt der Fokus zum ersten fehlerhaften Feld oder zur Fehlerzusammenfassung
Autofill-Attribute (autocomplete) sind korrekt gesetzt für Namen, E-Mail, Telefon, Adressen

Checkliste: Robust

Der Code muss mit aktuellen und zukünftigen assistiven Technologien kompatibel sein.

Semantisches HTML

Überschriften bilden eine logische Hierarchie: Nur eine <h1> pro Seite, darunter <h2>, <h3> ohne Ebenen zu überspringen
Landmark-Rollen sind korrekt implementiert: <header>, <nav>, <main>, <footer>, <aside>
Listen werden als <ul> oder <ol> ausgezeichnet, nicht nur visuell eingerückt
Tabellen haben <caption>, Kopfzellen als <th scope="col/row"> und keine verschachtelten Layouts-Tabellen

ARIA-Implementierung

ARIA-Rollen werden nur dort eingesetzt, wo natives HTML nicht ausreicht
aria-label und aria-labelledby sind vorhanden für Icons-Only-Buttons und Bereiche ohne sichtbare Überschrift
Dynamisch aktualisierte Inhalte (Toasts, Statusmeldungen) nutzen aria-live oder role="status" / role="alert"
Modale Dialoge implementieren Fokus-Management korrekt: Fokus geht beim Öffnen ins Modal, beim Schließen zurück zum auslösenden Element

Technische Validität

Kein doppeltes Vorkommen von id-Attributen auf einer Seite
Start- und End-Tags von HTML-Elementen sind korrekt geschlossen
Keine deprecated HTML-Elemente (<font>, <center>, <marquee>)

Sonderfall: Barrierefreiheit im Online-Shop

E-Commerce-Shops haben spezifische Barrieren, die über die allgemeine Checkliste hinausgehen.

Produktseiten

Produktbilder haben Alt-Texte, die das Produkt beschreiben (nicht nur „Produktbild 1")
Galeriebilder mit mehreren Ansichten haben unterschiedliche, aussagekräftige Alt-Texte
Produktvarianten (Größe, Farbe) sind nicht nur visuell unterscheidbar, sondern haben beschreibende Labels
„In den Warenkorb"-Button ist eindeutig beschriftet (nicht nur ein Icon ohne Text)

Filter und Suche

Filteroptionen sind per Tastatur bedienbar und haben verständliche Labels
Suchergebnisse werden per aria-live angekündigt, wenn sie sich dynamisch aktualisieren
Aktive Filter sind sichtbar markiert und können einzeln entfernt werden – auch per Tastatur

Checkout-Prozess

Alle Formularfelder im Checkout haben Labels und korrekte autocomplete-Attribute
Fehlermeldungen sind spezifisch: „Die Postleitzahl muss 5 Ziffern haben" statt „Fehler"
Der Bestellabschluss-Button ist eindeutig beschriftet und zeigt den nächsten Schritt an
Der gesamte Checkout ist per Tastatur abschließbar – von Adresseingabe bis Zahlungsbestätigung
Zahlungsformulare externer Anbieter (Stripe, PayPal) sind zwar nicht in deiner Kontrolle, aber du solltest barrierefreie Alternativen anbieten

Beispiele barrierefreier Websites: Woran man sie erkennt

Statt fremde Marken zu bewerten, beschreiben wir die technischen Merkmale, die barrierefreie Websites auszeichnen:

Klare Fokus-Indikatoren: Wenn du die Tab-Taste drückst, siehst du immer genau, welches Element gerade fokussiert ist. Der Fokus-Ring ist kontrastreich und bewegt sich logisch durch den Inhalt.

Beschreibende Link-Texte: Links heißen nicht „Hier klicken" oder „Mehr", sondern beschreiben das Ziel: „BFSG-Checkliste als PDF herunterladen" oder „Zur Barrierefreiheits-Servicepage von HEADON".

Sichtbare Skip-Links: Ein „Zum Hauptinhalt springen"-Link erscheint beim ersten Tab-Druck und erlaubt Tastaturnutzern, die Navigation zu überspringen.

Korrekte Fehlermeldungen in Formularen: Fehlermeldungen stehen neben dem betroffenen Feld, benennen den Fehler konkret und sind auch für Screen-Reader zugänglich (nicht nur als CSS-Styling).

Konsistente Navigation: Das Hauptmenü ist auf jeder Seite an derselben Stelle, hat dieselbe Reihenfolge und dieselben Beschriftungen.

Barrierefreiheitserklärung: Pflichtdokument nach BFSG

Neben der technischen Konformität schreibt das BFSG eine öffentlich zugängliche Barrierefreiheitserklärung vor. Sie muss folgende Informationen enthalten:

Den aktuellen Konformitätsstatus (vollständig konform, teilweise konform, nicht konform)
Eine Beschreibung bekannter Einschränkungen mit Begründung
Einen Kontaktweg für Nutzerbeschwerden zum Barrierefreiheits-Status
Bei öffentlichen Stellen: einen Link zum Schlichtungsverfahren

Die Erklärung muss auf der Website leicht auffindbar sein – typischerweise im Footer. Wir erstellen die Barrierefreiheitserklärung als festen Bestandteil unserer BFSG-Leistungen.

Nächste Schritte: Wie du jetzt anfängst

Schnelltest selbst durchführen: Öffne deine Website und drücke mehrfach die Tab-Taste. Kannst du jeden Link und Button erreichen? Siehst du immer, wo der Fokus ist? Das allein zeigt dir, ob es grundlegende Barrieren gibt.

Automatischen Scan nutzen: Tools wie axe DevTools (Browser-Extension), Google Lighthouse oder WAVE geben einen ersten Überblick. Sie finden automatisch erkennbare Fehler – aber nur etwa 30–40 % aller WCAG-Probleme lassen sich automatisch erkennen. Der Rest erfordert manuelles Testen.

Professionelles Audit beauftragen: Für rechtssichere BFSG-Konformität ist ein strukturiertes Audit nach WCAG 2.2 AA durch Fachleute erforderlich. Mit dem Barrierefreiheits-Schnellcheck kannst du eine erste kostenlose Analyse deiner Website starten.

Overlay-Tools meiden: Automatische Overlay-Lösungen lösen die zugrundeliegenden Probleme nicht. Screen-Reader-Nutzer berichten von aktiven Beeinträchtigungen durch solche Tools. Echte Barrierefreiheit entsteht im Quellcode.

Für eine vollständige Umsetzung inkl. Audit, Remediation und Barrierefreiheitserklärung: BFSG-Service von HEADON – Festpreisangebot nach Erstgespräch.

Letzte Aktualisierung: Juni 2026. Die WCAG 2.2 wurde im Oktober 2023 veröffentlicht und ist der aktuelle Stand der Technik. EN 301 549 v3.2.1 (2021) referenziert WCAG 2.1, WCAG 2.2 wird als vollständig kompatibel betrachtet.