BFSG-Checkliste 2026: barrierefreie Website

Das Barrierefreiheitsstärkungsgesetz (BFSG) gilt seit dem 28. Juni 2025 für bestimmte Dienstleistungen, u. a. Dienstleistungen im elektronischen Geschäftsverkehr, die auf einen Vertragsschluss mit Verbrauchern gerichtet sind (§ 1 Abs. 3 BFSG). Diese Checkliste enthält konkrete, prüfbare Anforderungen nach WCAG 2.2 AA. Sie können jeden Punkt selbst prüfen oder als Grundlage für ein Audit verwenden.

Was ist das BFSG – und was gilt bei Verstößen?

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 100.000 € für bestimmte Verstöße, etwa das Anbieten nicht konformer Dienstleistungen, sonst bis 10.000 € (§ 37 Abs. 1 Nr. 8, Abs. 2 BFSG).

Marktüberwachung: Zuständig ist die Marktüberwachungsstelle der Länder für die Barrierefreiheit von Produkten und Dienstleistungen (MLBF). Sie kann eine Frist zur Nachbesserung setzen und danach die Einschränkung oder Einstellung der Dienstleistung anordnen (§ 29 BFSG).

Wer ist betroffen? Unternehmen, deren Dienstleistungen unter § 1 Abs. 3 BFSG fallen – im Web typischerweise Online-Shops und Buchungsangebote, bei denen Verbraucher einen Vertrag abschließen. Kleinstunternehmen (weniger als 10 Beschäftigte und Jahresumsatz oder Jahresbilanzsumme höchstens 2 Mio. €, § 2 Nr. 17 BFSG) sind von der Dienstleistungspflicht ausgenommen – nicht aber von Produktanforderungen.

Übergang: Verträge, die vor dem 28.06.2025 geschlossen wurden, dürfen bis längstens 27.06.2030 unverändert fortbestehen. Für die Website selbst gibt es keine Übergangsfrist (§ 38 Abs. 1 BFSG).

Technischer Maßstab: Das BFSG nennt keine bestimmte Norm, sondern verweist auf harmonisierte Normen, die im Amtsblatt der EU veröffentlicht sind (§ 4 BFSG). Dort gilt derzeit EN 301 549 V3.2.1, die auf WCAG 2.1 AA verweist. Die neue Fassung V4.1.1 (September 2026) verlangt WCAG 2.2, steht aber noch nicht im Amtsblatt (AccessibleEU, Meldung vom 07.09.2026). Unsere Empfehlung: gleich auf WCAG 2.2 AA bauen – danach richtet sich diese Checkliste.

---

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 ergibt 4,54:1 und liegt damit knapp über der Grenze. Hellere Grautöne auf Weiß erreichen die 4,5:1 für normalen Text nicht mehr.

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")
• Empfehlung (kein eigenes WCAG-Kriterium): Schriftgrößen für Fließtext in rem oder em statt px angeben – das erleichtert das Vergrößern

Zeitbasierte Medien

• Videos haben Untertitel (geschlossen oder eingebettet), die den gesprochenen Text und relevante Geräusche beschreiben
• Reine Audioinhalte (Podcasts) haben ein Texttranskript
• Audio, das automatisch startet und länger als 3 Sekunden läuft, lässt sich anhalten oder unabhängig von der Systemlautstärke regeln (1.4.2)
• Autoplay-Videos zählen auch ohne Ton als bewegter Inhalt: Sie müssen sich pausieren, stoppen oder ausblenden lassen (2.2.2, siehe „Ausreichend Zeit“)

---

Checkliste: Bedienbar

Die gesamte Website muss ohne Maus bedienbar sein.

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 verstößt gegen 2.4.7, wenn kein sichtbarer Fokus bleibt
• Fokus-Indikatoren heben sich deutlich ab: Für AA gelten 2.4.7 (Fokus sichtbar) und 1.4.11 (Nicht-Text-Kontrast); ein fester 3:1-Fokuskontrast steht erst in 2.4.13 (AAA)
• Das fokussierte Element wird nicht von Sticky-Headern oder Cookie-Bannern verdeckt (2.4.11 Fokus nicht verdeckt, 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 automatisch starten und länger als 5 Sekunden laufen (auch Autoplay-Videos ohne Ton), können angehalten, gestoppt oder ausgeblendet werden (2.2.2)
• 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 deutschsprachige Seiten)
• Fremdsprachige Passagen im Text sind mit lang-Attribut ausgezeichnet (<span lang="en">privacy policy</span>)

Vorhersehbare Navigation

• 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
• Empfehlung: 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: <h2>, <h3> ohne Ebenen zu überspringen; Empfehlung: nur eine <h1> pro Seite
• Landmark-Rollen sind korrekt implementiert: <header>, <nav>, <main>, <footer>, <aside>
• Listen werden als <ul> oder <ol> ausgezeichnet, nicht nur visuell eingerückt
• Tabellen haben Kopfzellen als <th scope="col/row"> und keine verschachtelten Layout-Tabellen; Empfehlung: <caption> als Tabellentitel

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 Sauberkeit (Empfehlung)

Das frühere Kriterium 4.1.1 (Parsing) ist in WCAG 2.2 entfallen. Sauberes HTML bleibt trotzdem sinnvoll, weil Hilfstechnologien darauf aufbauen.

• 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
• Eingebundene Dienste wie Zahlungsanbieter (Stripe, PayPal) mitprüfen: Verantwortlich für die gesamte Dienstleistung ist ihr Anbieter

---

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 Sie die Tab-Taste drücken, sehen Sie 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: „Barrierefreiheitserklärung ansehen" oder „Zur Barrierefreiheit bei 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: Pflichtangaben nach BFSG

Neben der technischen Umsetzung verlangt das BFSG Informationen dazu, wie die Dienstleistung die Anforderungen erfüllt. Nach Anlage 3 BFSG gehören dazu:

• eine Beschreibung der Dienstleistung in barrierefreiem Format
• Erläuterungen, wie die Dienstleistung die Barrierefreiheitsanforderungen erfüllt
• die Angabe der zuständigen Marktüberwachungsbehörde

Das verbreitete Muster mit Konformitätsstatus (vollständig, teilweise, nicht konform), bekannten Einschränkungen, Kontaktweg und Link zum Schlichtungsverfahren stammt aus den Vorgaben für öffentliche Stellen (BITV 2.0). Für Unternehmen nach BFSG maßgeblich sind die Inhalte nach Anlage 3.

Veröffentlichen Sie die Angaben gut auffindbar, etwa verlinkt im Footer. Wir erstellen die Barrierefreiheitserklärung als festen Bestandteil unserer BFSG-Leistungen.

---

Häufige Irrtümer

„Unsere Website ist responsiv, also barrierefrei.“ Responsiv heißt nur, dass die Seite auf verschiedenen Bildschirmgrößen funktioniert. Barrierefreiheit verlangt zusätzlich Tastaturbedienung, Kontraste, Screenreader-Unterstützung und mehr.

„Wir haben ein Accessibility-Overlay installiert.“ Overlay-Tools beheben die Ursachen im Code nicht und stören Screenreader-Nutzer teils aktiv. Echte Barrierefreiheit entsteht im Quelltext.

„Wir sind B2B, das betrifft uns nicht.“ Prüfen Sie genau: Sobald Verbraucher über Ihre Website einen Vertrag abschließen können, kann das BFSG greifen.

---

Nächste Schritte: So prüfen Sie Ihre Website

Schnelltest selbst durchführen: Öffnen Sie Ihre Website und drücken Sie mehrfach die Tab-Taste. Erreichen Sie jeden Link und Button? Sehen Sie immer, wo der Fokus ist? Das allein zeigt Ihnen, ob es grundlegende Barrieren gibt.

Automatischen Scan nutzen: Tools wie axe DevTools (Browser-Extension), Google Lighthouse oder WAVE geben einen ersten Überblick, ebenso unser kostenloser Barrierefreiheits-Check. Automatisch erkennen lässt sich aber nur ein Teil der WCAG-Probleme.

Manuell prüfen: Für eine belastbare Einschätzung empfiehlt sich eine manuelle Prüfung nach WCAG 2.2 AA mit dokumentierten Befunden: Tastaturbedienung, Fokusreihenfolge, Screenreader (NVDA, VoiceOver) und verständliche Fehlermeldungen. Das leistet kein Werkzeug.

---

Letzte Aktualisierung: September 2026. Rechtsangaben an den Wortlaut des BFSG angeglichen, Normstand nach AccessibleEU (Meldung vom 07.09.2026); Inhalte des früheren Beitrags zu WCAG und BFSG hier zusammengeführt.