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

Wichtigste Erkenntnisse

• Sechs Fehler machen die überwiegende Mehrheit der Barrierefreiheitsfehler im Web aus, und jeder davon taucht auch in Shopify-Stores auf.
• 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.
• Die Lösung ist immer eine Änderung an deinem Theme-Code oder einem Admin-Feld, kein darübergelegtes Widget. Overlays lassen den zugrunde liegenden Fehler bestehen.
• Automatisierte Scanner erfassen diese sechs, weil sie eindeutig sind, aber das macht nur etwa ein Drittel der WCAG aus. Daher ist ein manueller Test mit Tastatur und Screenreader immer noch unerlässlich.

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

Im Folgenden findest du jeden Fehler mit seinem WCAG-Kriterium, wie er in einem Shopify-Theme auftritt und wie du ihn behebst.

Warum du uns vertrauen kannst

Jacques hat über 15 Jahre Erfahrung in der Entwicklung und hat vielen Shopify-Brands geholfen, barrierefreie, schnelle Storefronts zu shippen. Wir sind seit über vier Jahren im Shopify-Umfeld tätig und entwickeln Fudge, den KI-Operator für Shopify-Stores, mit einer Bewertung von 4.9 im Shopify App Store. Die direkte Behebung von Accessibility-Problemen im nativen Theme-Code gehört zu seinen Aufgaben. Die rechtlichen und standardbezogenen Hintergründe zu dieser Arbeit findest du in unserem ausführlicheren 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.¹ Fast alle dieser Fehler fallen in diese sechs Kategorien, und die Liste hat sich in sieben Jahren kaum verändert.

Die Prozentzahlen sind der Anteil der Top-Eine-Million-Startseiten, auf denen WebAIM im Februar 2026 den jeweiligen Fehler entdeckt hat.¹ 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 Seite ohne lang-Attribut im <html>-Element, sodass Hilfstechnologien nicht wissen, in welcher Sprache sie den Inhalt vorlesen sollen.

Warum es gegen die WCAG verstößt. 3.1.1 Language of Page (Sprache der Seite) erfordert, dass die standardmäßige menschliche Sprache jeder Seite programmatisch festgelegt wird. Ohne sie verwenden Screenreader möglicherweise die falschen Ausspracheregeln für die gesamte Seite.

Wie es in Shopify auftritt. Dieser Fehler befindet sich in einer einzigen Datei: theme.liquid, dem Layout, das jede Seite umschließt. Ein gut gebautes Theme setzt das Attribut anhand der Storefront-Locale. Custom Builds und stark bearbeitete Themes codieren manchmal einen festen Wert (Hardcoding) oder lassen das Attribut bei einem Redesign komplett weg.

Die Lösung. Setze lang aus der Request-Locale, damit es in jedem Markt und jeder übersetzten Storefront korrekt bleibt. Öffne layout/theme.liquid und überprüfe, ob der öffnende Tag so aussieht:

<!doctype html>
<html
  class="no-js"
  lang="{{ request.locale.iso_code }}"
>

Die Verwendung von {{ request.locale.iso_code }} anstelle eines festen "en" bedeutet, dass Shopify Markets und mehrsprachige Stores jedem Besucher automatisch den richtigen Sprachcode ausspielen. Dies ist eine Änderung in einer einzigen Zeile, die den Fehler sofort auf jeder Seite behebt.

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 sechs Fehler in nativem Code beheben und erneut prüfen

Jeder Fix oben ist eine Änderung an deinem Theme-Code oder einem Admin-Feld. Das ist Absicht. Eine echte Code-Änderung ist das, was ein Entwickler shippen würde, wovon ein Screenreader tatsächlich profitiert und was standhält, falls du jemals ein Mahnschreiben erhältst.

Hier kommt Fudge ins Spiel. Es ist der KI-Operator für Shopify-Stores: Wenn du nach einem Accessibility-Audit fragst, liest er dein Live-Theme, findet diese sechs Fehler in deinem Liquid, CSS und JavaScript und entwirft die Fixes direkt an der Quelle, damit dein Team sie als Vorschau ansehen und veröffentlichen kann. Frag nach einem Theme-Update oder einer neuen App-Installation erneut nach dem Audit, damit eine Änderung nicht unbemerkt wieder einen Fehler einführt. Da der Output nativer Code ist und kein injizierter Layer, gibt es kein zusätzliches Script, das die Seite verlangsamt. Es passt natürlich zu verwandten Aufgaben wie dem Hinzufügen strukturierter Daten und allgemeinem Store-Editing.

Beseitige die sechs Fehler, mach einen manuellen Durchlauf, und du hast das meiste Accessibility-Risiko in einem typischen Store dort beseitigt, wo es tatsächlich sitzt.

FAQ