Barrierefreiheit für Onlineshops: Was der European Accessibility Act für Sie bedeutet
Der EAA gilt seit dem 28. Juni 2025 und wird über nationale Umsetzungen durchgesetzt (in Deutschland das BFSG, in anderen Ländern entsprechende Regelungen), die sich in Details und Schwellenwerten unterscheiden können; die hier genannten Zahlen sind die veröffentlichten EU-Basiswerte, keine Bewertung Ihrer konkreten Situation. Die technischen Wege gelten für PrestaShop 1.6, 1.7, 8 und 9 mit dem Classic-Theme. Dies ist keine Rechtsberatung, klären Sie Ihren Geltungsbereich, mögliche Ausnahmen und nationale Pflichten mit einem Anwalt in Ihrem Land, und beachten Sie, dass kein Modul und kein Theme einen Shop allein "konform" macht.
Hier ist die Tatsache, die viele PrestaShop-Händler nur halb verinnerlicht haben: Seit dem 28. Juni 2025 macht der European Accessibility Act (EAA) Barrierefreiheit im Web für die meisten Onlineshops, die an Verbraucher in der EU verkaufen, zur gesetzlichen Pflicht, nicht zu einem netten Extra und nicht zu einem Problem für 2030. Durchgesetzt wird er auf Ebene der Mitgliedstaaten (in Deutschland über das BFSG, in jedem Land über die jeweilige Umsetzung der Richtlinie), und die Verantwortung liegt beim Händler, nicht bei PrestaShop oder Ihrem Theme-Anbieter. Wenn Ihre Kasse nicht mit der Tastatur abgeschlossen werden kann, ist das jetzt eine Compliance-Lücke mit Ihrem Namen darauf.
Dieser Leitfaden erklärt gezielt, was der EAA für einen PrestaShop-Shop bedeutet und wie Sie die Lücken in der Software schließen, die Sie tatsächlich betreiben, im Theme, im Backoffice und in den Modulen. Er ist der Barrierefreiheits-Baustein unseres Compliance-Clusters; Themen, die zu einem Schwesterbereich gehören (Cookie-Banner, DSGVO, AGB), verlinken wir deshalb nur kurz, statt sie hier erneut auszubreiten. Für das größere rechtliche Bild beim Verkauf in der EU beginnen Sie mit E-Commerce-Recht in der EU.
Für wen der EAA tatsächlich gilt (und wer ausgenommen ist)
Bevor Sie ein Wochenende in Alt-Texte investieren, prüfen Sie, ob das Gesetz für Sie vollständig gilt. Denn davon hängt ab, was Sie tun müssen.
- Sie verkaufen B2C an Verbraucher in der EU: Sie fallen in den Geltungsbereich. "E-Commerce-Dienstleistungen" werden im Gesetz ausdrücklich genannt.
- Sie sind ein Kleinstunternehmen, das Dienstleistungen verkauft: weniger als 10 Beschäftigte und unter 2 Mio. EUR Jahresumsatz oder Bilanzsumme. Dienstleister dieser Größe sind von den Dienstleistungspflichten ausgenommen. Das ist die Ausnahme, unter die viele kleine Shops fallen, aber lesen Sie den nächsten Punkt, bevor Sie sich entspannen.
- Sie verkaufen Produkte (die regulierte Produktliste des EAA, E-Reader, Hardware, Terminals): Die Dienstleistungsausnahme für Kleinstunternehmen gilt nicht für Produkte. Die meisten Shops für Kleidung, Kosmetik oder Haushaltswaren verkaufen keine regulierten Produkte, daher ist das selten der Haken, aber prüfen Sie es, statt es anzunehmen.
- Reines B2B: liegt im Allgemeinen außerhalb des verbraucherbezogenen Geltungsbereichs, auch wenn Barrierefreiheit weiterhin gute Praxis ist und von größeren Einkäufern vertraglich verlangt werden kann.
Und was heißt das? Eine polnische Boutique mit zwei Personen unterhalb der Umsatzschwelle ist rechtlich wahrscheinlich vom harten Druck ausgenommen, aber Barrierefreiheit vergrößert trotzdem den Markt und hilft der SEO, die Arbeit zahlt sich also unabhängig davon aus. Ein wachsender Shop verliert die Ausnahme, sobald er nach den geltenden nationalen Regeln nicht mehr als Kleinstunternehmen gilt. Behandeln Sie den Schwellenwert als Frist, auf die Sie zulaufen, nicht als dauerhaften Schutzschild. Dieser Leitfaden gibt bewusst keine Rechtsberatung zu Ihrem konkreten Status, klären Sie ihn mit einem Anwalt in Ihrem Land; die Zahlen hier sind die veröffentlichten EU-Schwellenwerte, keine Entscheidung über Ihren Fall.
Der Standard hinter dem Gesetz: WCAG 2.1 AA, verständlich erklärt
Der EAA selbst listet keine Pixelverhältnisse auf. Er verweist auf die harmonisierte Norm EN 301 549, die wiederum WCAG 2.1 Level AA als Web-Basis übernimmt. Das ist die Messlatte, die Ihr PrestaShop-Frontoffice erfüllen muss. Die Erfolgskriterien, die einen typischen Shop wirklich treffen, sind überschaubar, und jedes davon lässt sich auf etwas Konkretes in Ihrem Theme abbilden:
| WCAG-Kriterium | Was es in Ihrem Shop bedeutet | Wo es in PrestaShop meist scheitert |
|---|---|---|
| 1.1.1 Nicht-Text-Inhalte | Bilder haben aussagekräftige Alt-Texte | Produktbilder werden mit Dateinamen als Alt-Text importiert; dekorativen Icons fehlt ein leerer Alt-Text |
| 1.4.3 Kontrast (Minimum) | 4,5:1 für normalen Text, 3:1 für großen Text | Hellgraue Preise/"alter Preis", blasse Platzhalterbeschriftungen, kontrastarme Rabatt-Badges |
| 2.1.1 Tastatur | Alles ist ohne Maus bedienbar | Mega-Menü nur per Hover, Karussell-Pfeile, die nie den Fokus erhalten |
| 2.4.7 Fokus sichtbar | Das fokussierte Element ist klar umrandet | Theme-CSS mit outline: none auf Links/Buttons |
| 3.3.1 / 3.3.2 Beschriftungen & Fehler | Felder haben echte Labels; Fehler nennen das Feld | Kassenfelder nur mit Platzhaltern; generisches Banner "Es gibt 1 Fehler" |
| 4.1.3 Statusmeldungen | AJAX-Änderungen werden angekündigt | Warenkorbsumme / Facettenfilter-Updates bleiben für Screenreader stumm |
Das Muster ist deutlich: Fast nichts davon sind Fehler im PrestaShop-Kern. Es sind Entscheidungen, die in Ihrem Theme und Ihren Modulen stecken. Das ist eine gute Nachricht. Denn die Korrekturen liegen in Dateien, die Sie kontrollieren.
Wo PrestaShop Ihnen hilft und wo es Sie angreifbar macht

Das standardmäßige Classic-Theme von PrestaShop 1.7 bis 9 basiert auf Bootstrap und ist ein vernünftiger Ausgangspunkt: Formularfelder verwenden echte <label>-Elemente, die Kasse hat eine logische Überschriftenstruktur, und die meisten nativen Bedienelemente sind per Tastatur erreichbar. Wenn Sie nah am unveränderten Classic-Theme arbeiten, sind Sie weiter, als Sie denken.
Die Schwachstellen entstehen an drei vorhersehbaren Stellen:
- Ihr individuelles oder gekauftes Theme. Viele kostenpflichtige Themes entfernen die Fokusumrandung beim Styling, fügen Menüs ein, die nur per Hover funktionieren, und nutzen dünne graue Schrift, die 1.4.3 nicht erfüllt. Das ist in der Praxis die größte Fehlerquelle.
- Module, die Markup im Frontoffice einfügen. Slider, Schnellansicht-Popups, Cookie-Banner, Wunschlisten-Herzen, Live-Suche-Dropdowns, jedes fügt interaktives DOM hinzu, das möglicherweise nicht per Tastatur bedienbar ist oder nicht angekündigt wird. Jedes installierte Modul ist eine neue Barrierefreiheitsfläche, die getestet werden muss.
- Inhalte, die Sie selbst erstellen. Produktbeschreibungen mit Bildern aus dem Rich-Text-Editor (ohne Alt-Text), CMS-Seiten mit übersprungenen Überschriftenebenen, PDFs mit Linktexten wie "hier klicken". PrestaShop kann nicht korrigieren, was Sie eingeben.
Eine PrestaShop-spezifische Checkliste zur Behebung
Generische Ratschläge wie "Alt-Texte hinzufügen" sind nutzlos, wenn Sie nicht wissen, wo. Hier ist die Karte für Backoffice und Code, grob nach Aufwand und Nutzen sortiert.
1. Alt-Texte für Produktbilder, an der Quelle und gesammelt beheben
Im Produkteditor enthält der Tab Katalog → Produkte → [Produkt] → Bilder für jedes Bild ein Feld Bildunterschrift. Dieser Wert wird im Frontoffice zum alt-Attribut. Das Bild für Bild über einen echten Katalog hinweg zu pflegen, ist der Punkt, an dem gute Vorsätze sterben. Zwei schnellere Wege:
- SQL/Massenbearbeitung: Alt-Texte für Bilder liegen in ps_image_lang.legend (über id_image und id_lang verknüpft). Eine kontrollierte Aktualisierung dort oder ein Import schlägt das manuelle Bearbeiten hunderter Zeilen, vorher ein Backup erstellen.
- Keine neuen Schulden aufbauen: Machen Sie eine sinnvolle Bildunterschrift zu einem festen Teil Ihrer Routine beim Anlegen von Produkten, damit neue Bilder nie leer bleiben. Guter Alt-Text wird auch von Google Bilder gelesen, also verbessern Sie Barrierefreiheit und Auffindbarkeit in einem Schritt. Unsere Smart SEO Revolution suite ist dafür gemacht, solche Onpage-Metadaten katalogweit sauber zu halten, statt Produkt für Produkt.
2. Sichtbarer Fokus, meist eine Ein-Zeilen-Korrektur im Theme
Wenn das CSS Ihres Themes outline: none oder outline: 0 auf Links, Buttons oder Eingabefeldern enthält, ohne einen ebenso sichtbaren Ersatz zu liefern, verlieren Tastaturnutzer vollständig die Orientierung. Durchsuchen Sie assets/css/ Ihres Themes (und jede custom.css) danach. Die richtige Lösung ist nicht, die Regel blind zu löschen, sondern einen klaren :focus-visible-Stil bereitzustellen, eine 2px starke, kontrastreiche Umrandung. Das ist die Änderung mit dem besten Verhältnis aus Wirkung und Aufwand in dieser Liste.
Fügen Sie dies in die custom.css Ihres Themes ein (oder in ein Child-Theme-Stylesheet, damit ein Theme-Update es nicht überschreibt). Es stellt einen sichtbaren Fokusring für interaktive Elemente wieder her, ohne Umrandungen bei Mausklicks erneut zu aktivieren:
/* Restore a visible keyboard focus indicator (WCAG 2.4.7) */
a:focus-visible,
button:focus-visible,
input:focus-visible,
select:focus-visible,
textarea:focus-visible,
[tabindex]:focus-visible {
outline: 2px solid #1a1a1a; /* pick a colour that hits 3:1 against its background */
outline-offset: 2px;
}
Die Umrandungsfarbe muss einen Kontrast von 3:1 zu dem erreichen, was dahinter liegt. Passen Sie den Hex-Wert also an Ihre Palette an, statt ihn blind zu übernehmen. Wenn das Theme outline: none mit !important gesetzt hat, müssen Sie möglicherweise dieselbe Spezifität erreichen. Besser ist aber, die problematische Regel an ihrer Quelle zu entfernen, statt ein weiteres !important darüberzustapeln.
3. Kasse und Formulare, der Teil, an dem Umsatz hängt
Die Kasse ist die Seite, die rechtlich und wirtschaftlich am empfindlichsten ist. Navigieren Sie durch den gesamten Bestellablauf im PrestaShop-Controller order, persönliche Daten, Adressen, Versand, Zahlung, ausschließlich mit der Tastatur. Prüfen Sie, ob jedes Feld ein sichtbares Label hat (nicht nur einen Platzhalter), ob die Auswahlfelder für Versanddienstleister erreichbar sind und ob Validierungsfehler das betroffene Feld nennen, statt nur ein generisches Banner zu zeigen. Zahlungs-iFrames von Drittanbietern (Stripe, PayPal, Adyen) bringen ihre eigene Barrierefreiheit mit, testen Sie die echte Übermittlung von Anfang bis Ende, nicht nur das Laden der Seite. Weil eine barrierefreie Kasse und eine gut konvertierende Kasse weitgehend dieselbe Kasse sind, überschneidet sich das mit allem in unserem Leitfaden zur Zahlungssicherheit, wenn es darum geht, diesen Ablauf sauber umzusetzen.
4. AJAX-Statusmeldungen, der blinde Fleck für Screenreader
PrestaShop aktualisiert die Warenkorbsumme und das Produktraster von ps_facetedsearch, ohne die Seite neu zu laden. Ein sehender Nutzer sieht, dass sich die Zahl ändert; ein Screenreader-Nutzer hört nichts, sofern der aktualisierte Bereich nicht mit aria-live="polite" markiert ist. Das ist WCAG 4.1.3, und es ist das Kriterium, das automatisierte Tools am häufigsten übersehen. Prüfen Sie, ob der Zwischensummenblock im Warenkorb und der Ergebniscontainer der Facettensuche ihre Updates ankündigen, wenn ein Modul den nativen Warenkorb oder die Suche ersetzt hat, liegt diese Prüfung bei diesem Modul.
5. Überschriftenhierarchie und Kontrast, in Minuten prüfbar
Prüfen Sie, ob jede Seite genau ein <h1> hat und keine Ebenen übersprungen werden (eine Kategorieseite, die von H1→H3 springt, verwirrt die Navigation per Screenreader). Beim Kontrast sind die üblichen Problemstellen die gedämpfte Farbe für Preise/alte Preise, Rabatt-Badges und Platzhaltertexte, testen Sie sie mit einem beliebigen Kontrastprüfer gegen 4,5:1.
So testen Sie Ihren Shop, wie Aufsichtsbehörden es tun werden
Automatisierte Scanner finden nur eine Minderheit der Probleme. Häufig wird ungefähr ein Drittel genannt, auch wenn die Schätzungen je nach Tool und Website variieren. Daher sind sie der Startpunkt, nicht die Ziellinie. Testen Sie in Schichten:
- Automatisierter erster Durchlauf: Lighthouse (Chrome DevTools → Accessibility audit), die WAVE-Erweiterung und axe DevTools. Führen Sie sie auf Startseite, Kategorie, Produkt, Warenkorb und jedem Kassenschritt aus, nicht nur auf der Startseite.
- Nur-Tastatur-Durchlauf: Ziehen Sie die Maus ab. Tabben Sie vom Logo bis zur abgeschlossenen Bestellung. Alles, was Sie nicht erreichen oder aktivieren können, ist ein Fehler, Punkt.
- Screenreader-Durchlauf: NVDA (Windows, kostenlos) oder VoiceOver (Mac, integriert). Hören Sie sich eine Produktseite und die Kasse an. Dabei treten Alt-Text-, Label- und aria-live-Probleme zutage, die kein Scanner zuverlässig meldet.
- Zoom auf 200%: Prüfen Sie, dass keine Inhalte abgeschnitten werden und nichts horizontales Scrollen erfordert.
Die Erklärung zur Barrierefreiheit, das Dokument, das viele vergessen
Mehrere nationale Umsetzungen erwarten eine veröffentlichte Erklärung zur Barrierefreiheit: welchen Standard Sie anstreben (EN 301 549 / WCAG 2.1 AA), bekannte Einschränkungen und einen Kontaktkanal für Hinweise zur Barrierefreiheit. In PrestaShop ist das am einfachsten als CMS-Seite (Design → Seiten) umzusetzen, die aus dem Footer verlinkt wird und neben Ihren anderen Rechtstexten steht. Sie gehört ins gleiche Regal wie Ihre Allgemeinen Geschäftsbedingungen, und ist wie diese ein lebendes Dokument, das Sie aktualisieren, wenn Sie ein Problem beheben oder entdecken.
Wo Barrierefreiheit den Rest Ihres Compliance-Stacks berührt
Zwei Teile der Barrierefreiheitsarbeit überschneiden sich stark mit benachbarten Themen. Bearbeiten Sie sie daher dort, wo sie hingehören, statt doppelt:
- Das Cookie-Einwilligungsbanner. Ein Banner, das Tastaturnutzer einschließt oder ohne Maus nicht geschlossen werden kann, verletzt sowohl Barrierefreiheit als auch Einwilligungsrecht. Bringen Sie das Banner selbst einmal sauber in Ordnung. Was es rechtlich leisten muss, steht in Cookie-Einwilligung für PrestaShop und DSGVO- und Cookie-Compliance für PrestaShop, und testen Sie dasselbe Banner anschließend auf Tastaturbedienbarkeit.
- Daten und Formulare. Die Arbeit an barrierefreien Formularen auf Ihren Konto- und Kontaktseiten liegt direkt neben Ihren Pflichten im Umgang mit Daten; die Datenschutzseite ist in DSGVO für Onlineshops abgedeckt.
Der geschäftliche Nutzen über das Bußgeld hinaus
Es lohnt sich, Barrierefreiheit nicht nur als Abgabe zu betrachten. Ein relevanter Teil der Bevölkerung, häufig wird weltweit etwa jede siebte Person genannt, wobei nationale Zahlen variieren, lebt mit einer Behinderung, und deutlich mehr Menschen nutzen Barrierefreiheitsfunktionen situativ: blendendes Sonnenlicht auf dem Smartphone, ein verstauchtes Handgelenk, ein schlafendes Baby, das Audio ausschließt. Jede dieser Personen ist ein Kunde, dem Sie den Kauf derzeit schwerer machen als nötig.
Auch die Überschneidung mit guter technischer Arbeit ist real. Saubere Überschriftenstruktur und Alt-Texte sind dieselben Signale, die Suchmaschinen honorieren; klare Labels und sichtbarer Fokus reduzieren Formularfehler und Abbrüche für alle, nicht nur für Nutzer assistiver Technologien. Sie werden wahrscheinlich nie vollständig trennen können zwischen "das haben wir wegen des EAA gemacht" und "das hat den Shop einfach besser gemacht". Genau das ist der ehrliche Grund, die Arbeit zu erledigen, selbst wenn Ihre Ausnahme als Kleinstunternehmen heute noch greift.
Dauerhaft verankern: Barrierefreiheit als Routine, nicht als Projekt
Shops, die konform bleiben, führen kein heroisches Einmal-Audit durch und vergessen es dann, sie bauen ein paar Prüfungen in bestehende Abläufe ein:
- Produkt hinzufügen: Geben Sie jedem Bild eine Bildunterschrift und halten Sie Beschreibungen in echten Überschriften/Listen, statt fett gesetzte Pseudo-Überschriften zu verwenden.
- Modul installieren: Tabben Sie durch jedes Frontoffice-Element, das es hinzufügt, bevor es live geht; ein nicht barrierefreier Slider oder ein Popup ist eine Regression, die Sie eingeführt haben.
- Theme oder Design ändern: Führen Sie Tastatur- und Kontrastprüfungen erneut durch, bei Umgestaltungen verschwinden Fokusumrandungen und Kontraste oft leise.
- Vierteljährlich: ein 30-minütiger Lighthouse- und Tastaturdurchlauf durch den Kern-Funnel (Startseite → Kategorie → Produkt → Warenkorb → Kasse).
Häufig gestellte Fragen
Gilt der EAA für meinen kleinen PrestaShop-Shop?
Das hängt von Ihrer Größe und davon ab, was Sie verkaufen. Ein Kleinstunternehmen, das Dienstleistungen anbietet, weniger als 10 Beschäftigte und unter 2 Mio. EUR Umsatz oder Bilanzsumme, ist im Allgemeinen von den Dienstleistungspflichten ausgenommen, was viele kleine B2C-Shops betrifft. Die Ausnahme erstreckt sich jedoch nicht auf die regulierte Produktliste des EAA, und reines B2B liegt weitgehend außerhalb des Verbraucherbereichs. Das sind die veröffentlichten EU-Schwellenwerte, keine Entscheidung über Ihren Fall; klären Sie Ihren Status mit einem Anwalt in Ihrem Land, da nationale Umsetzungen variieren.
Welchen Barrierefreiheitsstandard muss ich tatsächlich erfüllen?
Der EAA verweist auf die harmonisierte Norm EN 301 549, die WCAG 2.1 Level AA als Web-Basis übernimmt. Das ist die Messlatte, die Ihr Shop-Frontend erfüllen muss. Die Kriterien, die einen typischen PrestaShop-Shop treffen, sind überschaubar, Alt-Text, Kontrast, Tastaturbedienbarkeit, sichtbarer Fokus, echte Formularlabels und angekündigte AJAX-Updates, und fast alle sind Theme- oder Modulentscheidungen, keine Fehler im Kern.
Ist das standardmäßige PrestaShop-Classic-Theme von Haus aus barrierefrei?
Es ist ein vernünftiger Ausgangspunkt, keine Garantie. Classic verwendet echte <label>-Elemente, eine logische Überschriftenstruktur in der Kasse und größtenteils per Tastatur erreichbare Bedienelemente. Die Fehler kommen meist durch ein individuelles oder gekauftes Theme, das die Fokusumrandung entfernt und dünne graue Schrift nutzt, durch Module, die interaktives Markup einfügen, und durch Inhalte, die Sie ohne Alt-Text erstellen. Je näher Sie am unveränderten Classic-Theme bleiben, desto weniger Nacharbeit haben Sie.
Sagt mir ein automatisierter Scanner, ob ich konform bin?
Nein. Automatisierte Tools (Lighthouse, WAVE, axe) finden nur eine Minderheit der Probleme (häufig wird etwa ein Drittel genannt, auch wenn es je nach Tool und Website variiert), und sind daher nur ein Startpunkt. Sie brauchen weiterhin einen Nur-Tastatur-Durchlauf (Maus abziehen, vom Logo bis zur abgeschlossenen Bestellung tabben), einen Screenreader-Test (NVDA oder VoiceOver) und eine Prüfung bei 200% Zoom. Die Kriterien, die Scanner am häufigsten übersehen, sind genau die, auf die Behörden und echte Nutzer stoßen: aria-live-Ankündigungen, Label-Qualität und Tastaturfallen.
Brauche ich eine Erklärung zur Barrierefreiheit, und wo gehört sie in PrestaShop hin?
Mehrere nationale Umsetzungen erwarten eine: den Standard, den Sie anstreben (EN 301 549 / WCAG 2.1 AA), bekannte Einschränkungen und einen Kontaktkanal für Hinweise zur Barrierefreiheit. Der einfachste Ort dafür in PrestaShop ist eine CMS-Seite unter Design → Seiten, verlinkt aus dem Footer neben Ihren anderen Rechtstexten. Behandeln Sie sie als lebendes Dokument, das Sie aktualisieren, sobald Sie ein Problem beheben oder entdecken.
Der EAA hat keine neue Art von Arbeit erfunden; er hat UX-Arbeit, von der Sie ohnehin profitieren, mit einer gesetzlichen Frist versehen. Gerade in PrestaShop ist diese Arbeit ungewöhnlich gut greifbar, weil die Fehler in Ihrem Theme, Ihren Modulen und Ihren selbst erstellten Inhalten gebündelt auftreten, alles Bereiche, die Sie im eigenen Backoffice sehen und ändern können. Beginnen Sie mit der Kasse (der Seite, auf der fehlende Barrierefreiheit und verlorener Umsatz dasselbe Problem sind), beheben Sie die Fokusumrandung, die Ihr Theme entfernt hat, bringen Sie Alt-Texte an der Quelle unter Kontrolle, und Sie haben einen großen Teil der Anforderungen erfüllt, bevor Sie irgendetwas Exotisches anfassen.