BFSG Checkliste für Onlineshops: 20 Punkte für einen barrierefreien Checkout

Seit dem 28. Juni 2025 ist Barrierefreiheit im digitalen Handel keine freiwillige Kür mehr. Das Barrierefreiheitsstärkungsgesetz (BFSG), die deutsche Umsetzung des European Accessibility Act, verpflichtet alle relevanten Onlineshops, ihre Dienste nach WCAG 2.1 Level AA zugänglich zu machen. Wer bis dahin nichts unternommen hat, ist bereits im Verzug - und die ersten Abmahnungen wurden Ende 2025 beobachtet.

Diese Checkliste fokussiert auf den Checkout-Prozess, weil er der kritischste Punkt ist: Eine Barriere hier verhindert direkt den Vertragsabschluss. Die 20 Prüfpunkte sind konkret und testbar - kein theoretisches WCAG-Kauderwelsch, sondern das, was ich nach über 50 umgebauten Shops als tatsächliche Stolperstellen kenne. Ich bin Webentwickler, kein Rechtsanwalt - für rechtliche Fragen im Einzelfall wenden Sie sich bitte an einen auf IT-Recht spezialisierten Anwalt.

Was das BFSG für Onlineshops bedeutet

Das BFSG setzt die EU-Richtlinie 2019/882 (European Accessibility Act) in deutsches Recht um. Technische Messlatte ist der europäische Standard EN 301 549, der WCAG 2.1 Level AA vollständig integriert. In der Praxis heißt das: Wer WCAG 2.1 AA einhält, gilt als konform. EN 301 549 wird derzeit auf WCAG 2.2 aktualisiert, die neue Version wird voraussichtlich im Oktober 2026 im EU-Amtsblatt erscheinen - bis dahin bleibt WCAG 2.1 AA die verbindliche Grundlage.

Von der Pflicht ausgenommen sind Kleinstunternehmen mit weniger als 10 Mitarbeitern UND maximal 2 Millionen EUR Jahresumsatz. Beide Kriterien müssen gleichzeitig erfüllt sein. Wer 9 Mitarbeiter hat, aber 3 Millionen EUR umsetzt, fällt unter das Gesetz. Wer Produkte im Sinne von § 1 Abs. 2 BFSG verkauft (z. B. Computer, Tablets, Smartphones), muss diese Produkte unabhängig von seiner Unternehmensgröße barrierefrei gestalten.

Bei einem Kunden aus dem Großraum Hamburg - ein Modegeschäft mit 14 Mitarbeitern und einem WooCommerce-Shop - stellten wir beim Audit fest, dass der gesamte Checkout-Flow ausschließlich mit der Maus bedienbar war. Kein sichtbarer Fokusrahmen, keine Fehlermeldungen für Screenreader, Pflichtfelder ohne programmatisches Label. Das war kein Randproblem, sondern komplette Nicht-Konformität in allen vier WCAG-Hauptprinzipien.

Was der BFSG-Checkout erfüllen muss - und warum

Der Checkout besteht aus mehreren dynamischen Schritten: Warenkorb, Adresseingabe, Versandwahl, Zahlungsmethode, Zusammenfassung und Bestellbestätigung. Jeder dieser Schritte enthält Komponenten, die für Menschen mit Seh-, Motorik- oder kognitiven Einschränkungen zur Barriere werden können - Formulare, Dropdowns, Modals, Ladeindikatoren und Statusmeldungen. Die gute Nachricht: Wer diese Komponenten sauber baut, verbessert gleichzeitig die Usability für alle Nutzer und senkt die Abbruchquote.

Nach den vier WCAG-Prinzipien muss der Checkout wahrnehmbar (1), bedienbar (2), verständlich (3) und robust (4) sein. Im Folgenden finden Sie 20 konkrete Prüfpunkte, gegliedert nach diesen Kategorien.

Wahrnehmbarkeit: Kontrast, Texte und visuelle Darstellung

Punkt 1: Kontrastverhältnis Text
Normaler Text muss ein Kontrastverhältnis von mindestens 4,5:1 zum Hintergrund haben. Für große Schrift (ab 18 pt bei normaler Schriftstärke oder ab 14 pt bei Fettschrift) genügen 3:1. Prüfen Sie alle Textelemente im Checkout: Feldlabels, Hilfe-Texte, Fehler-Meldungen, Button-Beschriftungen und Preise. Häufige Falle: hellgrauer Platzhaltertext in Eingabefeldern, der oft unter 2:1 liegt.

Punkt 2: Kontrastverhältnis UI-Elemente
Fokusstile, Checkboxen, Radio-Buttons, Divider und aktive Zustände brauchen mindestens 3:1 Kontrast zur Nachbarfarbe (WCAG 1.4.11). Prüfen Sie den Zustand von aktivierten Checkboxen ("AGB akzeptiert") und nicht-ausgewählten Radio-Buttons. Viele Themes setzen hier nur Farbe als Indikator - das reicht nicht.

Punkt 3: Keine reine Farbkodierung
Pflichtfelder, Fehler und Erfolgsstatus dürfen nicht ausschließlich durch Farbe signalisiert werden (WCAG 1.4.1). Ein rotes Feld als einziger Fehlerhinweis ist nicht ausreichend. Ergänzen Sie Farbe immer mit einem Icon, einem Text oder einem Muster.

Punkt 4: Alt-Texte für funktionale Bilder
Wenn Sie im Checkout Logos von Zahlungsanbietern (Visa, PayPal, Klarna) als Bilder einbinden, brauchen diese einen aussagekräftigen Alt-Text. Dekorative Bilder erhalten alt="". Bei einem Kunden, dessen Checkout-Seite vier Zahlungs-Icons ohne Alt-Text hatte, las der Screenreader stattdessen den Dateinamen vor - "visa_logo_2024_v3.png".

Punkt 5: Textalternativen für Captchas und Sicherheitsabfragen
Falls Sie ein Captcha im Checkout oder bei der Kontoregistrierung einsetzen, muss es eine Audio-Alternative geben. Image-only-Captchas sind nach WCAG 1.1.1 ein Ausschlussmerkmal für blinde Nutzer. Besser: Honeypot-Felder, serverseitige Rate-Limiting oder hCaptcha mit Audio-Fallback.

Bedienbarkeit: Tastatur, Fokus und Zeit

Bedienbarkeit ist der Bereich, in dem die meisten Checkout-Probleme stecken. Jede Schaltfläche, jedes Formularfeld, jeder Dialog muss mit der Tastatur erreichbar und steuerbar sein - in einer logischen Reihenfolge, ohne Fokusverlust.

Punkt 6: Vollständige Tastaturbedienbarkeit
Navigieren Sie den gesamten Checkout ausschließlich mit Tab, Shift+Tab, Pfeiltasten, Enter und Leertaste. Können Sie den "In den Warenkorb"-Button, alle Adressfelder, die Versandauswahl, die Zahlungsmethoden und den "Jetzt kaufen"-Button erreichen? Wenn irgendwo der Fokus "verschwindet" (in einem Modal oder nach einem dynamischen Update), ist das ein kritischer Fehler.

Punkt 7: Sichtbarer Fokusindikator
Jedes fokussierte Element muss einen klar sichtbaren Fokusring haben (WCAG 2.4.7, mit WCAG 2.2 verschärft durch 2.4.11). Der Standard-Fokusstil des Browsers ist oft ausreichend - das Problem entsteht, wenn Themes ihn mit outline: none oder outline: 0 deaktivieren. Prüfen Sie alle interaktiven Elemente: Buttons, Links, Inputs, Checkboxen, Selects und benutzerdefinierte Komponenten wie Tab-Panels.

Punkt 8: Kein Fokus-Trap außerhalb von Modals
Wenn ein Modal oder ein Overlay geöffnet wird (z. B. ein "Adresse bestätigen"-Dialog), muss der Fokus darin eingesperrt bleiben - und nach dem Schließen wieder an die auslösende Stelle zurückspringen. Außerhalb von Modals darf kein Fokus-Trap existieren: Ein Nutzer muss alle Elemente verlassen können, ohne die Maus zu nutzen.

Punkt 9: Keine zeitabhängigen Sitzungen ohne Warnung
Wenn Ihre Session nach 15 Minuten Inaktivität abläuft und den Warenkorb leert, muss der Nutzer mindestens 20 Sekunden vor Ablauf gewarnt werden und die Möglichkeit haben, die Sitzung zu verlängern (WCAG 2.2.1). Ein hartcodierter Timeout ohne Warnung ist eine häufige Barriere in älteren WooCommerce-Checkout-Implementierungen.

Punkt 10: Keine automatisch startenden Medien
Autoplay-Videos oder -Audio im Checkout sind nach WCAG 1.4.2 verboten, wenn sie länger als 3 Sekunden laufen und nicht sofort gestoppt werden können. Das betrifft auch Hintergrundanimationen, die vestibulären Störungen auslösen können (WCAG 2.3.3 für Level AAA, aber ein gutes Argument für Zurückhaltung).

Verständlichkeit: Labels, Fehler und Sprache

Punkt 11: Programmatische Labels für alle Formularfelder
Jedes Eingabefeld braucht ein <label>-Element, das über das for-Attribut mit der id des Feldes verknüpft ist - oder ein aria-label / aria-labelledby. Placeholder-Text zählt nicht als Label: Er verschwindet beim Tippen und ist für viele Screenreader-Konfigurationen unzuverlässig. Prüfen Sie: Klickt man auf den Label-Text, springt der Fokus ins richtige Feld?

Punkt 12: Klare Fehlermeldungen mit Bezug zum Feld
Fehler-Meldungen müssen beschreibend sein, das betroffene Feld benennen und einen Lösungshinweis geben. "Fehler" als Meldung reicht nicht. Besser: "Bitte geben Sie eine gültige deutsche Postleitzahl (5 Ziffern) ein." Die Meldung muss programmatisch mit dem Feld verknüpft sein, z. B. über aria-describedby oder durch Platzierung direkt vor/nach dem Feld im DOM.

Punkt 13: Fehler-Identifikation und Vorschläge
Wenn ein Formular validiert und Fehler findet, müssen alle fehlerhaften Felder identifiziert und beschrieben werden (WCAG 3.3.1 und 3.3.3). Für vorhersehbare Eingaben (Datum, E-Mail-Format, IBAN) muss ein Format-Hinweis sichtbar sein, bevor der Nutzer das Feld verlässt.

Punkt 14: Seitensprache im HTML definiert
Das <html>-Element braucht ein korrektes lang-Attribut (lang="de" für deutschsprachige Shops). Screenreader wählen darauf basierend die Sprachsynthese. Mischsprachliche Passagen (z. B. ein englischsprachiger Trust-Badge-Text) sollten mit lang-Attribut im entsprechenden Element ausgezeichnet werden.

Punkt 15: Konsistente Navigation und Beschriftungen
Wenn der "Zurück zur Übersicht"-Button auf Seite 2 des Checkouts anders beschriftet ist als auf Seite 3, verwirrt das alle Nutzer - besonders Menschen mit kognitiven Einschränkungen. Labels, Buttons und Navigationselemente müssen im gesamten Checkout konsistent beschriftet sein.

Robustheit: Semantisches HTML und ARIA

Punkt 16: Valides, semantisches HTML
Screenreader und andere assistive Technologien interpretieren die Bedeutung von HTML-Elementen. Ein <button> ist ein Button - ein <div onClick> ist keiner. Prüfen Sie: Werden Buttons als <button> implementiert? Haben Überschriften eine logische Hierarchie (h1 > h2 > h3)? Sind Listen als <ul> / <ol> ausgezeichnet? Fehler hier sind oft tief im Theme oder in einem Checkout-Plugin vergraben.

Punkt 17: Korrekte ARIA-Attribute
ARIA-Attribute können fehlende Semantik ergänzen - aber falsch eingesetzt, machen sie es schlimmer. Verbreitete Fehler: role="button" auf einem <a>-Tag ohne href, aria-hidden="true" auf einem sichtbaren und interaktiven Element, oder aria-required ohne visuell sichtbares Pflichtfeld-Kennzeichen. Regel: Lieber kein ARIA als falsches ARIA.

Punkt 18: ARIA-Live-Regionen für dynamische Updates
WooCommerce-Checkout-Blöcke aktualisieren Preissummen, Versandoptionen und Fehlermeldungen dynamisch via JavaScript. Ohne ARIA-Live-Regionen bemerken Screenreader-Nutzer diese Änderungen nicht. Für wichtige Status-Updates ("Artikel wurde dem Warenkorb hinzugefügt", "Bestellung aufgegeben") verwenden Sie aria-live="polite". Für kritische Fehler darf es aria-live="assertive" sein - aber sparsam, da es laufende Ansagen unterbricht.

Punkt 19: Kompatibilität mit assistiven Technologien
Testen Sie Ihren Checkout mindestens mit NVDA (kostenlos, Windows) und dem Chrome-Browser. NVDA ist der am weitesten verbreitete Screenreader unter Windows-Nutzern in Deutschland. Zusätzlich lohnt sich ein Test mit VoiceOver auf iOS, da viele blinde und sehbehinderte Nutzer das Smartphone fürs Online-Shopping nutzen.

Die Barrierefreiheitserklärung: Pflicht nach BFSG § 13

Punkt 20: Barrierefreiheitserklärung mit Feedback-Mechanismus
Die Barrierefreiheitserklärung ist keine Kür, sondern Pflicht nach BFSG § 13. Sie muss den aktuellen Stand der Konformität dokumentieren (vollständig / teilweise / nicht konform), bekannte Einschränkungen benennen und einen Feedback-Kanal anbieten, über den Nutzer Barrieren melden können. Die Bundesfachstelle Barrierefreiheit empfiehlt einen Link "Barrierefreiheit" im Header oder Footer, der auf eine eigene Unterseite führt. Ein einfacher E-Mail-Link als Feedback-Mechanismus ist ausreichend.

Die Erklärung muss selbst barrierefrei sein - also in barrierefreiem HTML, mit ausreichendem Kontrast und ohne PDF-only-Lösung.

Wie Sie die 20 Punkte systematisch abarbeiten

Starten Sie mit dem automatischen Scan: Installieren Sie die WAVE Browser-Extension und öffnen Sie Ihren Checkout. WAVE markiert fehlende Alt-Texte, fehlende Labels und einige Kontrast-Probleme sofort visuell direkt auf der Seite. Ergänzen Sie das mit einem Lighthouse-Audit (F12 in Chrome, Reiter "Lighthouse", Modus "Accessibility"). Lighthouse nutzt die axe-core-Engine und gibt Ihnen einen Score sowie eine Liste der automatisch erkannten Probleme.

Danach kommt der manuelle Test, den kein Tool ersetzen kann: Öffnen Sie Ihren Shop, schließen Sie die Maus weg (oder ziehen Sie das USB-Kabel) und navigieren Sie den gesamten Checkout mit der Tastatur. Können Sie jeden Schritt abschließen? Sehen Sie immer, wo der Fokus ist? Das dauert 15-20 Minuten und liefert mehr Erkenntnisse als jedes automatische Tool.

Bei einem Kunden aus Köln - ein B2C-Elektronikhändler mit Shopware 6 - fanden wir beim manuellen Test, dass der Fokus beim Wechsel zwischen Zahlungsoptionen jedesmal auf den Seitenanfang sprang. Das automatische Tool hatte es nicht gemeldet. Die Ursache war ein window.scrollTo(0,0) in einem alten jQuery-Snippet. Behebung: zwei Zeilen Code entfernen.

Bei komplexeren Checkouts - mehrstufige Formulare, Ajax-Updates, externe Payment-Provider - empfehle ich einen kurzen Test mit NVDA. Laden Sie NVDA kostenlos von nvaccess.org, starten Sie es und navigieren Sie den Checkout. Sie werden in 10 Minuten mehr Probleme finden als in stundenlangen Code-Reviews.

Was die meisten BFSG-Guides falsch machen

Viele Ratgeber zur BFSG Checkliste für Onlineshops behandeln Barrierefreiheit als reine Compliance-Aufgabe: Punkte abhaken, Erklärung hochladen, fertig. Das greift zu kurz. Barrierefreiheit ist ein laufender Prozess, weil Ihr Shop sich verändert: neue Plugins, neue Zahlungsanbieter, neue Landing Pages, Theme-Updates. Jede Änderung kann neue Barrieren einführen.

Ein zweiter verbreiteter Fehler: Das Verlassen auf automatische Tools allein. Die 30-40 % der Probleme, die automatische Scanner erkennen, sind oft die einfachen Fälle - fehlende Alt-Texte, unzureichender Kontrast. Die schwerwiegenden Barrieren - Fokus-Traps, nicht angekündigte dynamische Updates, unzugängliche Custom-Dropdown-Menüs bei der Zahlungswahl - finden sich nur im manuellen Test.

Ein drittes Missverständnis betrifft die Ausnahmeregel: Kleinstunternehmen denken, sie seien generell frei vom BFSG. Aber die Grenze liegt bei unter 10 Mitarbeitern UND unter 2 Millionen EUR Jahresumsatz. Viele wachsende Shops überschreiten eine der beiden Schwellen, ohne es aktiv zu prüfen.

Mehr zu den übergreifenden rechtlichen Pflichten für Onlineshops in 2026 - von E-Rechnung bis Widerrufsrecht - finden Sie im Artikel zu den rechtlichen Pflichten für Websites und Shops 2026. Einen ausführlichen Blick auf barrierefreie und rechtssichere WooCommerce-Shops finden Sie in unserem WooCommerce-Bereich.

Kosten und Aufwand realistisch einschätzen

Was kostet die BFSG-Umsetzung für einen WooCommerce-Shop? Die ehrliche Antwort: Es kommt auf den Ausgangszustand an. Bei einem Shop mit einem modernen Theme (Blocksy, GeneratePress, Astra) und wenigen Plugins liegt der Aufwand bei 20-40 Stunden für einen erfahrenen Entwickler. Bei einem gewachsenen Shop mit Custom-Theme, vielen Drittanbieter-Plugins und einem komplexen Checkout können es auch 80-120 Stunden sein.

Die Alternative - nichts tun und auf eine Abmahnung warten - ist teurer. Erste Abmahnungen durch Wettbewerber und Verbraucherschutzverbände wurden Ende 2025 beobachtet. Die Kosten einer solchen Abmahnung (Anwaltsgebühren, eventuelle Vertragsstrafen) übersteigen in der Regel den Aufwand für eine ordentliche Umsetzung.

Ein BFSG-Audit für Ihren Shop - mit Priorisierung der Probleme nach Schweregrad und Reparaturaufwand - ist ein guter erster Schritt. So wissen Sie genau, wo Sie stehen, bevor Sie Budget freigeben. Wenn Sie unsicher sind, welche Anforderungen für Ihren Shop gelten oder wie Sie die Umsetzung angehen sollen, können Sie sich gerne über unsere Kontaktseite melden.

Weitere Informationen zu rechtssicheren AGB und Impressum für Onlineshops finden Sie in den Artikeln zu AGB für Onlineshops und zum Widerrufsrecht bei digitalen Produkten.

Häufige Fragen

Ab wann gilt das BFSG für meinen Onlineshop?

Das BFSG ist am 28. Juni 2025 in Kraft getreten. Ab diesem Stichtag müssen alle betroffenen Onlineshops die Anforderungen erfüllen. Eine Übergangsfrist gibt es nicht - wer bis dahin nichts unternommen hat, ist bereits im Verzug und kann von der Marktüberwachungsbehörde oder per Abmahnung in die Pflicht genommen werden.

Wer ist vom BFSG ausgenommen?

Kleinstunternehmen mit weniger als 10 Mitarbeitern UND einem Jahresumsatz von maximal 2 Millionen EUR sind von den Dienstleistungspflichten des BFSG ausgenommen. Wichtig: Beide Bedingungen müssen gleichzeitig erfüllt sein. Wer Produkte im Sinne von § 1 Abs. 2 BFSG vermarktet (z. B. Hardware, Computer), fällt unabhängig von der Größe unter das Gesetz.

Welcher technische Standard liegt dem BFSG zugrunde?

Das BFSG verweist auf den europäischen Harmonisierungsstandard EN 301 549, der seinerseits WCAG 2.1 Level AA vollständig integriert. Wer WCAG 2.1 AA einhält, gilt in der Praxis als konform. EN 301 549 wird derzeit auf WCAG 2.2 aktualisiert, die neue Version wird voraussichtlich im Oktober 2026 im EU-Amtsblatt erscheinen.

Was droht bei Verstößen gegen das BFSG?

Die Marktüberwachungsbehörden können Bußgelder bis zu 100.000 EUR verhängen, wenn ein Unternehmen nach einer Aufforderung zur Nachbesserung weiterhin gegen das BFSG verstößt. Daneben sind Abmahnungen durch Mitbewerber und Verbraucherschutzverbände möglich. Erste Abmahnwellen wurden ab Ende 2025 beobachtet.

Reicht ein Barrierefreiheit-Plugin für WordPress oder WooCommerce?

Nein - ein Plugin allein macht einen Shop nicht konform. Plugins können Teilbereiche verbessern (z. B. Fokusstile, Schriftgrößen), aber Probleme in Theme-Code, Checkout-Blöcken oder Drittanbieter-Plugins müssen separat behoben werden. WCAG-Konformität entsteht durch sauberes semantisches HTML, korrekte ARIA-Attribute und manuelle Tests - nicht durch einen einzigen Schalter.

Was ist eine Barrierefreiheitserklärung und wohin gehört sie?

Die Barrierefreiheitserklärung ist nach BFSG § 13 für jeden betroffenen Shop Pflicht. Sie muss den Stand der Konformität, bekannte Einschränkungen und einen Feedback-Kanal (z. B. E-Mail-Adresse) enthalten. Die Bundesfachstelle Barrierefreiheit empfiehlt einen gut sichtbaren Link 'Barrierefreiheit' im Header oder Footer, der auf eine eigene Seite mit den Pflichtinformationen zeigt.

Wie teste ich meinen Onlineshop auf Barrierefreiheit?

Starten Sie mit kostenlosen Browser-Extensions: WAVE (Chrome/Firefox/Edge) markiert Fehler direkt auf der Seite, axe DevTools läuft im Chrome-Devtools-Panel, Google Lighthouse liefert einen Accessibility-Score. Diese Tools prüfen aber nur 30-40 % der WCAG-Kriterien automatisch. Ergänzen Sie den Test unbedingt mit manueller Tastaturnavigation (Tab, Shift+Tab, Enter, Leertaste) und einem Screenreader-Test (NVDA kostenlos unter Windows, VoiceOver auf Mac/iOS).

Muss der gesamte Shop barrierefrei sein oder nur der Checkout?

Das BFSG fordert Barrierefreiheit für den gesamten Dienst - also alle Seiten, die zum Kauf führen: Startseite, Kategorien, Produktseiten, Warenkorb, Checkout und Bestellbestätigung. Der Checkout ist besonders kritisch, weil hier eine Barriere direkt den Abschluss eines Vertrags verhindert. In der Praxis beginnen viele Shops aber sinnvollerweise mit dem Checkout und arbeiten sich zur Startseite vor.