PrestaShop und BFSG: Barrierefreiheit für deinen PrestaShop umsetzen

PrestaShop im BFSG-Kontext

PrestaShop ist in Europa weit verbreitet – besonders bei kleinen und mittleren Online-Shops. Als Open-Source-Shopsystem bietet PrestaShop volle Code-Kontrolle, hat aber keine eingebauten Barrierefreiheits-Features wie etwa Shopware oder Shopify. Das bedeutet: BFSG-Konformität liegt komplett in deiner Verantwortung.

Gemäß § 1 Abs. 3 BFSG müssen Dienstleistungen im elektronischen Geschäftsverkehr – also jeder Online-Shop – seit Juni 2025 die Anforderungen der EN 301 549 erfüllen. Diese Norm verweist auf WCAG 2.1 Level AA. Für PrestaShop-Betreiber heißt das: Du bist nicht nur für deinen Content verantwortlich, sondern auch für die technische Barrierefreiheit deines Themes, deiner Module und deines Checkout-Flows.

Die gute Nachricht: Mit dem richtigen Theme und gezielten Anpassungen ist volle Konformität möglich. PrestaShop gibt dir als Open-Source-System die vollständige Kontrolle über den Code – anders als bei SaaS-Lösungen kannst du jede Zeile anpassen.

PrestaShop-Architektur verstehen: Smarty, Twig und Templates

Um Barrierefreiheit in PrestaShop umzusetzen, musst du die Template-Architektur verstehen. PrestaShop nutzt zwei Template-Engines – je nach Version und Bereich: Weitere Informationen finden Sie im BFSG-Glossar.

Frontend (Storefront): PrestaShop 1.7 und 8.x verwenden im Frontend Smarty-Templates (.tpl-Dateien). Das Classic-Theme basiert vollständig auf Smarty. Hier findest du die Templates unter /themes/classic/templates/.

Backend (Back Office): Ab PrestaShop 1.7.7+ und durchgängig in 8.x werden Backend-Seiten zunehmend auf Twig-Templates migriert (Symfony-Integration). Für die BFSG-Konformität ist primär das Frontend relevant – also Smarty.

Ein typisches Smarty-Template für eine Produktseite sieht vereinfacht so aus:

{* templates/catalog/product.tpl *}
<div id="product-description" role="main">
  <h1 itemprop="name">{$product.name}</h1>
  <img src="{$product.cover.large.url}"
       alt="{$product.cover.legend}"
       loading="lazy">
  {* Fehlend: Wenn legend leer ist, wird alt="" gesetzt *}
</div>

Das Problem: PrestaShop generiert den alt-Text aus dem Feld „Legend“ im Backend. Wenn dieses Feld leer bleibt, erhält das Bild ein leeres alt="" – für Screenreader unsichtbar. Das verletzt WCAG SC 1.1.1 (Textalternativen).

PrestaShop 1.7 vs. 8.x: Was sich ändert

PrestaShop 8.x bringt mehrere Änderungen, die für Barrierefreiheit relevant sind:

• Symfony 5.4+ im Backend: Modernere Controller-Struktur, aber keine direkten Frontend-Auswirkungen.
• Classic-Theme leicht überarbeitet: Einige HTML5-Elemente wurden aktualisiert, aber grundlegende ARIA-Lücken bestehen weiter.
• PHP 8.1+ Support: Ermöglicht modernere Module, ändert aber nichts an der Template-Ebene.
• Neue Hooks: Zusätzliche Hooks (z. B. displayAfterProductActions) erleichtern das Einfügen barrierefreier Elemente ohne Core-Modifikation.

Fazit: Der Versionssprung allein löst keine Barrierefreiheits-Probleme. Die eigentliche Arbeit liegt in den Smarty-Templates und im CSS – und die sind in beiden Versionen nahezu identisch aufgebaut.

Classic-Theme Analyse: Was funktioniert, was nicht

Das Classic-Theme ist der Ausgangspunkt der meisten PrestaShop-Shops. Unsere Analyse zeigt ein gemischtes Bild:

Was funktioniert:

• Grundlegendes semantisches HTML: <header>, <main>, <footer> sind vorhanden
• Navigation verwendet <nav> mit role="navigation"
• Formular-Labels sind im Checkout größtenteils vorhanden
• Breadcrumb-Navigation ist als Liste strukturiert

Was fehlt oder problematisch ist:

• Skip-Link fehlt: Kein „Zum Inhalt springen“-Link – Tastaturnutzer müssen durch die gesamte Navigation tabben (WCAG SC 2.4.1)
• Fokus-Indikatoren: Der CSS-Outline wird oft per outline: none entfernt (WCAG SC 2.4.7)
• Quick View Modal: Kein Fokus-Trapping, kein role="dialog", kein aria-modal="true" (WCAG SC 2.4.3)
• Facettenfilter: Checkboxen sind custom-styled ohne zugehörige Labels (WCAG SC 1.3.1)
• Produktbilder: Alt-Text wird aus „Legend“ gezogen – standardmäßig leer
• Mobile Menu: Hamburger-Button ohne aria-expanded (WCAG SC 4.1.2)

Typische Barrierefreiheits-Probleme in PrestaShop

Das Standard-Theme (Classic) hat moderate Barrierefreiheit: Grundlegendes semantisches HTML ist vorhanden, aber ARIA-Labels fehlen an vielen Stellen. Der Checkout-Prozess ist oft nur teilweise per Tastatur bedienbar. Produktbilder haben häufig keinen Alt-Text (der wird aus dem Produktnamen generiert – nicht immer ausreichend).

Facettenfilter sind selten tastaturzugänglich. Und Pop-ups (Quick View) haben kein Fokus-Management.

Über das Classic-Theme hinaus gibt es weitere systembedingte Probleme:

• Marketplace-Module: Viele Drittanbieter-Module (Slider, Mega-Menüs, Pop-ups) fügen HTML ohne ARIA-Attribute ein. Ein einziges schlecht kodiertes Modul kann die Barrierefreiheit der gesamten Seite untergraben.
• Dynamische Inhalte: AJAX-basierte Warenkorbaktualisierungen und Produktfilter informieren Screenreader nicht über Änderungen (fehlende aria-live-Regionen).
• PDF-Rechnungen: Von PrestaShop generierte PDFs (Rechnung, Lieferschein) sind nicht getaggt und damit für Screenreader unlesbar.

Checkout-Flow barrierefrei gestalten

Der Checkout ist der kritischste Bereich – hier scheitern die meisten PrestaShop-Shops. Der Standard-Checkout in PrestaShop ist ein mehrstufiger Prozess: Persönliche Daten, Adresse, Versand, Zahlung, Bestätigung.

Schritt 1 – Persönliche Daten: Stelle sicher, dass jedes Formularfeld ein sichtbares <label> hat – nicht nur Placeholder-Text. Pflichtfelder müssen mit aria-required="true" gekennzeichnet sein (WCAG SC 1.3.1). Im Smarty-Template:

{* templates/checkout/_partials/customer-form.tpl *}
<div class="form-group">
  <label for="field-firstname">
    Vorname <span aria-hidden="true">*</span>
  </label>
  <input type="text"
         id="field-firstname"
         name="firstname"
         aria-required="true"
         autocomplete="given-name">
</div>

Schritt 2 – Versandauswahl: Versandoptionen sind oft als Radio-Buttons umgesetzt, aber ohne fieldset/legend. Screenreader können dann die Gruppenzugehörigkeit nicht erkennen. Lösung:

<fieldset>
  <legend>Versandart wählen</legend>
  <div class="delivery-option">
    <input type="radio" id="delivery-1"
           name="delivery_option" value="1">
    <label for="delivery-1">
      DHL Standardversand – 4,90 EUR
    </label>
  </div>
</fieldset>

Schritt 3 – Zahlung: Zahlungsmodule (PayPal, Stripe, Mollie) betten oft iFrames ein. Teste, ob der Fokus beim Betreten des iFrames korrekt gesetzt wird und ob Fehlermeldungen (WCAG SC 3.3.1) als Text erscheinen – nicht nur als rote Umrandung.

Schritt 4 – Bestätigung: Die Bestellbestätigung muss per Screenreader lesbar sein. Setze den Fokus nach Absenden auf eine Überschrift wie „Bestellung erfolgreich“ – nicht auf ein dekoratives Häkchen-Icon.

Produktseiten WCAG-konform machen

Die Produktseite ist nach der Startseite die meistbesuchte Seite. Hier sind die wichtigsten Anpassungen:

• Produktbilder: Jedes Bild braucht einen beschreibenden Alt-Text im „Legend“-Feld des Back Office. Nicht „Schuhe“, sondern „Schwarze Lederschuhe, seitliche Ansicht, Größe 42“ (WCAG SC 1.1.1).
• Bildergalerie: Die Thumbnail-Navigation muss per Pfeiltasten bedienbar sein. Das aktive Bild braucht aria-current="true".
• Variantenauswahl: Farb- und Größenwahl als <select> oder role="radiogroup" – nicht als rein visuelle Farbkreise ohne Text-Label.
• „In den Warenkorb“-Button: Muss fokussierbar und eindeutig benannt sein. Nach dem Klick eine aria-live-Meldung: „Produkt wurde zum Warenkorb hinzugefügt“.
• Tab-Struktur (Beschreibung/Details/Bewertungen): Verwende role="tablist", role="tab" und role="tabpanel" mit korrekter aria-selected-Steuerung (WCAG SC 4.1.2).

Modul-Audit: Drittanbieter-Code prüfen

Jedes installierte Modul kann Barrierefreiheit beeinträchtigen. Führe ein systematisches Audit durch:

1. Liste erstellen: Gehe im Back Office zu „Module → Module Manager“ und dokumentiere alle aktiven Module, die Frontend-Output erzeugen.
2. Kategorisieren: Slider, Mega-Menüs, Pop-ups, Newsletter-Formulare, Social-Sharing-Buttons, Cookie-Banner – alle haben Barrierefreiheits-Relevanz.
3. Testen: Jedes Modul einzeln per Tastatur und Screenreader testen. Häufige Probleme: fehlende ARIA-Labels, Fokus-Fallen in Slidern, nicht-schließbare Pop-ups.
4. Entscheiden: Modul anpassen (wenn Open Source), Anbieter kontaktieren, oder Modul deaktivieren und durch barrierefreie Alternative ersetzen.

Besonders kritisch sind Cookie-Consent-Module: Sie erscheinen auf jeder Seite und müssen gemäß WCAG SC 2.1.1 per Tastatur bedienbar sein. Ein nicht-schließbares Cookie-Banner blockiert die gesamte Seitennutzung für Tastaturnutzer.

Code-Beispiele: Smarty-Templates anpassen

Hier sind die wichtigsten Template-Anpassungen für das Classic-Theme. Erstelle ein Child-Theme, um die Änderungen Update-sicher zu machen:

Skip-Link einfügen (templates/_partials/header.tpl):

{* Ganz oben im header.tpl *}
<a class="skip-link" href="#main-content">
  Zum Inhalt springen
</a>

{* CSS dazu: *}
.skip-link {
  position: absolute;
  left: -9999px;
  z-index: 9999;
}
.skip-link:focus {
  left: 10px; top: 10px;
  background: #1e40af; color: #fff;
  padding: 8px 16px;
  border-radius: 4px;
}

Hamburger-Menü barrierefrei (templates/_partials/header.tpl):

<button class="menu-toggle"
        aria-expanded="false"
        aria-controls="mobile-menu"
        aria-label="Hauptmenü öffnen">
  <span class="icon-bar"></span>
</button>
<nav id="mobile-menu" role="navigation"
     aria-label="Hauptnavigation">
  {* Menü-Inhalt *}
</nav>

Quick-View als Dialog (templates/catalog/_partials/miniatures/product.tpl):

<div class="quick-view-modal"
     role="dialog"
     aria-modal="true"
     aria-label="Produktvorschau: {$product.name}">
  <button class="close-modal"
          aria-label="Vorschau schließen">&times;</button>
  {* Produktinhalt *}
</div>

PrestaShop barrierefrei machen: Schritt-für-Schritt

Erstens: Theme prüfen. Das Classic-Theme ist akzeptabel, aber viele Marketplace-Themes sind schlecht. Zweitens: Produktbilder mit individuellen Alt-Texten versehen – nicht nur den Produktnamen verwenden.

Drittens: Checkout per Tastatur testen und problematische Schritte fixen. Viertens: Quick-View-Funktion entweder barrierefrei machen oder deaktivieren. Fünftens: Barrierefreiheits-Module aus dem Marketplace prüfen – es gibt spezialisierte Module für ARIA-Labels und Skip-Links.

Der komplette Fahrplan:

1. Automatisierter Scan: Nutze den bf-check Scanner für einen ersten Überblick. Ergänze mit axe DevTools im Browser.
2. Theme-Entscheidung: Classic-Theme als Basis nutzen oder ein barrierefreies Child-Theme erstellen. Marketplace-Themes nur nach gründlichem Test.
3. Template-Anpassungen: Skip-Link, ARIA-Labels, Fokus-Management – die oben gezeigten Code-Änderungen umsetzen.
4. Modul-Audit: Jedes Frontend-Modul auf Barrierefreiheit prüfen und bei Bedarf ersetzen.
5. Checkout testen: Den gesamten Kaufprozess per Tastatur und Screenreader durchspielen. Vergleiche auch mit WooCommerce-Lösungen für Best-Practice-Beispiele.
6. Produktdaten pflegen: Alt-Texte für alle Bilder, strukturierte Beschreibungen, korrekte Überschriften-Hierarchie.
7. Barrierefreiheitserklärung: Gemäß § 13 BFSG eine Erklärung veröffentlichen, die den aktuellen Stand dokumentiert.
8. Formulare prüfen: Kontaktformular, Newsletter-Anmeldung, Bewertungsformulare – alle brauchen Labels, Fehlerhinweise und logische Tab-Reihenfolge.

PrestaShop-Module für Barrierefreiheit

Im PrestaShop Marketplace gibt es mittlerweile Module, die Barrierefreiheit verbessern: Accessibility-Module für Skip-Links und ARIA-Labels, Kontrast-Anpasser und Schriftgrößen-Tools. Wichtig: Diese Module sind Hilfsmittel, kein Ersatz für saubere Grundstruktur. Ein Overlay-Widget, das nachträglich Barrierefreiheit simuliert, ist nicht BFSG-konform.

Empfehlenswerte Modul-Kategorien:

• Strukturelle Module: Skip-Link-Module, die einen „Zum Inhalt springen“-Link einfügen
• ARIA-Ergänzungen: Module, die fehlende ARIA-Attribute in Standard-Elementen nachträglich setzen
• Cookie-Consent: WCAG-konforme Consent-Banner als Ersatz für nicht-barrierefreie Standard-Module

Vorsicht bei: Overlay-Widgets (z. B. „Accessibility Toolbar“), die einen Button mit Kontrastumschalter und Schriftgrößenregler einblenden. Diese ändern nichts am zugrundeliegenden HTML-Code und erfüllen die EN 301 549 nicht.

Hinweis: Dieser Artikel bietet technische Orientierung zur BFSG-Umsetzung in PrestaShop. Er ersetzt keine Rechtsberatung und kein vollständiges WCAG-Audit. Die konkreten Anforderungen hängen von deinem Shop-Setup, deinen Modulen und deiner PrestaShop-Version ab. Im Zweifel ziehe eine spezialisierte Beratung hinzu.

Häufig gestellte Fragen