Am 28. Juni 2025 trat das Barrierefreiheitsstärkungsgesetz (BFSG) in Kraft — die deutsche Umsetzung der EU-Richtlinie 2019/882 (European Accessibility Act). Ein Jahr später ist die Lage im Feld deutlich: Die Mehrheit der PrestaShop-Shops, die in Deutschland Verbraucher beliefern, ist weiterhin nicht konform — und die meisten Händler wissen es noch nicht.
Das Thema ist nicht mehr nur ethischer Natur. Es ist inzwischen ein juristisches Risiko, ein kommerzielles (Verlust öffentlicher Ausschreibungen, sensibler B2B-Rahmenverträge) und ein Reputationsrisiko. Dieser Artikel ordnet den tatsächlichen Rechtsrahmen in 2026 ein, beleuchtet die seit 2025 verhängten Sanktionen und liefert den technischen Fahrplan, um einen PrestaShop 8- oder 9-Shop konform zu machen — ohne das Theme neu zu bauen.
Der Rechtsrahmen für einen PrestaShop-Shop in Deutschland 2026
Das BFSG setzt die EAA in deutsches Recht um, ergänzt durch die Barrierefreiheitsstärkungsgesetz-Verordnung (BFSGV), die die technischen Anforderungen präzisiert. Der Anwendungsbereich ist weit gefasst: Jeder E-Commerce-Dienst, der sich an Verbraucher in der EU richtet, ist betroffen — Website, Mobile App, Bestellprozess, After-Sales-Kommunikation.
Zwei strukturelle Ausnahmen:
- Kleinstunternehmen im europäischen Sinne (weniger als 10 Mitarbeitende UND Umsatz oder Bilanzsumme unter 2 Mio. €) sind für ihre Dienstleistungen befreit. Achtung: Die Schwelle wird auf Konzernebene bewertet.
- Nicht kontrollierte Drittinhalte (etwa rohe Nutzerkommentare) liegen außerhalb des Anwendungsbereichs, aber der Händler bleibt verantwortlich für die Struktur, die diese Inhalte aufnimmt.
Die technische Referenznorm in Deutschland ist die EN 301 549 V3.2.1, die WCAG 2.1 Stufe AA integriert. In der Praxis orientiert sich die tägliche Arbeit an WCAG 2.2, im Oktober 2023 veröffentlicht, mit neun zusätzlichen Erfolgskriterien — insbesondere sichtbarer Fokus (2.4.11), Mindestgröße von Bedienelementen (2.5.8) und konsistente Hilfen (3.2.6). Ein WCAG 2.2 AA-konformer Shop erfüllt EN 301 549 und damit die technischen Anforderungen des BFSG. Für den öffentlichen Sektor gilt parallel die BITV 2.0, die hier nicht direkt relevant ist, in technischen Anforderungen aber kongruent.
Sanktionen, die seit einem Jahr in Deutschland tatsächlich verhängt werden
Die Aufsicht liegt bei den Marktüberwachungsbehörden der Länder, koordiniert durch die Bundesfachstelle Barrierefreiheit. Nach zwölf Monaten:
- Anfänglich überwiegend pädagogische Phase. Die ersten Kontrollen 2025 führten überwiegend zu Mahnungen und Korrekturzusagen. Wenige tatsächliche Bußgelder.
- Verschärfung seit dem ersten Quartal 2026. Mehrere Bußgeldbescheide wurden zugestellt, gestaffelt zwischen 5.000 € und 75.000 € je nach Größe des Betreibers und Schwere (insbesondere bei vollständigem Fehlen einer Erklärung zur Barrierefreiheit).
- Die gesetzliche Höchstgrenze ist hoch: bis zu 100.000 € pro Verstoß nach § 37 BFSG, bei wiederholten oder schweren Verstößen kumulativ anwendbar.
- Indirektes Risiko vermutlich höher: Ausschluss von öffentlichen Ausschreibungen, Ablehnung der Listung durch B2B-Einkaufszentralen, kundenseitige Signale auf Bewertungsportalen.
Die am systematischsten kontrollierte sichtbare Pflicht ist die Erklärung zur Barrierefreiheit, die auf dem Shop veröffentlicht, datiert sein und den erreichten Konformitätsgrad (vollständig / teilweise / nicht konform) sowie einen mehrjährigen Maßnahmenplan ausweisen muss. Ein Shop ohne diese Seite wird in Minuten identifiziert.
Feldaudit: Was auf PrestaShop tatsächlich versagt
Auf Grundlage von Audits über Classic-, Hummingbird-, Warehouse- und Custom-Themes konzentrieren sich die wiederkehrenden Nicht-Konformitäten auf sechs Familien:
1. Unzureichender Kontrast (Kriterium WCAG 1.4.3 / 1.4.11)
Das hellgraue Grau auf weißem Hintergrund, das für durchgestrichene Preise, „inkl. MwSt.“-Hinweise oder Trust-Symbole verwendet wird, scheitert nahezu systematisch am Verhältnis 4,5:1 (Normaltext) oder 3:1 (Großtext und Interfaces). Ein einziger Audit-Durchlauf mit Lighthouse oder axe-core deckt typischerweise 15 bis 40 Kontrastfehler auf einer Standard-Produktseite auf.
2. Defekte Tastaturnavigation
Das obere Dropdown-Menü, die Facettenfilter links, der benutzerdefinierte Mengenwähler, das Newsletter-Popup — diese Komponenten sind häufig allein mit der Tastatur nicht zugänglich (Tab + Enter + Leertaste). Der sichtbare Fokus verschwindet in der Hälfte der Premium-Themes. Ein blockierendes Kriterium.
3. Fehlerhaft etikettiertes Checkout-Formular
Feld ohne zugehöriges label-Attribut, Fehleranzeige nur durch Farbe (rot), kein aria-describedby für Beschränkungen („mindestens 8 Zeichen“), Bestellzusammenfassung für Screenreader nicht zugänglich. Der native One-Page-Checkout in PrestaShop 8 wurde verbessert, bleibt aber lückenhaft, sobald ein Zahlungsmodul oder ein Drittanbieter-Adressselektor hinzukommt.
4. Bilder ohne strukturierten Alternativtext
Das klassische Problem: Alle Produktbilder haben ein leeres alt-Attribut oder den Produktnamen kopiert. Die korrekte Logik: leeres alt für rein dekorative Bilder (alt=““), beschreibendes und differenziertes alt für Sekundäransichten („Rückansicht“, „Detail der Naht“). PrestaShop macht das nicht automatisch — der Händler muss es beim Katalogimport einpflegen.
5. Auto-abspielende Videos und Karussells
Home-Karussell, das ohne Pause-Button von selbst läuft, Produktvideo mit Autoplay: direkter Verstoß gegen Kriterium 2.2.2 (Pause, Stop, Hide). Für einen Besucher mit vestibulären Störungen kann automatisches Scrollen physisch belastend sein.
6. Blockierendes Captcha und aufdringliche Popups
reCAPTCHA v2 „Box ankreuzen“ ohne Alternative für Screenreader-Nutzer, Newsletter-Popup ohne Fokus-Falle, Cookie-Modal nicht per Tastatur schließbar. Drei Klassiker, die jede Marktüberwachungsprüfung in wenigen Minuten findet.
Fahrplan zur Konformität — ohne Theme-Neubau
Gute Nachricht: Die meisten Shops können in 4 bis 8 Wochen gezielter Arbeit substantielle WCAG 2.2 AA-Konformität erreichen, ohne Komplettneubau. Die funktionierende Sequenz:
Woche 1 — Quantifiziertes Audit
Automatisches Audit (axe DevTools, WAVE, Lighthouse) über 10 repräsentative Seiten: Startseite, Kategorie, Produktseite, Warenkorb, Versandschritt, Zahlungsschritt, Bestellbestätigung, Blog, Kontakt, Impressum und Datenschutzerklärung. Ergänzen durch manuellen Tastaturtest und Screenreader-Test (NVDA kostenlos für Windows, VoiceOver für Mac). Eine Matrix „Kriterium / Seite / Schweregrad“ mit Punkten ausgeben.
Woche 2 bis 3 — Oberflächliche Korrekturen mit hohem Hebel
- Anpassung der Farbpalette, um Kontrastverhältnisse zu erreichen — oft eine CSS-Variable zu justieren, höchstens zwei oder drei.
- Globale, sichtbare Fokusanzeige (2-Pixel-Outline mit Kontrastfarbe).
- Alt-Texte im Katalog überarbeiten — oft automatisierbar via SQL-Skript oder dediziertem Modul.
- Autoplay entfernen und Pause-Kontrolle im Karussell hinzufügen.
Woche 4 bis 5 — Kritische Komponenten
- Hauptmenü mit vollständiger Tastaturbedienung neu bauen (Tab, Enter, Escape, Pfeiltasten).
- Korrekte ARIA-Auszeichnung der Facettenfilter, des Mengenwählers und der Warenkorb-Benachrichtigungen.
- Formulare nachbessern: zugehörige Labels, Fehleranzeigen in Text UND Farbe, Fokus auf das erste fehlerhafte Feld.
Woche 6 bis 7 — Redaktionelle Konformität und Erklärung
- Audit der CMS-Seiten und Blog-Artikel (Überschriftenstruktur, Bild-Alt).
- Erstellen und Veröffentlichen der Erklärung zur Barrierefreiheit nach dem amtlichen Muster (Konformitätsstand, begründete Ausnahmen, Feedback-Kanal, Rechtsbehelf).
- Mehrjähriger Maßnahmenplan auf derselben Seite veröffentlicht.
Woche 8 — Nutzertest und Dokumentation
Ein Test mit einer realen Person mit Behinderung (Seh- oder Motorikbeeinträchtigung) bleibt der einzige Weg, um zu validieren, dass kein subtiles Kriterium übersehen wurde. Außerdem ein Argument bei einer Kontrolle: einen kontinuierlichen Verbesserungsprozess nachweisen.
Die Falle der Drittanbieter-Module
Der große blinde Fleck: Drittanbieter-Module fügen ständig nicht auditierte Elemente hinzu. Ein Wishlist-Popup, ein Cross-Sell-Modul mit Karussell, ein Bewertungs-Widget eines Drittanbieters — jede Erweiterung kann die gerade gewonnene Konformität zerstören. Die gesunde Regel: jedes neue Modul vor dem Deployment mit axe-core auditieren und vom Entwickler eine WCAG 2.2 AA-Kompatibilitätserklärung verlangen.
Bei DataFirefly werden alle aktuellen Module (Side-Cart, Alerts, Live-Suche, Page Builder) vor der Veröffentlichung mit axe-core und Screenreadern getestet, und die technische Konformitätserklärung wird auf Anfrage für Händler unter behördlicher Prüfung bereitgestellt.
Fazit: Das Risiko ist nicht mehr theoretisch
Das Argument „niemand prüft“ trägt ein Jahr nach Inkrafttreten des BFSG nicht mehr. Bußgelder beginnen einzuschlagen, die Erklärung zur Barrierefreiheit ist das sichtbare Minimum geworden, und der B2B-Druck steigt — Einkaufszentralen, öffentliche Ausschreibungen und Großauftraggeber fordern inzwischen WCAG-Zusagen in ihren Rahmenverträgen.
Der strategisch richtige Winkel für einen PrestaShop-Händler ist nicht das kosmetische Minimum, sondern die Anpassung als allgemeines UX-Audit zu nutzen: Die meisten Barrierefreiheits-Korrekturen verbessern gleichzeitig die Conversion (Lesbarkeit, Kontrast, Tastaturnavigation für Power-User, bessere semantische Struktur für SEO und AEO). Eine Investition von 4 bis 8 Wochen, die mehreren Zielen dient.
