Behebe die 6 häufigsten Accessibility-Fehler in deinem Shopify-Theme

Wichtigste Erkenntnisse

• Sechs Fehler sind für die überwältigende Mehrheit der Barrierefreiheits-Fehler im Web verantwortlich, und jeder davon taucht in Shopify-Stores auf.
• Alle sechs sind maschinell erkennbar (machine-detectable), weshalb ein kostenloser Scanner sie in Minuten findet. Jeder hat ein spezifisches WCAG-Erfolgskriterium (success criterion) und einen spezifischen Fix im Native-Code.
• Der Fix besteht immer in einer Änderung an deinem Theme-Code oder einem Admin-Feld, nicht in einem darübergelegten Widget. Overlays lassen den zugrundeliegenden Fehler bestehen.
• Automatisierte Scanner erfassen diese sechs, weil sie eindeutig sind, aber das ist nur etwa ein Drittel der WCAG. Ein manueller Durchlauf mit Tastatur und Screenreader bleibt also wichtig.

Die Verbesserung deiner Shopify Accessibility beginnt nicht damit, die gesamte WCAG auswendig zu lernen. Sie beginnt mit sechs spezifischen Fehlern. Die jährliche WebAIM Million-Studie der Top-Prozent der einer Million Homepages findet jedes Jahr dieselben sechs Probleme ganz oben auf der Liste, und zusammen machen sie den Großteil aller erkannten Fehler aus.¹

Dieser Guide nimmt sich jeden einzelnen vor: was es ist, welches WCAG-Kriterium er bricht, wie er speziell in einem Shopify-Theme auftritt und den genauen Fix im nativen Code oder im Admin-Bereich. Das sind die schnellsten “Wins”, weil sie so häufig und eindeutig sind.

Warum du uns vertrauen kannst

Jacques hat über 15 Jahre Entwicklungs-Erfahrung und hat bereits vielen Shopify-Brands geholfen, schnelle und barrierefreie Storefronts bereitzustellen. Wir sind seit über vier Jahren im Shopify-Bereich tätig und haben Fudge entwickelt, einen AI Store Builder und Editor mit einer 5,0-Bewertung im Shopify App Store, der Barrierefreiheits-Fehler direkt im nativen Theme-Code behebt. Für den rechtlichen und standardisierten Hintergrund dieser Arbeit, schau dir unseren ausführlicheren Guide zur Shopify ADA- und WCAG-Compliance an.

Die sechs häufigsten Fehler auf einen Blick

Der WebAIM Million-Bericht vom Februar 2026 fand erkennbare WCAG-Fehler auf 95,9 % der Homepages, mit durchschnittlich 56,1 Fehlern pro Seite.¹ Auf diese sechs Kategorien entfallen fast all diese Fehler, und die Liste hat sich in sieben Jahren kaum verändert.

Die Prozentzahlen entsprechen dem Anteil der Top-Million-Homepages, bei denen WebAIM im Februar 2026 den jeweiligen Fehler festgestellt hat.¹ Arbeite die Liste ab, und du entfernst den Großteil deines Risikos. Die vollständigen Kriterien über diese sechs hinaus findest du in unserer WCAG 2.2 AA-Checkliste für Shopify.

1. Kontrastarmer Text

Was es ist. Text, der sich zu wenig vom Hintergrund abhebt, um angenehm lesbar zu sein. Das ist der häufigste Fehler im Web überhaupt und ist auf den allermeisten Seiten zu finden.

Warum es bei der WCAG durchfällt. Das Erfolgskriterium 1.4.3 Contrast (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 bold oder 24px regular). Grau-auf-weißem Fließtext (Body Copy) und blasser Text auf einem Button in Markenfarbe sind die üblichen Verdächtigen.

Wie es in Shopify auftritt. Themes bieten Farbauswahlen als Color Schemes (Farbschemata) im Theme-Editor an. Eine Markenpalette, die eher nach Optik als nach Kontrast ausgewählt wurde, fließt global in Body-Text, Buttons, Sale-Badges und Platzhaltertexte in allen Templates ein. Eine gedämpft graue Bildunterschrift (Caption) oder ein helles Pastell-Label “In den Warenkorb” kann leicht unter 4,5:1 fallen, ohne sofort fehlerhaft auszusehen.

Der Fix. Passe die Color Tokens an, nicht die einzelnen Elemente. Öffne im Theme-Editor Theme Settings > Colors und erhöhe den Kontrast für Text und Buttons in jedem Schema, bis die Werte passen. Wenn du den Code direkt bearbeitest, befinden sich die 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; /* Text abdunkeln, bis das Text-Hintergrund-Verhältnis 4,5:1 erreicht */
  --color-background: 255, 255, 255;
}

Prüfe jede Kombination mit einem Kontrast-Tool wie dem integrierten Checker in den Chrome DevTools oder von WebAIM. Denke daran, den Button-Text gegen die Füllfarbe des Buttons zu testen, nicht gegen den Seitenhintergrund. Wenn du den Token anpasst, wird der Kontrast überall behoben, 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 teilen eine Eigenschaft: sie sind für eine Maschine eindeutig abgrenzbar (machine-decidable). Ein Tool kann unhinterfragt beweisen, ob ein Bildelement kein alt-Attribut hat, ob ein Kontrast unter das 4,5:1-Minimum rutscht oder ob ein <button> keinen verknüpften Text mitführt. Aus diesem Grund fangen kostenlose automatisierte Scanner wie axe DevTools, WAVE oder Lighthouse diese Problemchen binnen weniger Sekunden ein und dominieren dementsprechend auch die Daten der WebAIM Million-Studie. WebAIM nutzt hierbei schließlich genau solche Tools, so sind die häufigsten Resultate auch die am ehesten erkennbaren Fehler.

Der einzige Haken dabei: Die automatisierte Erkennung deckt nur einen kleinen Teil der WCAG ab. Unabhängige Tests ordnen der maschinenorientierten Abdeckung konstant immer nur grob 30 bis 40 % der echten Erfolgskriterien zu. Der Rest schreit nach dem Urteilsvermögen eines Menschen: Hat dieser Alt-Text Kontext und Mehrwert? Ist die Tastatur-Fokus-Reihenfolge schlüssig? Kommt ein Screenreader-Benutzer gut durch den gesamten Checkout? Erklärt eine ausgegebene Fehlermeldung prägnant auf, wie das dazugehörige Problem repariert werden kann?

Behandle diese Top-6 also ruhig als Minimum, niemals aber als sicheres Dach über dem Kopf. Nachdem du sie auf Null gedrückt hast, kümmere dich um den manuellen Durchlauf (Manual Pass):

• Navigiere die gesamte Wegstrecke von der PDP bis zum abgeschlossenen Checkout – und greife ausschließlich zur Tastatur (Tab, Shift+Tab, Enter). Du musst in der Lage sein, jede einzelne Eingabe und Funktion zu steuern.
• Lade einen Screenreader (VoiceOver auf dem Mac oder die Free-Variante NVDA auf Windows) und versuche im Live-Betrieb mal testweise einen Einkauf abzuschließen.
• Zoome auf 200 % ran und checke, ob irgendwo Boxen wegbechen oder schmerzhaft überlappen.

Und hier schließt sich der Kreis, weshalb sogenannte Accessibility Overlays das Problem per se nicht fixen: Ein im Hintergrund der Ladezeit reingeklebtes Skript bringt gar keine der erforderlichen manuellen Überlegungen mit und lässt auch stumpf genau die sechs ursächlichen Code-Fehler unangetastet stehen. Falls du dir immer noch recht unsicher bist, wie dich deine Shop-Infrastruktur rechtlich schützt, lies hier kurz nach: Ist Shopify ADA-compliant?.

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

Ähnliche Beiträge

Accessibility Overlays machen deinen Shopify Store nicht compliant

23 Jun 2026

Der European Accessibility Act für Shopify-Stores (2026)

7 Jul 2026

Der Stand der Shopify-Performance in 2026

20 Jul 2026