Die Produktseite entscheidet über den Kauf. Sie ist damit nicht nur die wichtigste Conversion-Seite Ihres Shopify-Stores, sondern auch der Ort, an dem eine Barriere am teuersten ist: Wer hier scheitert, kauft nicht. Gleichzeitig ist die Produktseite technisch eine der komplexesten Seiten, weil sie Variantenauswahl, Mengenfeld, Bildergalerie, Warenkorb-Aktion und oft noch Akkordeons, Tabs und Bewertungen auf engem Raum bündelt. Dieser Beitrag führt Sie Baustein für Baustein durch eine barrierefreie Produktseite, jeweils mit dem zuständigen WCAG-Erfolgskriterium und mit Liquid-Code, den Sie direkt in Ihr Theme übernehmen können.
Eine Produktseite vereint mehr interaktive Bedienelemente als fast jede andere Seite im Shop. Jeder dieser Bausteine kann für sich genommen eine Barriere errichten. Eine Variantenauswahl, die nur per Maus funktioniert, schließt Tastatur- und Screenreader-Nutzer vom Kauf aus. Ein Produktbild ohne Alternativtext bleibt für blinde Nutzer leer. Ein In-den-Warenkorb-Button, der nach dem Klick keine wahrnehmbare Rückmeldung gibt, lässt Screenreader-Nutzer im Unklaren, ob die Aktion überhaupt funktioniert hat. Weil diese Bausteine zusammenwirken, lohnt sich eine systematische, Schritt-für-Schritt-Prüfung statt einer punktuellen Stichprobe.
Das BFSG (BGBl. 2021 I S. 2970) setzt die EU-Richtlinie 2019/882 (European Accessibility Act, EAA) in deutsches Recht um. Online-Shops fallen nach § 1 Abs. 3 Nr. 5 BFSG als "Dienstleistungen im elektronischen Geschäftsverkehr" in den Anwendungsbereich. Über Anlage I der EU-Richtlinie 2019/882 verweist das BFSG auf die harmonisierte Norm EN 301 549 v3.2.1, die in ihrem Kapitel 9 die WCAG-2.1-AA-Erfolgskriterien für Webinhalte übernimmt. Das Gesetz ist seit dem 28. Juni 2025 anwendbar.
Bei Verstößen sieht § 37 BFSG Bußgelder vor. Nach § 37 Abs. 2 BFSG beträgt der Rahmen für das nicht konforme Anbieten oder Erbringen einer Dienstleistung bis zu 100.000 EUR. Die rechtliche Verantwortung trägt nach § 8 BFSG der Diensteanbieter, also der Händler. Das gilt auch dann, wenn die Produktseite überwiegend aus dem gekauften Theme oder aus installierten Apps stammt. AccessifyAI hilft, Verstöße zu finden und zu beheben, garantiert aber keine Rechts- oder BFSG-Konformität.
Vom Anwendungsbereich ausgenommen sind nach § 3 Abs. 3 BFSG nur Kleinstunternehmen, also Unternehmen mit weniger als zehn Beschäftigten UND einem Jahresumsatz oder einer Jahresbilanzsumme unter zwei Millionen EUR. Beide Bedingungen müssen kumulativ erfüllt sein.
Fünf Erfolgskriterien aus EN 301 549 v3.2.1 bilden den Kern der Anforderungen an eine Produktseite. Alle fünf sind über das BFSG verbindlich.
| Kriterium |
Inhalt |
Stufe |
| WCAG 1.1.1 Non-text Content |
Bilder brauchen einen Textersatz |
A |
| WCAG 1.3.1 Info and Relationships |
Struktur und Beziehungen müssen im Code erkennbar sein |
A |
| WCAG 2.1.1 Keyboard |
Jede Funktion muss per Tastatur bedienbar sein |
A |
| WCAG 4.1.2 Name, Role, Value |
Bedienelemente brauchen Name, Rolle und Zustand |
A |
| WCAG 4.1.3 Status Messages |
Statusänderungen müssen ohne Fokuswechsel angekündigt werden |
AA |
Vier dieser Kriterien sind Stufe A, das niedrigste und damit am striktesten geforderte Konformitätsniveau. WCAG 4.1.3 ist Stufe AA und damit Teil des über die Norm referenzierten Mindestmaßstabs.
Eine logische Überschriftenstruktur ist das Skelett der Seite. Screenreader-Nutzer springen über die Überschriften von Abschnitt zu Abschnitt, ähnlich wie sehende Nutzer eine Seite überfliegen. Bricht die Hierarchie, geht diese Orientierung verloren.
Regel: genau ein <h1> pro Seite, und das ist der Produktname. Darunter folgt eine lückenlose Staffelung mit <h2> für Hauptabschnitte (etwa "Beschreibung", "Details", "Versand", "Bewertungen") und <h3> für untergeordnete Punkte. Überspringen Sie keine Ebene und wählen Sie die Ebene nie nach der gewünschten Schriftgröße, sondern nach der inhaltlichen Bedeutung.
In Shopify-Themes wird der Produkttitel in der Regel in der Haupt-Produkt-Section ausgegeben. Achten Sie darauf, dass er als <h1> ausgezeichnet ist:
<h1 class="product__title">{{ product.title }}</h1>
Ein häufiger Fehler: Der Theme-Entwickler nutzt für den Produkttitel ein <p> oder ein <div> mit großer Schrift und vergibt das <h1> stattdessen an das Shop-Logo im Header. Prüfen Sie die Seite mit einer Überschriften-Erweiterung im Browser oder über die Gliederungsansicht eines Screenreaders. Es darf nur ein einziges <h1> geben, und es muss der Produktname sein.
Die Auswahl von Größe und Farbe ist der heikelste Baustein. Zwei Muster sind verbreitet, und beide bergen typische Fehler.
Das robusteste Muster ist die native Auswahlliste. Ein <select> mit einem zugehörigen <label> ist von Haus aus tastaturbedienbar und für Screenreader beschriftet:
<label for="variant-size">Größe</label>
<select id="variant-size" name="options[Größe]">
{% for value in product.options_by_name['Größe'].values %}
<option value="{{ value }}">{{ value }}</option>
{% endfor %}
</select>
Beliebter, aber fehleranfälliger sind Varianten-Buttons oder Farbfelder (Swatches). Hier passieren drei typische Verstöße: Die Auswahl wird über ein <div> statt eines echten Bedienelements umgesetzt und ist deshalb nicht per Tastatur erreichbar (Verstoß gegen WCAG 2.1.1). Der ausgewählte Zustand wird nur farblich markiert, aber nicht im Code hinterlegt (Verstoß gegen WCAG 4.1.2). Und ein Farbfeld trägt keinen Textnamen, sodass der Screenreader nur "Schaltfläche" vorliest, ohne die Farbe zu nennen.
Setzen Sie Swatches als Radio-Gruppe um. Native Radiobuttons sind tastaturbedienbar, kennen den ausgewählten Zustand und lassen sich visuell frei gestalten, solange das Eingabeelement zugänglich bleibt:
<fieldset>
<legend>Farbe</legend>
{% for value in product.options_by_name['Farbe'].values %}
<input
type="radio"
name="Farbe"
id="farbe-{{ forloop.index }}"
value="{{ value }}"
class="visually-hidden"
{% if forloop.first %}checked{% endif %}>
<label for="farbe-{{ forloop.index }}">{{ value }}</label>
{% endfor %}
</fieldset>
Das <fieldset> mit <legend> gruppiert die Optionen und nennt den Optionsnamen ("Farbe"). Jedes <label> trägt den Wertnamen ("Blau", "Grün"), sodass der Screenreader "Farbe, Blau, Optionsfeld" ankündigt. Die native Checkbox oder der Radiobutton darf dabei nicht per display: none ausgeblendet werden, weil das die Tastaturbedienung entfernt. Nutzen Sie stattdessen die visually-hidden-Technik, die das Element visuell verbirgt, aber für Tastatur und Screenreader zugänglich lässt.
Der Mengen-Stepper besteht aus einem Eingabefeld und meist zwei Plus-/Minus-Schaltflächen. Drei Punkte sind hier zu beachten. Das Eingabefeld braucht ein Label, das nicht nur ein Platzhalter sein darf. Die Plus- und Minus-Schaltflächen müssen echte <button>-Elemente sein und einen sprechenden Namen tragen. Und ein Symbol allein, etwa ein Minuszeichen, genügt nicht als Name.
<label for="Quantity">Menge</label>
<button type="button" class="quantity__button" aria-label="Menge verringern">−</button>
<input
type="number"
id="Quantity"
name="quantity"
value="1"
min="1">
<button type="button" class="quantity__button" aria-label="Menge erhöhen">+</button>
Das aria-label liefert den Buttons einen Namen für den Screenreader, während das sichtbare Zeichen das visuelle Design trägt. Das <label for="Quantity"> verbindet die Beschriftung mit dem Eingabefeld, sodass das Anklicken des Worts "Menge" den Fokus in das Feld setzt und der Screenreader das Feld korrekt benennt (WCAG 4.1.2).
Jedes informative Produktbild braucht einen Alternativtext, der den Bildinhalt beschreibt (WCAG 1.1.1). In Shopify pflegen Sie diesen Text im Admin direkt am Medium, und das Theme gibt ihn über image.alt aus:
<img
src="{{ image | image_url: width: 800 }}"
alt="{{ image.alt | escape }}"
width="800"
height="800"
loading="lazy">
Ist im Admin kein Alt-Text gepflegt, bleibt das Attribut leer. Das ist nur bei rein dekorativen Bildern korrekt; bei einem aussagekräftigen Produktbild ist es ein Verstoß. Pflegen Sie den Alt-Text deshalb für jedes Produktmedium im Admin unter "Produkte > Medien". Beschreiben Sie, was zu sehen ist, ohne den Dateinamen oder Wiederholungen des Produkttitels.
Die Galerie selbst muss tastaturbedienbar sein (WCAG 2.1.1). Wenn Thumbnails das Hauptbild wechseln, müssen sie echte Bedienelemente sein, also <button>-Elemente, die per Tabulator erreichbar und per Eingabe- oder Leertaste auslösbar sind. Eine Zoom- oder Lightbox-Funktion folgt der Modal-Logik: Beim Öffnen wandert der Fokus in das Overlay, die Escape-Taste schließt es, und der Fokus kehrt anschließend zum auslösenden Thumbnail zurück. Eine Galerie, die sich nur per Maus-Hover oder nur per Wischgeste bedienen lässt, schließt Tastaturnutzer aus.
Die zentrale Aktion der Seite muss ein echter Button sein, kein gestyltes <div> und kein nackter Link mit JavaScript. Ein <button type="submit"> ist von Haus aus fokussierbar, per Tastatur auslösbar und trägt seinen sichtbaren Text als zugänglichen Namen:
<button type="submit" name="add" class="product-form__submit">
In den Warenkorb
</button>
Achten Sie auf den ausverkauften Zustand. Wird der Button bei nicht verfügbaren Varianten deaktiviert, sollte das disabled-Attribut gesetzt sein und der sichtbare Text die Lage benennen, etwa "Ausverkauft". Ein nur ausgegrauter, aber technisch weiterhin auslösbarer Button verwirrt alle Nutzer, besonders aber jene mit Screenreader, weil der angekündigte Zustand nicht zur tatsächlichen Funktion passt (WCAG 4.1.2).
Dieser Schritt wird am häufigsten übersehen. Wenn ein Produkt in den Warenkorb gelegt wird, erscheint oft eine Bestätigung, etwa ein kurzer Hinweis "Zum Warenkorb hinzugefügt" oder das Aufklappen des Warenkorb-Drawers. Für sehende Nutzer ist das offensichtlich. Ein Screenreader-Nutzer, dessen Fokus auf dem Button bleibt, bemerkt diese Änderung jedoch nicht, weil sie ohne Fokuswechsel an einer anderen Stelle der Seite passiert.
WCAG 4.1.3 (Status Messages, Stufe AA) verlangt, dass solche Statusänderungen angekündigt werden, ohne dass der Fokus dorthin wandern muss. Das gelingt mit einem Live-Bereich, also einem Element mit aria-live, dessen Inhalt der Screenreader bei jeder Änderung automatisch vorliest:
<div id="cart-status" role="status" aria-live="polite" class="visually-hidden"></div>
Das begleitende JavaScript schreibt nach dem erfolgreichen Hinzufügen den Bestätigungstext in dieses Element:
document.getElementById('cart-status').textContent =
'Produkt wurde in den Warenkorb gelegt.';
Der Bereich kann visuell versteckt sein (visually-hidden), die Meldung wird dennoch vorgelesen. Wichtig: Das Element muss bereits beim Laden der Seite im DOM vorhanden sein und leer bleiben, bis die Aktion eintritt. Wird es erst beim Hinzufügen neu erzeugt, kündigen viele Screenreader die Meldung nicht zuverlässig an.
Zusatzinformationen wie Versanddetails, Materialangaben oder Pflegehinweise stecken oft in Akkordeons oder Tabs. Ein Akkordeon lässt sich barrierefrei und ohne eigenes JavaScript mit den nativen HTML-Elementen <details> und <summary> umsetzen. Diese sind von Haus aus tastaturbedienbar und melden ihren Auf- und Zuklapp-Zustand:
<details class="product__accordion">
<summary>Versand und Rückgabe</summary>
<div class="product__accordion-content">
{{ block.settings.content }}
</div>
</details>
Wenn Ihr Theme stattdessen ein eigenes Akkordeon mit <button> und aria-expanded nutzt, ist das ebenfalls korrekt, solange der Button echtes Bedienelement ist und sein Zustand über aria-expanded="true" beziehungsweise false gemeldet wird.
Bewertungen stammen häufig aus einer App und liegen damit außerhalb des Theme-Codes. Prüfen Sie sie trotzdem, denn die Verantwortung nach § 8 BFSG bleibt beim Händler. Achten Sie auf zwei Punkte: Eine Sternebewertung darf nicht nur als Bild ohne Textersatz vorliegen, sondern braucht eine Textangabe wie "4 von 5 Sternen". Und die Steuerung zum Aufklappen weiterer Bewertungen muss ein tastaturbedienbarer Button sein.
Ein Teil dieser Punkte lässt sich automatisiert prüfen, ein anderer nur manuell. Fehlende Alt-Texte und fehlende Namen findet ein automatisiertes Werkzeug zuverlässig. Ob die Variantenauswahl per Tastatur sinnvoll bedienbar ist und ob die Statusmeldung tatsächlich vorgelesen wird, zeigt nur ein manueller Test.
| Werkzeug |
Zweck |
Kosten |
| Manueller Tastaturtest |
Variantenauswahl, Galerie, Button-Bedienung |
kostenlos |
| axe DevTools |
Erkennt fehlende Namen, Alt-Texte, ARIA-Probleme |
kostenlose Variante |
| WAVE Browser Extension |
Visuelle Markierung von Verstößen |
kostenlos |
| NVDA Screenreader |
Prüfung von Überschriften und Statusmeldungen |
kostenlos |
| AccessifyAI |
Shopify-spezifische Prüfung mit Liquid-Korrekturvorschlägen |
Free-Tier, ab 9,99 USD/Monat |
Welche dieser Probleme in Ihrer konkreten Produktseite stecken, zeigt nur ein echter Test auf Ihrer aktuellen Theme-Version und im installierten Zustand mit allen aktiven Apps. Ich habe AccessifyAI entwickelt, weil allgemeine Werkzeuge zwar einen Verstoß melden, aber nicht sagen, in welcher Liquid-Datei oder welchem Section-Snippet die Korrektur erfolgen muss. AccessifyAI ordnet den Befund dem Shopify-Code-Modell zu und gibt statt eines Overlays einen Korrekturvorschlag als Liquid-Diff aus, den Sie vor der Übernahme begutachten können. Wenn Sie zunächst nur sehen wollen, wie es um Ihre Produktseite steht, können Sie ohne Installation den kostenlosen On-Page-Scanner auf accessify.ensomedia.pl nutzen. Die App selbst finden Sie im Shopify App Store.
- Prüfen Sie die Überschriftenstruktur einer Produktseite: ein einziges
<h1> mit dem Produktnamen, danach lückenlose <h2>/<h3>.
- Bedienen Sie die Variantenauswahl ausschließlich per Tastatur. Hört der Screenreader Optionsname und Wert?
- Prüfen Sie das Mengenfeld auf Label und benannte Plus-/Minus-Buttons.
- Pflegen Sie für jedes informative Produktbild einen Alt-Text im Admin und testen Sie die Galerie per Tastatur.
- Stellen Sie sicher, dass der In-den-Warenkorb-Button ein echter Button ist und seinen ausverkauften Zustand korrekt meldet.
- Ergänzen Sie eine Statusmeldung über
aria-live, falls nach dem Hinzufügen keine vorgelesen wird.
- Wiederholen Sie die Prüfung nach jedem Theme-Update und jeder neuen App, da beide neue Barrieren einführen können.
Weitere fachliche Vertiefung finden Sie in unserem Beitrag zur Tastaturbedienung im Shopify-Store und in der BFSG-Pflichtcheckliste mit 14 Punkten.
Ja, das ist die saubere und erwartbare Struktur. WCAG 1.3.1 (Info and Relationships, Stufe A) verlangt, dass die Struktur einer Seite im Code erkennbar ist. Auf einer Produktseite ist der Produktname die zentrale Hauptüberschrift und gehört als einziges <h1> ausgezeichnet. Weitere Abschnitte folgen lückenlos als <h2> und <h3>.
Sie können barrierefrei sein, scheitern aber oft an drei Punkten: keine Tastaturbedienung, kein im Code hinterlegter Auswahlzustand und kein Textname für die Farbe. Setzen Sie Swatches als native Radio-Gruppe in einem <fieldset> mit <legend> um, dann sind Tastaturbedienung (WCAG 2.1.1) und korrekter Name und Zustand (WCAG 4.1.2) von Haus aus erfüllt.
Ein Platzhalter verschwindet, sobald der Nutzer tippt, und wird von einigen Screenreadern nicht als Beschriftung gewertet. WCAG 4.1.2 verlangt einen verlässlichen Namen für das Bedienelement. Ein verbundenes <label for="Quantity"> erfüllt das, ein bloßer Platzhalter nicht.
Eine Statusmeldung ist eine Rückmeldung über eine Zustandsänderung, etwa "Zum Warenkorb hinzugefügt", die nicht den Tastaturfokus übernimmt. WCAG 4.1.3 (Status Messages, Stufe AA) verlangt, dass solche Änderungen auch Screenreader-Nutzern angekündigt werden. Ein Live-Bereich mit aria-live="polite" oder role="status" liest die Meldung vor, ohne den Fokus zu verschieben.
Ja. Auch wenn die Bewertungsfunktion aus einer Drittanbieter-App stammt, bleibt die rechtliche Verantwortung nach § 8 BFSG beim Händler. Prüfen Sie Sternebewertungen auf einen Textersatz und die Steuerelemente auf Tastaturbedienbarkeit, im installierten Zustand mit aktiver App.
Nein. Eine barrierefreie Produktseite ist ein wichtiger Baustein, aber das BFSG gilt für die gesamte Dienstleistung, also auch für Startseite, Navigation, Suche, Warenkorb und Checkout. Kein Werkzeug, auch AccessifyAI nicht, kann Rechtskonformität garantieren. Werkzeuge helfen beim Finden und Beheben von Verstößen, die Verantwortung trägt nach § 8 BFSG der Händler.
Eine barrierefreie Produktseite in Shopify entsteht aus sieben Bausteinen: einer sauberen Überschriftenhierarchie mit genau einem <h1> (WCAG 1.3.1), einer tastaturbedienbaren und beschrifteten Variantenauswahl (WCAG 2.1.1, 4.1.2), einem Mengenfeld mit Label und benannten Buttons (WCAG 4.1.2), Produktbildern mit Alt-Texten und einer tastaturbedienbaren Galerie (WCAG 1.1.1, 2.1.1), einem echten In-den-Warenkorb-Button mit korrektem Zustand (WCAG 2.1.1, 4.1.2), einer Statusmeldung über aria-live nach dem Hinzufügen (WCAG 4.1.3) sowie barrierefreien Akkordeons, Tabs und Bewertungen. Alle fünf Kernkriterien sind über EN 301 549 v3.2.1 nach dem BFSG verbindlich. Prüfen Sie jeden Baustein im installierten Zustand auf der aktuell ausgespielten Theme-Version und wiederholen Sie die Prüfung nach jedem Theme-Update und jeder neuen App.