Shopsysteme

BFSG in Shopware, WordPress und WooCommerce

Die Verstöße, die wir bei Scans am häufigsten messen, sind erstaunlich gleichförmig – und sie stammen fast nie aus eigenem Code, sondern aus Themes, Page-Buildern und Plugins. Dieser Artikel benennt die typischen Befunde je System und trennt sauber: Was lässt sich im Backend pflegen, und was ist echte Entwicklungsarbeit?

Aktualisiert am 25.08.2026

Lesezeit ca. 7 Minuten

Von Manuel Reichel, Geschäftsführer der MAP Handelsgesellschaft mbH

Warum Standard-Themes so oft stolpern

Themes werden verkauft, weil sie gut aussehen. Barrierefreiheit ist im Verkaufsprozess selten ein Kriterium, und viele der beliebtesten Anpassungen arbeiten sogar dagegen: Fokusrahmen werden entfernt, weil sie „stören“; Beschriftungen werden durch Platzhalter ersetzt, weil das Formular dadurch aufgeräumter wirkt; Bedienelemente werden zu reinen Symbolen, weil Text die Kopfzeile unruhig macht. Jede dieser Entscheidungen ist gestalterisch nachvollziehbar und erzeugt einen messbaren Verstoß.

Hinzu kommt die Vervielfältigung durch Templates: Ein fehlender Button-Name im Produktkachel-Template erscheint nicht einmal, sondern auf jeder Kategorieseite hundertfach. Das ist die gute Nachricht dieser Artikelgattung – eine Korrektur an einer Stelle räumt oft Hunderte von Fundstellen ab.

Shopware: die häufigsten Befunde

Die Storefront von Shopware 6 basiert auf Twig-Templates und Bootstrap. Die folgenden Punkte finden wir dort besonders regelmäßig – teils im Standard, meist aber in angepassten Themes und Drittanbieter-Plugins.

  • Kontraste aus der Theme-Konfiguration

    Die Farbwerte lassen sich im Admin frei setzen. Eine helle Markenfarbe auf weißem Grund sieht in der Vorschau gut aus und rutscht bei Buttons, Badges, Streichpreisen und Hinweistexten unter das erforderliche Kontrastverhältnis von 4,5:1. Betroffen sind fast immer auch Zustände wie „deaktiviert“ und „Hover“.

  • Bildslider ohne Tastaturbedienung

    Karussells auf der Startseite und in der Produktgalerie werden häufig nur per Wischgeste und Maus bedienbar ausgeliefert. Pfeil-Schaltflächen sind dann div-Elemente ohne Rolle, ohne Namen und ohne Fokus. Wer nicht mit der Maus arbeitet, kommt an die Bilder zwei bis acht nie heran.

  • Produktbilder ohne Alternativtext

    In der Medienverwaltung gibt es ein Feld für den Alternativtext. Es ist optional, und beim Massenimport bleibt es leer. Ergebnis: Produktseiten, auf denen ein Screenreader nur Dateinamen vorliest. Auch Bilder in Erlebniswelten sind betroffen.

  • Symbol-Schaltflächen ohne zugänglichen Namen

    Warenkorb, Merkzettel, Suche, Menü und die Schließen-Kreuze der Off-Canvas-Bereiche sind oft reine Icons. Ohne aria-label oder unsichtbaren Text meldet die assistive Technologie nur „Schaltfläche“.

  • Off-Canvas-Bereiche ohne Fokusverwaltung

    Öffnet sich der Warenkorb oder die mobile Navigation seitlich, bleibt der Tastaturfokus häufig auf der Seite dahinter. Man tabbt durch unsichtbare Elemente, und die Escape-Taste schließt nichts.

  • Checkout-Formulare ohne verknüpfte Beschriftung

    Anschrift, Zahlungsart und Gastbestellung sind die kritischsten Formulare des Shops. Angepasste Templates verlieren dort gern die Verknüpfung zwischen Beschriftung und Feld oder ersetzen sie durch einen Platzhalter, der beim Tippen verschwindet.

  • Varianten-Auswahl ohne Semantik

    Farb- und Größenauswahl wird oft als Kette gestylter div- oder span-Elemente gebaut. Optisch funktioniert das, technisch fehlen Rolle, Name und Zustand – die Auswahl ist per Tastatur weder erreichbar noch als getroffene Wahl erkennbar.

WordPress und WooCommerce: die häufigsten Befunde

WordPress selbst bringt eine solide Grundstruktur mit. Die Befunde entstehen meist eine Ebene darüber: im Theme, im Page-Builder und in Plugins.

  • Optisch gestylte Überschriften statt echter Überschriften

    Page-Builder wie Elementor, Divi oder WPBakery erlauben es, jeden Text beliebig groß zu setzen. Häufig ist die sichtbare Kapitelüberschrift technisch ein Absatz, während irgendwo im Footer eine h2 steckt. Die Überschriftenstruktur, an der sich Screenreader-Nutzende orientieren, ist damit unbrauchbar.

  • Leerer Alternativtext in der Mediathek

    Das Feld „Alternativtext“ ist gut sichtbar, wird beim Hochladen aber übersprungen. Bei WooCommerce-Produktgalerien und Beitragsbildern bleibt dann nur der Dateiname. Dekorative Bilder brauchen übrigens einen leeren Alternativtext – nicht gar keinen.

  • Slider- und Popup-Plugins

    Slider, Countdown-Banner und Newsletter-Popups sind eine wiederkehrende Fehlerquelle: automatisch wechselnde Inhalte ohne Stopp-Möglichkeit, Dialoge ohne Fokusverwaltung, Schließen-Symbole ohne Namen.

  • Mengenfeld und Varianten im Produktformular

    Das Mengenfeld von WooCommerce wird in vielen Themes ohne sichtbare Beschriftung ausgeliefert, Varianten-Auswahlfelder verlieren beim Umbau ihre Verknüpfung. Beides trifft direkt den Bestellvorgang.

  • Statusmeldungen, die niemand mitbekommt

    „Produkt wurde in den Warenkorb gelegt“ erscheint visuell, wird aber ohne Live-Region nicht angesagt. Wer nicht sieht, dass sich etwas geändert hat, klickt ein zweites Mal.

  • Gleichlautende Links in Produktlisten

    Zwanzig Links mit dem Text „Weiterlesen“ oder „In den Warenkorb“ sind ohne Kontext nicht unterscheidbar. Abhilfe schafft ein ergänzender, visuell versteckter Produktname im Linktext.

  • Cookie-Banner als Fokusfalle

    Consent-Plugins legen einen Dialog über die Seite. Ist der Fokus nicht darin gefangen und der Hintergrund nicht inaktiv geschaltet, tabbt man an der Entscheidung vorbei – und kann sie unter Umständen mit der Tastatur gar nicht treffen.

Backend-Pflege oder Code-Arbeit?

Diese Trennung entscheidet über Budget und Zeitplan. Grob gilt: Inhalte sind Redaktionsarbeit, Struktur und Verhalten sind Entwicklungsarbeit. Wie sich das auf die Rechnung auswirkt, steht im Artikel Was kostet die BFSG-Umsetzung wirklich?.

Wo welche Aufgabe gelöst wird
Aufgabe Bearbeitungsort
Alternativtexte für Produkt- und Beitragsbilder Backend, Redaktion (Medienverwaltung bzw. Mediathek)
Aussagekräftige Seitentitel und Linktexte Backend, Redaktion
Korrekte Überschriftenebenen im Inhalt Backend, sofern der Editor echte Ebenen anbietet – sonst Template
Farbwerte des Themes meist Backend, aber nur nach Kontrastprüfung aller Zustände
Sichtbare Fokus-Stile Code: CSS im eigenen Theme bzw. Child-Theme
Zugängliche Namen für Symbol-Schaltflächen Code: Template-Override
Formularbeschriftungen im Checkout Code: Template-Override
Slider, Off-Canvas und Dialoge bedienbar machen Code: JavaScript und Template
Statusmeldungen für assistive Technologien Code: Live-Region im Template
Consent-Dialog Konfiguration beim Anbieter, im Zweifel Anbieterwechsel

Für die Code-Zeile gilt in beiden Systemen dieselbe Regel: Änderungen gehören in ein eigenes Theme oder Child-Theme beziehungsweise in ein eigenes Plugin mit Template-Overrides – niemals direkt in Kern- oder Kaufdateien. Sonst ist die Korrektur beim nächsten Update wieder verschwunden.

Warum Plugins die Verstöße nicht entfernen

Für beide Systeme werden Erweiterungen angeboten, die Barrierefreiheit per Installation versprechen. Technisch legen sie eine zusätzliche Bedienschicht über die Seite: ein Symbol, ein Menü mit Reglern für Schriftgröße, Kontrast oder Zeilenabstand, dazu Skripte, die zur Laufzeit Attribute ergänzen sollen.

Was dabei nicht passiert: Der ausgelieferte Quelltext ändert sich nicht. Ein Produktbild ohne Alternativtext bleibt eines. Ein Eingabefeld ohne Beschriftung bleibt eines. Eine Prüfung – ob durch eine Behörde, eine Agentur oder ein automatisiertes Werkzeug – misst weiterhin dieselben Verstöße. Automatisch ergänzte Attribute sind zudem raten, nicht wissen: Ein Skript kann nicht erkennen, was auf einem Foto zu sehen ist oder wofür eine Schaltfläche gedacht ist.

Hinzu kommt, dass diese Bedienschicht mit den Hilfsmitteln kollidieren kann, die Betroffene tatsächlich nutzen – Screenreader, Vergrößerungssoftware, eigene Browser-Einstellungen. Wir bieten deshalb bewusst kein Overlay an, auch nicht als Zwischenschritt.

Ein Vorgehen, das in beiden Systemen funktioniert

  1. Messen statt schätzen. Automatisierter Scan der Vorlagen-Typen: Startseite, Kategorie, Produkt, Warenkorb, Checkout, Konto, Formularseiten. Mehr braucht es zu Beginn nicht, weil sich Befunde über Templates wiederholen.
  2. Nach Template gruppieren. Jeden Befund der Datei zuordnen, aus der er stammt. Aus 400 Einzelfundstellen werden so oft 12 Aufgaben.
  3. Update-fest umsetzen. Korrekturen in Child-Theme, eigenem Theme oder eigenem Plugin – mit Notiz, welches Original überschrieben wurde.
  4. Nachmessen und wiederholen. Re-Scan nach jeder Umsetzungsrunde, danach regelmäßig. Jedes Theme-Update und jedes neue Plugin kann Verstöße neu einführen.

Und die ehrliche Grenze bleibt auch hier: Automatisierte Prüfung deckt die maschinell prüfbaren WCAG-Kriterien ab; eine vollständige Konformitätsbewertung erfordert zusätzlich eine manuelle Prüfung – etwa der Tastaturbedienung des kompletten Kaufprozesses und der inhaltlichen Qualität von Alternativtexten.

Weiterlesen

Erstscan für Ihr Shopsystem

Wir scannen die relevanten Vorlagen-Typen Ihres Shops automatisiert nach WCAG 2.1 AA und ordnen jeden Befund der verursachenden Vorlage zu. Anschließend beheben wir die messbaren technischen Verstöße nach WCAG 2.1 AA / EN 301 549 update-fest im Quellcode – oder liefern Ihrem Team eine präzise Fix-Anleitung.

Kostenlosen Erstscan anfordern

Dieser Artikel ist eine technische Einordnung und keine Rechtsberatung. Die genannten Befunde stammen aus eigenen Prüfläufen mit einer etablierten Open-Source-Prüfengine gegen die maschinell prüfbaren Erfolgskriterien der WCAG 2.1 AA sowie aus manuellen Stichproben. Produkt- und Herstellernamen dienen ausschließlich der Beschreibung des jeweiligen Systems.