Key Takeaways
- Sechs Fehler sind für die absolute Mehrheit der Accessibility-Probleme im Web verantwortlich, und jeder einzelne davon kommt auch in Shopify-Stores vor.
- Alle sechs sind maschinell erkennbar, sodass ein kostenloser Scanner sie in wenigen Minuten findet. Jeder hat ein spezifisches WCAG-Erfolgskriterium und einen spezifischen Fix im nativen Code.
- Der Fix ist immer eine Änderung an deinem Theme-Code oder einem Admin-Feld, kein Widget, das einfach darübergelegt wird. Overlays lassen den zugrundeliegenden Fehler bestehen.
- Automatisierte Scanner erkennen diese sechs, weil sie eindeutig sind. Das deckt aber nur etwa ein Drittel der WCAG ab, weshalb ein manueller Test mit Tastatur und Screenreader immer noch wichtig ist.
Die Shopify-Accessibility zu verbessern, fängt nicht damit an, die kompletten WCAG-Richtlinien auswendig zu lernen. Es beginnt mit sechs spezifischen Fehlern. Die jährliche WebAIM Million-Studie der Top-1-Million-Startseiten findet jedes Jahr dieselben sechs Probleme ganz oben auf der Liste, und zusammen machen sie den Großteil aller gefundenen Fehler aus.1
Dieser Guide geht sie der Reihe nach durch: was es ist, welches WCAG-Erfolgskriterium verletzt wird, wie es spezifisch in einem Shopify-Theme auftritt und wie der genaue Fix im nativen Code oder im Admin-Bereich aussieht. Das sind echte Quick Wins, weil sie so häufig und eindeutig sind.
Warum du uns vertrauen kannst
Jacques hat über 15 Jahre Entwicklererfahrung und hat schon vielen Shopify-Brands geholfen, barrierefreie, schnelle Storefronts zu launchen. Wir sind seit über vier Jahren im Shopify-Ökosystem unterwegs und haben Fudge entwickelt – einen KI-Store-Builder und Editor mit einer 4.8-Bewertung im Shopify App Store, der Accessibility-Probleme direkt im nativen Theme-Code behebt. Mehr zu den rechtlichen Grundlagen und Standards hinter dieser Arbeit findest du in unserem ausführlichen Guide zur Shopify ADA- und WCAG-Compliance.
Die sechs häufigsten Fehler auf einen Blick
Der WebAIM Million-Bericht vom Februar 2026 fand erkennbare WCAG-Fehler auf 95,9 % der Startseiten, mit durchschnittlich 56,1 Fehlern pro Seite.1 Fast alle dieser Fehler fallen in diese sechs Kategorien, und die Liste hat sich in sieben Jahren kaum verändert.
| Fehler | Betroffene Startseiten | WCAG-Erfolgskriterium | Typische Shopify-Ursache |
|---|---|---|---|
| Kontrastarmer Text | 83,9 % | 1.4.3 Kontrast (Minimum) | Markenfarben für Fließ- oder Button-Text |
| Fehlender Alt-Text | 53,1 % | 1.1.1 Nicht-Text-Inhalt | Produkt- und Abschnittsbilder ohne Alt-Text |
| Fehlende Formular-Labels | 51,0 % | 3.3.2, 4.1.2 | Such-, Newsletter- und Kontaktfelder |
| Leere Links | 46,3 % | 2.4.4, 4.1.2 | Icon-only Links (Warenkorb, Social, Logo) |
| Leere Buttons | 30,6 % | 4.1.2 Name, Rolle, Wert | Icon-only Buttons (Menü-Toggle, Drawer close) |
| Fehlende Dokumentsprache | 13,5 % | 3.1.1 Sprache der Seite | Benutzerdefinierte/bearbeitete theme.liquid |
Die Prozentzahlen sind der Anteil der Top-Eine-Million-Startseiten, auf denen WebAIM im Februar 2026 den jeweiligen Fehler entdeckt hat.1 Arbeite diese Liste ab und du minimierst dein Risiko enorm. Für die vollständigen Kriterien jenseits dieser sechs, schau dir unsere WCAG 2.2 AA-Checkliste für Shopify an.
1. Kontrastarmer Text
Was es ist: Text, der sich zu schwach vom Hintergrund abhebt, um angenehm lesbar zu sein. Das ist der mit Abstand häufigste Fehler im Web, der auf der großen Mehrheit aller Seiten zu finden ist.
Warum es die WCAG nicht erfüllt: Das Erfolgskriterium 1.4.3 Kontrast (Minimum) erfordert ein Kontrastverhältnis von mindestens 4,5:1 für normalen Text und 3:1 für großen Text (etwa ab 18px fett oder 24px normal). Grauer Fließtext auf weißem Grund oder blasser Text auf einem Button in Markenfarbe sind die üblichen Übeltäter.
Wie es in Shopify auftritt: Themes bieten im Theme-Editor eine Farbauswahl als Farbschemata an. Eine Markenpalette, die eher nach Optik als nach Kontrast ausgewählt wurde, fließt sofort in Fließtext, Buttons, Sale-Badges und Platzhaltertexte über alle Templates hinweg ein. Eine gedämpfte graue Bildunterschrift oder ein helles, pastellfarbenes „In den Warenkorb“-Label können leicht deutlich unter 4,5:1 fallen, ohne direkt fehlerhaft auszusehen.
Die Lösung: Passe die Color-Tokens an, nicht einzelne Elemente. Öffne im Theme-Editor Theme-Einstellungen > Farben und erhöhe den Kontrast der Text- und Button-Farben jedes Schemas, bis sie den Test bestehen. Wenn du den Code direkt bearbeitest, stehen diese Werte in den CSS-Custom-Properties des Themes. In einem Dawn-basierten Theme sieht das so aus:
.color-scheme-1 {
--color-foreground: 18, 18, 18; /* dunkle den Text ab, bis Text-auf-Hintergrund 4,5:1 erreicht */
--color-background: 255, 255, 255;
}Prüfe jedes Paar mit einem Kontrast-Tool, wie dem in den Chrome DevTools integrierten oder dem WebAIM Contrast Checker. Denke daran, den Button-Text gegen die Button-Hintergrundfarbe zu testen, nicht gegen den Seitenhintergrund. Die Korrektur des Tokens repariert den Kontrast überall dort, wo das Schema verwendet wird.
2. Fehlender Alt-Text bei Bildern
Was es ist. Ein Bild ohne Textalternative, sodass ein Screenreader entweder gar nichts Nützliches meldet oder einfach den Dateinamen buchstabiert.
Warum es bei der WCAG durchfällt. Das Erfolgskriterium 1.1.1 Non-text Content erfordert eine Textalternative für Bilder, die Informationen vermitteln. Produktfotos, Info-Banner und Content-Bilder benötigen alle einen Alt-Text. Rein dekorative Bilder benötigen genau das Gegenteil: ein leeres alt="", damit assistive Technologien sie überspringen.
Wie es in Shopify auftritt. Es gibt zwei verschiedene Stellen, an denen Alt-Text fehlen kann:
- Produkt- und Variantenbilder enthalten Alt-Text, der im Adminbereich festgelegt wurde. Öffne ein Produkt, wähle ein Medium aus und klicke in den Details auf Alt-Text hinzufügen (Add alt text). Bulk-Uploads enthalten in diesem Feld von Haus aus fast immer gähnende Leere.
- Section- und Theme-Bilder (Slideshow-Slides, Image-Banner, Promo-Kacheln) werden über den Theme-Editor hinzugefügt. Dort hat jede
image_picker-Einstellung ein eigenes Alt-Text-Feld, das allzu leicht vergessen wird.
Der Fix. Setze den Alt-Text für jedes aussagekräftige Bild an seiner Quelle und stelle sicher, dass das Theme ihn auch tatsächlich rendert. Ein Theme sollte den gespeicherten Wert wie folgt ausgeben:
{{ product.featured_image | image_url: width: 800 | image_tag: alt: product.featured_image.alt }}Für ein rein dekoratives Bild ohne Informationswert solltest du ein explizites, leeres Alt-Attribut angeben, damit Screenreader es ignorieren:
<img src="{{ 'divider.svg' | asset_url }}" alt="" role="presentation" width="1200" height="8">Schreibe einen Alt-Text, der beschreibt, was das Bild zeigt, warum es dort platziert ist, und halte ihn prägnant.
3. Fehlende Formular-Labels
Was es ist. Ein Input-Feld, das ein Screenreader nicht benennen kann, da es kein programmatisch verknüpftes Label hat. Ein sichtbarer Platzhalter (Placeholder) ist kein Label. Er verschwindet bei Eingabe und wird von vielen Screenreadern ohnehin ignoriert.
Warum es bei der WCAG durchfällt. Hier greifen zwei Kriterien. 3.3.2 Labels or Instructions verlangt, dass Eingabefelder Labels haben, und 4.1.2 Name, Role, Value erfordert, dass jedes Bedienelement einen barrierefreien Namen (Accessible Name) für assistive Technologien bereitstellt.
Wie es in Shopify auftritt. Die üblichen Verdächtigen sind das Suchfeld, die Newsletter-Anmeldung und Kontaktformulare. Viele Themes stylen diese mit einem sehr cleanen Look und nutzen nur Platzhalter:
<input type="email" name="contact[email]" placeholder="Email address">Das rendert komplett ohne Accessible Name.
Der Fix. Verknüpfe ein echtes <label> mit dem Input, indem das for mit der Input-id übereinstimmt. Wenn das Design kein sichtbares Label haben darf, behalte das Label trotzdem im DOM und verstecke es mittels der visually-hidden-Klasse des Themes, anstatt es zu löschen:
<label for="NewsletterEmail" class="visually-hidden">E-Mail-Adresse</label>
<input
type="email"
id="NewsletterEmail"
name="contact[email]"
placeholder="E-Mail-Adresse"
autocomplete="email"
>Dawn und die meisten “Online Store 2.0”-Themes bringen von Hause aus eine visually-hidden-Klasse mit. So bleibt das Label für Screenreader lesbar, optisch ist es aber ausgeblendet. Ein aria-label direkt am Formularfeld ist ein sinnvoller Fallback, falls du absolut kein <label>-Element einfügen kannst.
4. Leere Links
Was es ist. Ein Link, den der Screenreader einfach nur als “Link” ankündigt, völlig ohne Zieltext, weil sein einziger Inhalt ein Icon oder ein Bild ohne Textalternative (Alt-Text) ist.
Warum es bei der WCAG durchfällt. 2.4.4 Link Purpose (In Context) erfordert, dass sich der Zweck eines Links aus dem Text ableiten lässt, und 4.1.2 Name, Role, Value benötigt einen Accessible Name. Ein reiner Icon-Link (Icon-only-Link) erfüllt beides nicht.
Wie es in Shopify auftritt. Header und Footer sind voll davon: der Warenkorb-Link, der als Tasche dargestellt wird, Social Icons im Footer, der Logo-Link, um den ein SVG gewickelt ist, und reine Chevron-Icons (Pfeile) in der Pagination. Das Markup sieht oft in etwa so aus:
<a href="{{ routes.cart_url }}">
{% render 'icon-cart' %}
</a>Das SVG hat keinen Text, also hat der Link keinen Namen.
Der Fix. Gib dem Link einen Text, den ein Screenreader lesen kann. Die sauberste Lösung ist ein visuell versteckter Text (Visually Hidden Form) im Link. Praktischerweise lässt sich dort auch gleich der aktuelle Zähler integrieren:
<a href="{{ routes.cart_url }}">
{% render 'icon-cart' %}
<span class="visually-hidden">Warenkorb, {{ cart.item_count }} Artikel</span>
</a>Ein aria-label auf dem <a>-Tag funktioniert ebenfalls. Bei Links für Social Icons solltest du besser den Netzwerknamen vergeben (“Instagram”, “TikTok”), anstatt nur “Social Link” zu schreiben.
5. Leere Buttons
Was es ist. Ein <button> ohne erkennbaren Text, quasi der interaktive Zwilling des leeren Links. Mit der Maus funktioniert er zwar, liefert aber für Assistive Technologien keinerlei Info.
Warum es bei der WCAG durchfällt. 4.1.2 Name, Role, Value verlangt für jedes Control einen Accessible Name. Ein reiner Icon-Button, bei dem der Screenreader schlicht “Button” meldet, fällt durch, weil der User nicht erahnen kann, was er damit bewirkt.
Wie es in Shopify auftritt. Icon-Only-Elemente sind in modernen Themes leider allgegenwärtig: der Mobile-Menu-Toggle (Hamburger), der Close-Button für den Cart Drawer (×), die Plus- und Minus-Buttons bei der Stückzahl sowie die Buttons zum Öffnen und Schließen der Predictive Search. So sieht ein typischer Menu-Toggle aus:
<button type="button" class="header__icon" aria-expanded="false">
{% render 'icon-hamburger' %}
</button>Der Fix. Füge ein aria-label hinzu, das die Aktion definiert, oder setze visuell verborgenen Text direkt in den Button:
<button type="button" class="header__icon" aria-expanded="false" aria-label="Menü öffnen">
{% render 'icon-hamburger' %}
</button>Für einen Toggle, wie das Menü oder den Cart-Drawer, solltest du das Label zudem mit aria-expanded kombinieren. Halte dieses Attribut in deinem Theme-JavaScript mit dem jeweiligen Öffnungsstatus synchron. Dann wissen auch Screenreader-User immer, ob die Seitenleiste ausgeklappt ist. Ein Close-Button sollte entsprechend auch “Schließen” heißen und eine Mengensteuerung “Menge erhöhen” oder “Menge verringern”.
6. Fehlende Dokumentsprache
Was es ist. Eine aufgerufene Seite ohne lang-Attribut in ihrem <html>-Element – assistive Technologien wissen in der Konsequenz nicht, in welcher Sprache sie den Inhalt vorlesen sollen.
Warum es bei der WCAG durchfällt. 3.1.1 Language of Page verlangt, dass die hauptsächliche menschliche Sprache jeder Seite an dieser Stelle programmgesteuert festgelegt wird. Fehlt das Attribut, greifen Screenreader sehr wahrscheinlich auf falsche Aussprache-Regeln für die komplette Seite zurück.
Wie es in Shopify auftritt. Dieser Fehler spielt sich meist in einer einzigen Datei ab: theme.liquid, das Basis-Layout aller Seiten. Ein gut gemachtes Theme greift auf das Storefront-Lokalisierungsobjekt (Locale) zurück. Eigens programmierte Builds, Custom Themes oder stark bearbeitete Themes haben den Wert manchmal starr im Code verankert (Hardcoded) oder nach einem Redesign aus Versehen völlig weggelassen.
Der Fix. Setze lang dynamisch über das Request Locale, sodass es auf jedem Markt und über jede übersetzte Storefront hinweg die richtige Sprache zuweist. Öffne layout/theme.liquid und bestätige, ob das HTML-Eröffnungs-Tag wie folgt aussieht:
<!doctype html>
<html
class="no-js"
lang="{{ request.locale.iso_code }}"
dir="{{ request.locale.iso_code | default: 'en' }}"
>Wenn du {{ request.locale.iso_code }} statt eines stumpfen "de" oder "en" verwendest, servieren mehrsprachige Shops und Shopify Markets den Besuchern stets automatisch den exakten Language Code. Ein Einzeiler, der diesen WCAG-Fehler auf jeden Fall über die gesamte Breite abstellt.
Warum Scanner diese sechs Fehler finden und was sie übersehen
Alle sechs Fehler haben eine Eigenschaft gemeinsam: Sie sind maschinell überprüfbar. Ein Tool kann nachweisen, dass ein Bildelement kein alt-Attribut hat, das Kontrastverhältnis unter 4,5:1 liegt oder ein <button> keinen Text enthält. Deshalb erkennt ein kostenloser, automatisierter Scanner wie axe DevTools, WAVE oder Lighthouse sie in Sekundenschnelle, und deshalb dominieren sie die Daten der WebAIM Million. WebAIM misst mit automatisierten Tools, also sind die sechs häufigsten Ergebnisse schlicht die sechs, die sich am leichtesten erkennen lassen.
Der Haken an der Sache ist, dass die automatisierte Prüfung nur einen Teil der WCAG abdeckt. Unabhängige Tests zeigen immer wieder, dass die automatisierte Abdeckung bei etwa 30 bis 40 % der Erfolgskriterien liegt. Der Rest erfordert menschliches Urteilsvermögen: ob ein Alt-Text wirklich sinnvoll ist, ob die Reihenfolge des Tastaturfokus logisch ist, ob jemand mit einem Screenreader den Checkout abschließen kann oder ob eine Fehlermeldung verständlich erklärt, wie man ein Problem löst.
Betrachte diese sechs Fehler also als Basis und nicht als Endziel. Nachdem du sie behoben hast, solltest du einen manuellen Testdurchlauf machen:
- Navigiere den kompletten Weg von der Produktseite bis zum erfolgreichen Checkout ausschließlich mit der Tastatur (Tab, Shift+Tab, Enter). Stelle sicher, dass du jedes Bedienelement erreichen und benutzen kannst.
- Aktiviere einen Screenreader (VoiceOver auf dem Mac, das kostenlose NVDA unter Windows) und versuche, etwas zu kaufen.
- Zoome auf 200 % und prüfe, ob nichts abgeschnitten wird oder sich überlappt.
Unser Guide zur Durchführung eines Website-Accessibility-Audits erklärt diesen manuellen Teil im Detail und zeigt dir, wie du Testseiten auswählst und deine Ergebnisse dokumentierst.
Das ist auch der Grund, warum Accessibility-Overlays einen Shop nicht richtlinienkonform machen: Ein beim Laden der Seite nachträglich eingebundenes Skript kann das menschliche Urteilsvermögen für die manuelle Prüfung nicht ersetzen – und es belässt die sechs grundlegenden Fehler weiterhin im Code. Wenn du dir noch unsicher bist, ob die Plattform dich ausreichend absichert, lies unseren Beitrag Ist Shopify ADA-konform?
Die Top 6 fixen und im nativen Code überwachen
Jedwede zuvor vorgestellte Code-Änderung passiert direkt im Liquid deines Theme-Codes oder via Admin-Panel. Letzteres ist auch wirklich beabsichtigt so. Denn eine richtige Quellcode-Änderung ist genau der Weg, den gute Entwickler ausliefern, wovon ein Screenreader sofort ohne Flaschenhals profitiert und was auch im Worst Case eines erhaltenen anwaltlichen Demand Letters vor Gericht rechtssicher standhält.
Hier helfen AI Store Builder enorm. Fudge checkt den Puls deines bestehenden Themes, kramt exakt diese Mängel aus Liquid-, CSS- und Javascript-Strukturen heraus, fixt sie kompromisslos am Ursprung und sichert das Ergebnis nachhaltig gegen Regressionen ab – so zieht eine simple Inhaltsänderung oder eine blinde Drittanbieter-App die mühsam gewonnenen Pluspunkte bei der Barrierefreiheit nicht unvermittelt wieder ins Minus. Das Resultat ist echter nativer Code, also wird dein Seiten-Speed nicht einmal im Promillebereich angekratzt. Ein Vorgehen, das super für Synergien auf anderen Ebenen passt, etwa wenn du strukturierte Daten in Shopify hinzufügen möchtest oder generelles Store-Editing priorisierst.
Bringe die Fixes für die Top-6-Fehler unter, absolviere einen sauberen Manual Pass – und dann ist im Nu das meiste Accessibility-Risiko aus deinem gängigen Store genau dort wegoperiert worden, wo es überhaupt reingekommen ist.
FAQ
Kontrastarmer Text, fehlender Bild-Alt-Text, fehlende Formular-Labels, leere Links, leere Buttons und ein fehlendes Attribut für die Dokumentsprache. Die WebAIM Million-Studie findet jedes Jahr dieselben sechs Fehler ganz oben, und sie alle kommen häufig in Shopify-Themes vor und lassen sich im nativen Code beheben.
Nein. Kostenlose Tools wie axe DevTools, WAVE und Lighthouse erkennen die sechs häufigsten Fehler zuverlässig, weil sie maschinell entscheidbar sind. Die automatisierte Erkennung deckt jedoch nur etwa 30 bis 40 % der WCAG ab. Ein manueller Tastatur- und Screenreader-Test bis zum Checkout ist weiterhin nötig.
Öffne das Produkt im Adminbereich, wähle ein Medienelement aus und nutze das Feld 'Alt-Text hinzufügen' in der Medien-Detailansicht. Stelle dann sicher, dass dein Theme den gespeicherten Wert rendert, zum Beispiel mit dem image_tag-Filter und der Übergabe von alt: image.alt. Verwende ein leeres alt-Attribut für rein dekorative Bilder.
Bearbeite die layout/theme.liquid und setze das öffnende html-Tag auf lang="{{ request.locale.iso_code }}". Die Nutzung der Request-Locale anstelle eines hartcodierten Wertes hält den Sprachcode über Shopify Markets und übersetzte Storefronts hinweg korrekt und löst WCAG 3.1.1 auf jeder Seite sofort auf einmal.
Ein Placeholder verschwindet, sobald der Nutzer zu tippen beginnt, und viele Screenreader behandeln ihn nicht als Label. Dadurch fällt das Feld bei WCAG 3.3.2 und 4.1.2 durch. Füge ein echtes label-Element hinzu, das über for und id verknüpft ist, und verstecke es mit der visually-hidden-Klasse des Themes, falls es nicht sichtbar sein soll.
Gib ihm einen Accessible Name (zugänglichen Namen). Füge ein aria-label zum Button oder Link hinzu, oder platziere visuell versteckten Text darin, wie "Menü öffnen" oder "Warenkorb, 3 Artikel". Bei Toggles solltest du aria-expanded mit dem Öffnungsstatus synchron halten, damit Screenreader-Nutzer den Status des Panels kennen.
Footnotes
-
WebAIM Million, Bericht vom Februar 2026: 95,9 % der Top 1.000.000 Startseiten hatten erkennbare WCAG-Fehler, mit durchschnittlich 56,1 Fehlern pro Seite. Häufigste Fehler nach Anteil der Seiten: Kontrastarmer Text 83,9 %, fehlender Alternativtext 53,1 %, fehlende Formular-Labels 51,0 %, leere Links 46,3 %, leere Buttons 30,6 %, fehlende Dokumentsprache 13,5 %, webaim.org/projects/million. ↩ ↩2 ↩3
