Weder Magento Open Source noch Adobe Commerce macht einen Shop von sich aus barrierefrei oder nicht barrierefrei. Entscheidend ist die Storefront, die bei Ihren Kundinnen und Kunden ankommt – und die kann bei Magento dreierlei sein: ein Theme auf Basis von Luma oder Blank, ein Hyvä-Theme oder ein Headless-Frontend. Diese Seite trennt, was Adobe und die Frontend-Anbieter mitbringen, von dem, was Ihre Aufgabe bleibt – in den meisten Mittelstandsshops die Ihrer Agentur –, und nennt die Stellen, die Sie zuerst prüfen sollten.
Gilt das BFSG für Ihren Magento-Shop?
Wenn Sie über Magento oder Adobe Commerce an Verbraucherinnen und Verbraucher verkaufen, erbringen Sie eine „Dienstleistung im elektronischen Geschäftsverkehr“ (§ 1 Abs. 3 Nr. 5 BFSG). Dafür gilt das Barrierefreiheitsstärkungsgesetz seit dem 28. Juni 2025 [1]. Es setzt den European Accessibility Act um; wer in andere EU-Länder verkauft, trifft dort auf vergleichbare nationale Gesetze [2].
Ausgenommen sind Kleinstunternehmen, die Dienstleistungen erbringen: weniger als zehn Beschäftigte und höchstens 2 Mio. € Jahresumsatz oder Jahresbilanzsumme (§ 2 Nr. 17, § 3 Abs. 3 BFSG) [1]. Nur wenige Magento-Händler liegen unter dieser Grenze; Einzelheiten stehen auf unserer Seite zur Ausnahme für Kleinstunternehmen. Ein reiner B2B-Shop, der nur an Gewerbekunden verkauft, erbringt keine Dienstleistung für Verbraucher. Viele Magento-Installationen bedienen aber Fach- und Endkunden aus derselben Codebasis. Sobald Verbraucher kaufen können, sollten Sie diesen Teil als erfasst behandeln.
Anwendungsbereich, Marktüberwachung und Pflichtinformationen erklärt unser Überblick BFSG für Onlineshops. Zum Vergleich: Shopware und OXID eShop.
Was Magento mitbringt – und was nicht
Sie bekommen:
- Zwei Referenz-Themes und Vererbung. Magento liefert Luma als Demonstrations-Theme und Blank als Grundlage für eigene Themes. Ein eigenes Theme kann von beiden erben und überschreibt nur die Dateien, die es ändert [4]. Eine Korrektur im Eltern-Theme erreicht damit jedes Kind-Theme – ein Fehler allerdings auch.
- Einen veröffentlichten Konformitätsbericht. Adobe hat für Adobe Commerce einen Accessibility Conformance Report (Mai 2021) veröffentlicht, geprüft gegen WCAG 2.0 und 2.1 auf den Stufen A und AA sowie EN 301 549 V3.1.1, und er umfasst die Luma-Storefront [3].
- Neuere Frontends mit Barrierefreiheitsanspruch. Hyvä gibt an, dass sein Theme ab Release 1.3.0 Barrierefreiheitsfunktionen nach WCAG 2.1 Stufe AA umsetzt [6]. Adobes eigene Storefront auf Edge Delivery Services, gebaut aus sogenannten Drop-in-Komponenten [7], führt Barrierefreiheitskorrekturen in ihren Release Notes auf, zuletzt im Juli 2026 [8].
- Slider-Einstellungen im Page Builder. Der Page Builder, seit Adobe Commerce 2.3.1 der Inhaltseditor und seit 2.4.3 auch in Magento Open Source enthalten [10], lässt Redaktionen Autoplay, Pfeile und Navigationspunkte je Slider ein- oder ausschalten [11].
Sie bekommen nicht:
- Ein konformes Luma. Adobes Bericht bewertet die Luma-Storefront unter anderem bei Nicht-Text-Inhalt, Info und Beziehungen, Tastatur, Fokus-Reihenfolge, sichtbarem Fokus, Beschriftungen sowie Name, Rolle, Wert nur mit „Partially Supports“ [3].
- Barrierefreie Erweiterungen. Jede Extension mit Frontend-Ausgabe bringt eigene Templates und eigenes JavaScript mit. Die Hyvä-Dokumentation sagt es deutlich: Sowohl bei installierten Erweiterungen als auch bei Theme-Anpassungen ist Sorgfalt nötig, um die Barrierefreiheit nicht zu verschlechtern [6].
- Ein fertiges Headless-Frontend. Adobe beschreibt Venia, die Storefront von PWA Studio, als „proof-of-concept storefront“ [9]. Was Ihre Agentur darauf gebaut hat, ist eigener Code und muss als solcher geprüft werden.
- Brauchbare Alt-Texte. Alternativtexte kommen aus Ihren Katalogdaten – den Bildeinstellungen am Produkt, einem Import oder einem PIM. Eine Herstelleraussage über das Theme sagt darüber nichts.
Was wir auf Magento-Shops finden
Themes, die Lumas Fehler erben
Viele Mittelstandsshops laufen mit einem eigenen Theme, das von Luma oder Blank erbt. Was das Eltern-Theme falsch macht, behält das Kind-Theme, solange niemand das betreffende Template überschreibt. Adobes eigener Bericht nennt solche Fehler in Luma: Hauptnavigationspunkte, die sich nicht per Tastatur aktivieren lassen, Paginierung auf Listenseiten ohne sichtbaren Fokus und ein interaktives Hauptbild in der Galerie ohne passende Rolle [3]. Prüfen Sie, ob Ihr Theme diese Templates überschreibt – und ob die Korrektur je gemacht wurde.
Layered Navigation und Swatches
Die Filter in der Seitenleiste laden die Produktliste neu, sagen aber nicht an, wie viele Treffer es gibt. Der Fokus springt danach oft an den Seitenanfang oder geht verloren. Konfigurierbare Produkte mit visuellen oder Text-Swatches zeigen die gewählte Option nur als Rahmen und eine nicht lieferbare Kombination nur als ausgegraute Kachel. Ändern sich danach Preis oder Bestand, bekommt ein Screenreader davon nichts mit.
Mini-Cart und Meldungen, die niemand hört
Nach „In den Warenkorb“ erscheint oben auf der Seite eine Meldung, und im Header ändert sich ein Zähler. Beides wird nicht als Statusmeldung angesagt. Das Mini-Cart-Dropdown öffnet sich, ohne dass der Fokus hineinwandert, und sein Schließen-Button ist oft ein Symbol ohne Namen.
Headless-Frontends und clientseitiges Routing
PWA- und Headless-Builds wechseln Seiten ohne Neuladen. Kümmert sich das Frontend nicht darum, bleibt der Seitentitel gleich, der Fokus bleibt auf dem angeklickten Link, und wer einen Screenreader nutzt, erfährt nicht, dass eine neue Seite geladen wurde. Die Korrekturen in Adobes Storefront-Release vom Juli 2026 – zugängliche Namen, Statusansagen, autocomplete-Attribute, Umbruch der Header-Panels [8] – zeigen, welche Art Fehler hier auftritt.
Checkout, CAPTCHA und Erweiterungen
Der Standard-Checkout ist aus JavaScript-UI-Komponenten gebaut [5], und viele Shops ersetzen ihn durch eine One-Step-Checkout-Erweiterung oder ein separates Checkout-Produkt. Für den Standard-Checkout in Luma nennt Adobes Bericht: Das Gutscheinfeld bekommt den Fokus erst nach dem Button „Place Order“, die Überschriftenstruktur bildet den Inhalt nicht ab, Pflichtfelder sind in einigen Formularen nur mit Sternchen markiert, und das CAPTCHA bei Anmeldung und Checkout beruht auf einem Bild ohne alternative Aufgabe [3].
Inhalte aus dem Page Builder
Ein Page-Builder-Slider kann beim Laden starten und endlos wiederholen, mit einer Standardpause von 4.000 Millisekunden zwischen den Folien [11]. Ohne sichtbare Pause-Schaltfläche verletzt das WCAG 2.2.2. Banner mit eingebrannter Überschrift im Bild umgehen alles, was das Theme richtig macht.
Wo Sie zuerst prüfen sollten
| Kriterium | Warum bei Magento | Automatisierbar |
|---|---|---|
| 2.1.1 Tastatur (A) | Luma-Navigation, Swatches, Menüs aus Erweiterungen | Teilweise automatisiert |
| 2.4.3 Fokus-Reihenfolge (A) | Gutscheinfeld nach „Place Order“, Mini-Cart, clientseitiges Routing | Teilweise automatisiert |
| 2.4.7 Fokus sichtbar (AA) | Paginierung, Theme-CSS | Teilweise automatisiert |
| 4.1.2 Name, Rolle, Wert (A) | Galeriebild, Swatches, Icon-Buttons | Teilweise automatisiert |
| 4.1.3 Statusmeldungen (AA) | Warenkorb-Meldung, Filtertreffer | Nur manuell |
| 3.3.2 Beschriftungen oder Anweisungen (A) | Pflichtfelder nur mit Sternchen | Teilweise automatisiert |
| 3.3.8 Zugängliche Authentifizierung (Minimum) (AA) | Bild-CAPTCHA bei Anmeldung und Checkout | Nur manuell |
| 1.1.1 Nicht-Text-Inhalt (A) | CAPTCHA-Bild, Katalogbilder | Teilweise automatisiert |
| 2.2.2 Pausieren, stoppen, ausblenden (A) | Automatisch laufende Page-Builder-Slider | Teilweise automatisiert |
| 1.4.3 Kontrast (Minimum) (AA) | Theme-Farben, Rabatt-Badges | Automatisiert |
„Automatisiert“ heißt: Eine Regel kann das Kriterium allein entscheiden. „Teilweise automatisiert“ heißt: Eine Regel findet einen Teil der Fehler, den Rest muss ein Mensch beurteilen. Alle Kriterien stehen in WCAG 2.2 AA, Kriterium für Kriterium.
Eine sinnvolle Reihenfolge
- Frontend und Verantwortliche benennen. Luma-Kind-Theme, Hyvä oder Headless – und in welcher Version. Davon hängt ab, in wessen Code ein Befund steckt und wer ihn beheben kann; bei den meisten Magento-Shops steht das im Agenturvertrag.
- Gegen das Eltern-Theme vergleichen. Lassen Sie eine Staging-Kopie einmal mit dem reinen Eltern-Theme (Blank, Luma oder dem Hyvä-Standard) prüfen, bei Headless mit dem Boilerplate, auf dem Ihr Build aufsetzt. Was dort verschwindet, kommt aus Ihrem eigenen Theme.
- Die Kaufstrecke mit der Tastatur gehen – in jeder Store View, die an Verbraucher verkauft. Kategorie → Layered Navigation → konfigurierbares Produkt → Warenkorb → Kasse → Zahlung im Sandbox-Modus.
- Erweiterungen mit Frontend-Ausgabe inventarisieren. Checkout, Suche, Menüs, Bewertungen, Consent. Entscheiden Sie je Erweiterung: korrigieren, ersetzen oder als bekannte Einschränkung dokumentieren. Fragen Sie Anbieter nach Testnachweisen statt nach einem Siegel.
- Katalogdaten an der Quelle reparieren. Alt-Texte und Swatch-Beschriftungen gehören ins Backend, in den Import oder ins PIM, nicht in Templates.
- Nach jedem Upgrade erneut prüfen. Magento-Releases, Hyvä-Updates und neue Drop-in-Versionen ändern das Markup. Machen Sie eine Barrierefreiheitsprüfung zum Teil der Abnahmekriterien Ihrer Agentur.
Was Reviseberg auf Magento-Shops prüft – und was Sie selbst testen
Reviseberg crawlt Ihren Shop einschließlich Kategorie- und Produktseiten und führt auf jeder Seite alle axe-core-Regeln in einer Desktop-Breite von 1280 Pixeln aus. Die Regeln, deren Ergebnis vom Layout abhängt – etwa Kontrast und Zielgröße –, laufen zusätzlich bei 360 Pixeln. Die Ergebnisse sind WCAG 2.2 A/AA und EN 301 549 zugeordnet. Befunde werden je Regel zu Issues zusammengefasst und danach sortiert, wie viele Punkte ihre Behebung bringt. Ein Fehler in einem Eltern-Template erscheint deshalb als ein Issue auf 400 Seiten und nicht als 400 Einzelbefunde. Mit einem Konto kann Reviseberg auch eine passwortgeschützte Staging-Umgebung crawlen.
Der Tastatur-Agent öffnet die Seiten einer Journey, die Sie festlegen – Kategorie, Produktseite, Warenkorb –, drückt auf jeder Tab, Umschalt+Tab und Escape und protokolliert jeden Schritt. Er meldet unerreichbare Elemente, verschwindenden oder unsichtbaren Fokus, fehlende Skip-Links und Tastaturfallen. Formulare füllt er nicht aus, und er bestellt nicht. Die Kassenschritte hinter einem gefüllten Warenkorb und das Zahlungs-Iframe gehen Sie also selbst. Der kostenlose Bericht umfasst bis zu 100 Seiten und den Tastatur-Agenten auf einer Seite Ihrer Wahl.
Selbst testen müssen Sie weiterhin: ob Alt-Texte das Bild sinnvoll beschreiben, ob Fehlermeldungen verständlich sind und wie sich der Shop mit Screenreader und Zoom verhält. Agenten für Screenreader, Zoom und Sprachsteuerung sind noch nicht gebaut. Für diese Kriterien gibt es geführte manuelle Tests in der Plattform, und ein Kriterium, das niemand geprüft hat, gilt als ungeprüft – nie als bestanden. Es gibt keine Magento-Extension und keinen Connector: Nichts wird automatisch in Ihren Shop eingespielt, und wir setzen kein Overlay-Skript ein.
Geschrieben, um nützlich zu sein, nicht als Rechtsberatung. Stand: 27. September 2026.