Magento / Adobe Commerce und BFSG: Enterprise-Shop barrierefrei machen

Magento und BFSG: Hohe Komplexität, hohe Verantwortung

Magento (jetzt Adobe Commerce) wird typischerweise von mittelgroßen bis großen Online-Shops eingesetzt. Diese Shops haben oft Tausende Produkte, komplexe Filternavigation, Kundenkonto-Bereiche und mehrstufige Checkout-Prozesse. Jede dieser Funktionen muss nach BFSG barrierefrei sein.

Bei der Komplexität von Magento-Shops ist das eine ernsthafte Herausforderung – aber keine unlösbare.

Seit dem Inkrafttreten des Barrierefreiheitsstärkungsgesetzes (BFSG) im Juni 2025 müssen Online-Shops, die unter § 1 Abs. 2 BFSG fallen, die Anforderungen der EN 301 549 und damit der WCAG 2.1 Level AA erfüllen. Für Magento-Shops mit ihren komplexen Frontend-Interaktionen bedeutet das: Jede einzelne User-Journey – von der Produktsuche über den Konfigurator bis zum Checkout – muss für alle Nutzer zugänglich sein.

Hinweis: Dieser Artikel dient der allgemeinen Orientierung und ersetzt keine individuelle Rechtsberatung. Das BFSG und die zugrundeliegende EU-Richtlinie (European Accessibility Act) haben Ausnahmen und Übergangsfristen, die im Einzelfall geprüft werden sollten. Weitere Informationen finden Sie im BFSG-Glossar.

Barrierefreiheits-Status von Magento 2

Magento 2 hat in den letzten Versionen Barrierefreiheit verbessert: Das Luma-Theme nutzt semantisches HTML, grundlegende ARIA-Attribute sind vorhanden, und die Tastatur-Navigation im Checkout funktioniert akzeptabel. Adobe hat ein VPAT (Voluntary Product Accessibility Template) veröffentlicht. Aber: Custom-Themes überschreiben diese Verbesserungen oft.

Und Drittanbieter-Extensions (Payment, Shipping, Reviews) sind selten barrierefrei.

Luma-Theme: Solide Basis mit Lücken

Das Standard-Theme Luma bietet eine brauchbare Grundlage für Barrierefreiheit. Was Luma richtig macht:

Semantische Struktur (WCAG SC 1.3.1 – Info and Relationships): Luma nutzt <header>, <nav>, <main> und <footer>. Produktlisten verwenden <ol>- bzw. <ul>-Elemente. Breadcrumbs sind als <nav aria-label="Breadcrumb"> gekennzeichnet.

Skip-Link (WCAG SC 2.4.1 – Bypass Blocks): Luma enthält einen "Skip to Content"-Link, der bei Tastaturfokus sichtbar wird.

Wo Luma schwächelt: Die Layer-Navigation (Facettenfilter) hat unvollständige ARIA-Attribute. Produktbild-Galerien (Fotorama) sind per Tastatur nur eingeschränkt bedienbar. Das Mini-Cart-Overlay hat kein vollständiges Fokus-Trapping. Und die Mega-Menu-Implementierung verliert bei komplexen Kategoriestrukturen die Tastaturnavigierbarkeit.

Hyva-Theme: Moderner Ansatz, neue Herausforderungen

Das Hyva-Theme hat sich als performante Alternative zu Luma etabliert. Es nutzt Tailwind CSS und Alpine.js statt der jQuery/Knockout.js-Architektur von Luma. Für Barrierefreiheit bedeutet das:

Vorteil: Weniger JavaScript-Komplexität, schnellere Ladezeiten, mehr Kontrolle über den HTML-Output. Entwickler können barrierefreie Komponenten gezielter bauen.

Nachteil: Hyva-Extensions müssen separat auf Barrierefreiheit geprüft werden – sie sind nicht kompatibel mit Luma-Extensions. Das Hyva-Ökosystem ist kleiner, und nicht alle Hyva-Komponenten wurden mit Barrierefreiheit als Priorität entwickelt.

Beide Themes – Luma und Hyva – erfordern Custom-Arbeit für volle BFSG-Konformität. Der Unterschied liegt im Aufwand: Bei Hyva ist die Architektur moderner, bei Luma gibt es mehr dokumentierte Accessibility-Fixes.

Die größten Baustellen in Magento-Shops

Facettenfilter die nur per Maus bedienbar sind. Produktbild-Galerien ohne Tastatursteuerung. Mini-Cart-Overlays ohne Fokus-Management.

Mega-Menüs die per Tastatur nicht navigierbar sind. Kundenregistrierung und Login mit Captchas die nicht zugänglich sind. Und: Der gesamte Checkout-Prozess wenn Payment-Provider nicht barrierefreie iFrames liefern.

Layer-Navigation (Facettenfilter)

Die Layer-Navigation ist bei den meisten Magento-Shops die größte Barrierefreiheits-Baustelle. Typische Probleme und ihre WCAG-Verstöße:

Filter nur per Klick bedienbar (WCAG SC 2.1.1 – Keyboard): Filteroptionen lassen sich oft nicht per Tab + Enter aktivieren. Die Lösung: Stelle sicher, dass jede Filteroption ein fokussierbares Element ist (<a> oder <button>, nicht <div onclick="...">).

Keine Live-Region für Ergebnis-Updates (WCAG SC 4.1.3 – Status Messages): Wenn ein Filter angewendet wird und sich die Produktliste aktualisiert (AJAX), muss der Nutzer informiert werden. Ohne aria-live="polite" auf dem Ergebnisbereich bekommt ein Screenreader-Nutzer nichts mit.

Beispiel für eine barrierefreie Filter-Aktualisierung in einem Magento-Template:

<!-- catalog/layer/view.phtml -->
<div class="block-content filter-content"
     role="region"
     aria-label="Produktfilter">
  <button class="filter-toggle"
          aria-expanded="false"
          aria-controls="filter-options">
    Filter anzeigen
  </button>
  <div id="filter-options" hidden>
    <!-- Filter-Gruppen -->
  </div>
</div>

<!-- Ergebnis-Container -->
<div id="product-list"
     aria-live="polite"
     aria-atomic="false">
  <p class="sr-only" role="status">
    24 Produkte gefunden
  </p>
  <!-- Produktliste -->
</div>

Produktkonfigurator und Varianten

Konfigurierbare Produkte (Farbe, Größe, Material) sind in Magento über Dropdown-Selects oder Swatches gelöst. Die Swatches sind das Problem:

Farbfelder ohne Textlabel (WCAG SC 1.1.1 – Non-text Content): Farbswatches zeigen nur eine Farbe, haben aber keinen Alternativtext. Screenreader lesen "Link" oder gar nichts. Lösung: Jedes Swatch braucht ein aria-label mit dem Farbnamen.

Ausgewählter Status nicht kommuniziert (WCAG SC 4.1.2 – Name, Role, Value): Wenn ein Nutzer eine Variante auswählt, muss der Status (aria-selected="true" oder aria-pressed="true") programmatisch erkennbar sein.

Checkout-Flow: Der kritischste Pfad

Der Checkout ist die wichtigste User-Journey in jedem Online-Shop – und die komplexeste für Barrierefreiheit. Magento nutzt einen Multi-Step-Checkout mit Knockout.js (Luma) bzw. Alpine.js (Hyva).

Step-Indikator (WCAG SC 1.3.1): Die Fortschrittsanzeige muss nicht nur visuell, sondern auch programmatisch den aktuellen Schritt kommunizieren. Nutze aria-current="step" für den aktiven Schritt.

Adressformulare (WCAG SC 1.3.5 – Identify Input Purpose): Jedes Adressfeld braucht das korrekte autocomplete-Attribut. Browser und Passwort-Manager können dann Felder automatisch befüllen – besonders wichtig für motorisch eingeschränkte Nutzer.

Payment-iFrames (WCAG SC 4.1.2): Zahlungsanbieter wie Stripe, PayPal oder Adyen liefern iFrames. Diese brauchen ein title-Attribut. Prüfe, ob die iFrame-Inhalte selbst barrierefrei sind – das liegt beim Zahlungsanbieter, aber du bist gemäß BFSG verantwortlich für die Gesamtnutzbarkeit.

Fehlermeldungen (WCAG SC 3.3.1 – Error Identification): Wenn ein Pflichtfeld fehlt oder eine Kreditkartennummer ungültig ist, muss die Fehlermeldung programmatisch mit dem Feld verknüpft sein und der Fokus auf das erste fehlerhafte Feld gesetzt werden.

Extension-Audit für Magento

Das Magento-Ökosystem lebt von Extensions. Jede Extension bringt eigenes Frontend-HTML mit – und kann die Barrierefreiheit deines Shops zerstören. Besonders kritisch:

Payment-Extensions: Stripe, Mollie, Adyen, PayPal – prüfe, ob die Checkout-Integration per Tastatur und Screenreader nutzbar ist. Fordere beim Anbieter ein Accessibility Statement (VPAT) an.

Review-Systeme: Bewertungssterne, die nur als Bild dargestellt werden, brauchen eine Textbeschreibung. Prüfe, ob das Bewertungsformular Labels hat und ob Sterne per Tastatur auswählbar sind. Vergleiche auch, wie andere Shop-Systeme wie Shopware oder WooCommerce das Thema lösen.

Elasticsearch/Algolia-Suche: Autocomplete-Dropdowns müssen per Tastatur navigierbar sein und ARIA-Combobox-Pattern nutzen (WCAG SC 4.1.2). Live-Ergebnisse brauchen aria-live-Regionen.

Cookie-Consent-Extensions: Cookie-Banner müssen beim Laden den Fokus erhalten und per Tastatur bedienbar sein. Ein Cookie-Banner, das den Seiteninhalt blockiert aber per Tastatur nicht erreichbar ist, sperrt Screenreader-Nutzer komplett aus.

Admin-Konfiguration für Barrierefreiheit

Im Magento-Admin gibt es mehrere Stellen, die direkt die Frontend-Barrierefreiheit beeinflussen:

Stores → Configuration → General → Web: Stelle sicher, dass die Standard-Seitentitel aussagekräftig sind. Leere oder generische <title>-Tags verstoßen gegen WCAG SC 2.4.2 (Page Titled).

Catalog → Product → Images: Das Alt-Text-Feld für Produktbilder ist standardmäßig leer. Bei Tausenden Produkten ist das ein Mammut-Projekt. Tipp: Nutze ein Datenbank-Script oder eine Bulk-Import-CSV um Alt-Texte aus Produktnamen und Attributen zu generieren.

Content → Blocks/Pages: CMS-Blöcke und -Seiten werden im PageBuilder oder TinyMCE erstellt. Achte auf Überschriften-Hierarchie, Alt-Texte und barrierefreie Formulare in Custom-Blöcken.

Code-Beispiel: Barrierefreie Produktbild-Galerie

Die Standard-Galerie (Fotorama in Luma) hat Tastatur-Schwächen. Hier ein PHTML-Override-Ansatz für barrierefreie Thumbnails:

<!-- Magento_Catalog/templates/product/view/gallery.phtml -->
<div class="gallery-wrapper"
     role="region"
     aria-label="Produktbilder">

  <!-- Hauptbild -->
  <div class="gallery-main"
       role="img"
       aria-label="<?= $block->escapeHtmlAttr($product->getName()) ?>">
    <img src="..." alt="<?= $block->escapeHtmlAttr(
      $product->getData('image_alt') ?: $product->getName()
    ) ?>" />
  </div>

  <!-- Thumbnails -->
  <div class="gallery-thumbs" role="tablist"
       aria-label="Produktbild-Vorschau">
    <?php foreach ($images as $index => $image): ?>
    <button role="tab"
            aria-selected="<?= $index === 0 ? 'true' : 'false' ?>"
            aria-label="Bild <?= $index + 1 ?> von <?= count($images) ?>"
            data-image-index="<?= $index ?>">
      <img src="<?= $image['thumb'] ?>" alt="" />
    </button>
    <?php endforeach; ?>
  </div>
</div>

Dieses Pattern nutzt role="tablist" und role="tab" für die Thumbnails, aria-selected für den aktiven Status und beschreibende aria-label-Attribute. Die Thumbnail-Bilder haben leere alt-Attribute, weil die Buttons selbst beschriftet sind.

Magento BFSG-konform machen: Strategie

Bei einem Magento-Shop empfiehlt sich ein professionelles Audit. Schritt 1: BFSG-Scan mit bf-check.de für einen ersten Überblick. Schritt 2: Die kritischsten User-Journeys (Suche, Produktseite, Warenkorb, Checkout) manuell per Tastatur und Screenreader testen.

Schritt 3: Barrierefreiheits-Bugs im Theme fixen. Schritt 4: Alle Drittanbieter-Extensions prüfen und bei den Anbietern Accessibility-Statements einfordern. Schritt 5: Alt-Texte für alle Produktbilder hinterlegen – bei Tausenden Produkten ein Mammut-Projekt.

Priorisierung nach Impact: Konzentriere dich zuerst auf die Seiten mit dem höchsten Traffic und der höchsten Conversion-Relevanz. In der Regel: Startseite → Kategorieseiten → Produktdetailseiten → Checkout → Kundenkonto.

Layout-XML für Barrierefreiheit nutzen: Magento-Layouts werden per XML konfiguriert. Du kannst barrierefreie Attribute direkt in Layout-Dateien setzen, ohne PHTML zu ändern:

<!-- app/design/frontend/Vendor/Theme/Magento_Theme/layout/default.xml -->
<referenceContainer name="header.container">
  <block class="Magento\Framework\View\Element\Template"
         name="skip-link"
         template="Magento_Theme::html/skip-link.phtml"
         before="-" />
</referenceContainer>

Automatisiertes Monitoring: Magento-Shops ändern sich laufend – neue Produkte, Kategorie-Anpassungen, Extension-Updates. Richte regelmäßige automatisierte Scans ein, um Regressionen früh zu erkennen. Vergleiche deinen Shop auch mit den Ansätzen anderer Plattformen wie Shopware.

ARIA richtig einsetzen: Magento-Themes nutzen oft zu viel oder falsches ARIA. Lerne die Grundlagen in unserem Artikel zu ARIA-Attributen, bevor du Custom-Overrides erstellst. Die erste Regel von ARIA: Wenn du ein natives HTML-Element verwenden kannst, verwende kein ARIA.

Häufig gestellte Fragen