Wie du ein Accessibility Audit für deinen Shopify-Shop machst (Kostenlose Tools)

Wichtigste Erkenntnisse

• Ein Website Accessibility Audit besteht aus vier Ebenen: einem automatisierten Scan, einem Tastatur-Test, einem Screenreader-Test sowie Inhalts- und Design-Checks. Nur den ersten Schritt auszuführen, ist noch kein Audit.
• Das W3C stellt klar, dass Tools „die Barrierefreiheit nicht feststellen, sondern nur dabei helfen können“. Eine Maschine kann beweisen, dass einem Bild das alt-Attribut fehlt. Sie kann aber nicht beurteilen, ob der Alt-Text sinnvoll ist.
• Deine Startseite zu scannen, bedeutet nicht, deinen gesamten Shop zu scannen. Nimm eine Seite pro Template als Stichprobe, plus die interaktiven Zustände: Cart Drawer, Mobile-Menü, Pop-ups und Quick View.
• Halte die Ergebnisse in einem einzigen Issue-Log mit Seite, WCAG-Erfolgskriterium, Schweregrad und Verantwortlichem fest. Priorisiere zuerst blockierende Probleme und dann danach, wie viele Seiten der Fix betrifft.
• Führe nach Theme-Änderungen, neuen Kampagnen und App-Installationen ein erneutes Audit durch. App-Installationen sind die häufigste Ursache für Regressionen, da sie Markup einfügen, das du nicht selbst geschrieben hast.

Ein Website Accessibility Audit ist der Schritt, den die meisten Shopify-Händler überspringen – oder besser gesagt, der Schritt, den sie glauben erledigt zu haben, weil sie einmal einen Scanner durchlaufen ließen und einen Score erhalten haben. Ein Score ist ein Ausgangspunkt. Es ist kein Audit und sagt dir nicht, ob ein Shopper, der nur die Tastatur benutzt, den Checkout abschließen kann.

Dieser Guide behandelt die Audit-Methode und nicht die Fixes oder die rechtliche Lage. Vier Ebenen, die alle kostenlos in einem echten Shop durchgeführt werden können, von jemandem, der kein Experte für Barrierefreiheit ist. Wenn du dich stattdessen für die rechtliche Seite interessierst, beginne mit unserem Guide zur Shopify ADA- und WCAG-Compliance.

Warum du uns vertrauen kannst

Jacques hat über 15 Jahre Entwicklungserfahrung und hat vielen Shopify-Marken geholfen, barrierefreie, schnelle Storefronts aufzubauen. Wir sind seit über vier Jahren im Shopify-Umfeld tätig und haben mit hunderten Shopify-Marken an ihren Storefronts gearbeitet. Wir entwickeln Fudge, einen KI-Storefront-Editor mit einer Bewertung von 4.9 im Shopify App Store und „Built for Shopify“-Status. Daher verbringen wir unsere Arbeitstage in der Theme-Ebene, wo diese Probleme tatsächlich angesiedelt sind.

---

Warum ein automatisierter Scan kein Audit ist

Automatisierte Tools sind gut in dem, was sie tun. Aber sie stoßen an Grenzen – und genau deshalb besteht ein echtes Audit aus mehr als nur einer Ebene.

Die Web Accessibility Initiative des W3C bringt diese Grenze auf den Punkt: „Tools können nicht alle Aspekte der Barrierefreiheit automatisch prüfen. Menschliches Urteilsvermögen ist erforderlich.“ Auf derselben Seite heißt es, dass Evaluierungs-Tools „Barrierefreiheit nicht feststellen, sondern nur dabei helfen können“.¹

Wie viel sie übersehen, hängt davon ab, was man zählt.

• Zählt man die Erfolgskriterien, deckt Automatisierung nur eine Minderheit ab. Ein Bericht von Deque stellt fest, dass Tools mit der klassischen Methode nur etwa 16 der 50 WCAG 2.1 Level AA Kriterien abdecken.²
• Zählt man das Volumen der Probleme (Issues), ist die Zahl höher. Bei über 2.000 Erst-Audits, 13.000 Seiten und knapp 300.000 Issues fand Deque heraus, dass die Automatisierung 57,38 % der erfassten Probleme erkannte.²

Beide Zahlen stimmen, aber sie messen unterschiedliche Dinge. Automatisierung findet einen großen Teil der Fälle (Instances), weil sich einige wenige Fehlertypen tausendfach wiederholen – allen voran Farbkontraste. Sie deckt aber viel weniger Regeln ab, und für die Regeln, die sie übersieht, braucht es einen Menschen.

Die Aufteilung ist immer gleich:

Ein Scanner kann beweisen	Ein Scanner kann nicht beurteilen
Dass ein Bild kein alt-Attribut hat	Ob der Alt-Text das Bild sinnvoll beschreibt
Dass ein Kontrastverhältnis unter 4,5:1 liegt	Ob die Tab-Reihenfolge der visuellen Reihenfolge entspricht
Dass ein <button> keinen zugänglichen Namen hat	Ob „Mehr erfahren“ für einen Screenreader-Nutzer überhaupt Sinn macht
Dass ein Input-Feld kein zugehöriges <label> hat	Ob eine Fehlermeldung erklärt, wie man die Eingabe korrigiert
Dass die Seite kein lang-Attribut hat	Ob ein Tastatur-Nutzer den Cart Drawer schließen kann

Alles in der rechten Spalte wird durch die Ebenen zwei, drei und vier gefunden.

---

Die vier Ebenen eines Website Accessibility Audits

Führe sie in dieser Reihenfolge aus. Jede Ebene ist kostenlos und findet Dinge, die die vorherige nicht finden konnte.

Ebene	Was sie findet	Dauer beim ersten Durchlauf
1. Automatischer Scan	Kontraste, fehlende Alt-Texte, fehlende Labels, leere Bedienelemente	1 bis 2 Stunden für eine Stichprobe von Seiten
2. Tastatur-Check	Focus Traps, unsichtbarer Fokus, Sackgassen, kaputte Tab-Reihenfolge	1 bis 2 Stunden
3. Screenreader-Check	Bedeutungslose Namen, unangekündigte Statusänderungen, unbrauchbare Flows	Einen halben Tag
4. Inhalt und Design	Alt-Text-Qualität, Fehlermeldungen, Bildunterschriften, Zoom und Reflow	2 bis 3 Stunden

Ein erstes Audit für einen typischen Shop dauert ungefähr zwei Arbeitstage. Jedes weitere Audit geht viel schneller, weil du nur noch die Änderungen (Diffs) und nicht mehr den ganzen Shop prüfst.

---

Ebene 1: Der automatisierte Scan

Welchen kostenlosen Scanner man nutzen sollte

Vier kostenlose Tools decken diese Ebene ab.

Tool	Wo es läuft	Gut für
axe DevTools (kostenlose Ext.)	Chrome, Edge, Firefox	Der standardmäßige erste Scan. Führt die axe-core-Engine gegen WCAG 2.0, 2.1 und 2.2 in A, AA und AAA aus
WAVE	Chrome, Firefox, Edge	Visuelles Overlay für Issues direkt auf der Seite. Läuft lokal, funktioniert also auf passwortgeschützten und Dev-Seiten
Lighthouse	In Chrome DevTools integriert	Ein einzelner Accessibility-Score plus eine separate Liste manueller Prüfungen, die explizit nicht automatisiert werden können
Accessibility Insights for Web	Chrome, Edge	FastPass liefert automatisierte Checks plus einen visuellen Tab-Stop-Trace in unter fünf Minuten

WAVE läuft komplett im Browser. Es werden also keine Daten an Server gesendet und du kannst ein passwortgeschütztes Preview-Theme scannen. Starte es mit Strg + Shift + U oder Command + Shift + U auf einem Mac. Accessibility Insights for Web ist kostenlos, Open Source, wurde von Microsoft entwickelt und wird in Shopifys eigener Theme-Accessibility-Doku neben Lighthouse und WAVE empfohlen. Wenn du lieber direkt im Shopify-Adminbereich scannen möchtest: Unsere Übersicht der besten Shopify Accessibility-Apps vergleicht die dedizierten Scanner-Apps.

Ein Hinweis zu Lighthouse: Der Accessibility-Score ist ein gewichteter Durchschnitt aus bestandenen oder nicht bestandenen Audits, und eine Seite bekommt keine Punkte, wenn sie einen Check nur teilweise besteht. Betrachte ihn als Rauchmelder, nicht als Zertifikat. Shopify sagt über seine eigenen Richtlinien dasselbe: „Nur das Befolgen der Best Practices auf dieser Seite garantiert nicht, dass dein Theme vollständig barrierefrei ist.“

Ein Scan deiner Startseite ist kein Scan deines Shops

Deine Startseite ist ein Template. Dein Store besteht aus einem Dutzend, die jeweils unterschiedliche Sections mit eigenen Bildern, Formularen und Bedienelementen rendern. Ein fehlerfreier Scan der Startseite sagt nichts über deine Produktseite aus – und die Produktseite ist die, auf die es ankommt.

Wähle eine Beispielseite pro Template und scanne sie dann alle:

• Startseite (Home)
• Eine Collection-Seite, idealerweise mit Filtern und Pagination
• Eine Produktseite, idealerweise mit Varianten, einem Size Guide und Reviews
• Die Warenkorb-Seite (und den Cart Drawer separat, siehe unten)
• Suchergebnisse, inklusive des Empty States (keine Treffer)
• Eine Content-Seite: eine Über-uns-Seite, ein Blog-Post oder ein FAQ
• Eine Kundenkonto-Seite, falls dein Store Accounts aktiviert hat
• Checkout, so weit du eben kommst

Beim Checkout gibt es einen Vorbehalt. Seit dem Ende von checkout.liquid wird das Checkout-Markup in jedem Plan von Shopify gerendert und nicht mehr von deinem Theme. Gehe ihn durch und logge, was du findest, aber Issues dort laufen über den Shopify-Checkout und dessen Extensions, nicht über deinen Theme-Code.

Scanne dann die Zustände (States), nicht nur die reinen Seiten. Hier scheitern Shopify-Themes am häufigsten, weil diese Komponenten oft aus Custom JavaScript bestehen und ein Scanner nur das sieht, was sich aktuell im DOM befindet:

• Der Cart Drawer, geöffnet
• Das Mobile-Menü und eventuelle Mega-Menüs, geöffnet
• Jedes Pop-up oder Newsletter-Modal, geöffnet
• Quick View auf einer Collection-Seite
• Ein Quiz- oder Product-Finder-Modal, mitten im Ablauf
• Das Predictive-Search-Panel, mit angezeigten Ergebnissen

Öffne den State zuerst und scanne dann. Ein Scan, der bei geschlossenem Drawer ausgeführt wird, meldet logischerweise nichts über den Drawer.

Das meiste, was Ebene eins ausspuckt, ist immer wieder dieselbe Handvoll Issues: Kontrast, Alt-Texte, Labels, leere Links und Buttons. Wie du diese behebst, zeigen wir dir in Die 6 häufigsten Shopify-Accessibility-Fehler und wie man sie behebt.

---

Ebene 2: Der manuelle Tastatur-Test

Leg die Maus weg. Starte auf der Startseite, drücke Tab und geh den ganzen Weg durch bis zu einer abgeschlossenen Testbestellung.

Worauf du dabei achten solltest:

• Der Skip Link. Der erste Druck auf Tab auf jeder Seite sollte einen “Skip to content” (Zum Inhalt springen) Link zum Vorschein bringen. In vielen angepassten Themes geht dieser verloren.
• Sichtbarer Fokus. Du musst jederzeit sehen können, wo du dich befindest. Ein globales outline: none im Theme-CSS ist die häufigste Ursache für fehlende Focus-Ringe.
• Tab-Reihenfolge entspricht visueller Reihenfolge. Der Fokus sollte sich von links nach rechts und von oben nach unten bewegen. Absolut positionierte Sections und Sticky-Elemente machen das oft kaputt.
• Keine Focus Traps. Öffne den Cart Drawer mit der Tastatur. Kannst du mit Tab durch ihn navigieren und wieder herauskommen? Lässt er sich mit Escape schließen?
• Keine Sackgassen. Jedes Control, das du mit einer Maus klicken kannst, muss mit Tab erreichbar und mit Enter oder der Leertaste bedienbar sein.
• Der Fokus wird nicht verdeckt. Ein Sticky-Header, ein Cookie-Banner oder eine schwebende Chat-Bubble können sich über das Element legen, das du gerade fokussiert hast.

Die vier Komponenten, die am häufigsten durchfallen, sind der Cart Drawer, das Mobile Menu, die Quick View und Pop-ups, die über Apps injiziert werden. Alle vier sind Modal- oder Drawer-Patterns, und alle vier benötigen dieselben drei Verhaltensweisen: Der Fokus wandert beim Öffnen in das Panel, der Fokus bleibt dort, solange es offen ist, und Escape schließt es und gibt den Fokus an das Control zurück, das es geöffnet hat.

Notiere jeden Fehler und mach weiter mit Tab. Bleib nicht mitten im Audit stehen, um etwas zu reparieren. Auditing und Fixing sind zwei verschiedene Jobs. Wenn man sie vermischt, wird das Audit nie fertig.

---

Ebene 3: Der Screenreader-Test

Das ist die Ebene, um die sich die meisten drücken, und die, die völlig verändert, wie du deinen Shop siehst.

Beide verlässlichen Optionen sind kostenlos. VoiceOver ist ohne Aufpreis in macOS und iOS integriert und wird in den Bedienungshilfen aktiviert. NVDA ist kostenlos für Windows und wird von NV Access entwickelt, einer eingetragenen Wohltätigkeitsorganisation.

Dein erster Durchlauf wird langsam sein, weil du gleichzeitig den Screenreader lernst und den Shop auditierst. Plane einen halben Tag ein. Das zweite Audit dauert dann nur noch eine Stunde.

Beginne mit einer Product Page, da diese die meiste interaktive Komplexität in einem Shop birgt. Achte auf Folgendes:

• Heading-Struktur (Überschriften). Beschreiben die Headings die Seite und sind sie logisch verschachtelt?
• Das Produktbild. Liest es etwas Sinnvolles vor, einen Dateinamen oder gar nichts?
• Varianten-Selektoren. Werden Swatches und Dropdowns mit Namen und aktuellem Wert angekündigt? Farbmuster (Color Swatches), die nur als ungelabelte Divs gerendert werden, sind ein typischer Fehler.
• Der Quantity Stepper (Mengenauswahl). Sagen die Plus- und Minus-Buttons, was sie tun?
• Add to cart (In den Warenkorb). Hat der Button einen Namen und wird das Warenkorb-Update angesagt? Ein “In den Warenkorb gelegt”, das ohne Fokusverschiebung erscheint, benötigt eine ARIA Live Region, sonst bekommt der Screenreader-Nutzer davon überhaupt nichts mit.
• Preis- und Bestandsänderungen. Wird es angesagt, wenn ein Variantenwechsel den Preis ändert oder “Nur noch 2 auf Lager” anzeigt?
• Akkordeons. Versand-, Retouren- und Beschreibungs-Panels benötigen ein aria-expanded, das den tatsächlichen Zustand (State) widerspiegelt.

Wiederhole das Ganze dann im Warenkorb und im Checkout. Wenn du einen Kauf nur mit einem Screenreader abschließen kannst, ist das meiste Risiko bereits gebannt. Falls nicht, hast du das Problem gefunden, das wichtiger ist als alles andere in deinem Issue-Log.

---

Ebene 4: Content- und Design-Checks

Die letzte Ebene erfordert menschliches Urteilsvermögen: die Kriterien klären, die ein Scanner als “Needs Review” markiert, und inhaltliche Probleme finden, die kein Scanner sieht.

Farbkontrast. Das WCAG 2.2 Kriterium 1.4.3 fordert mindestens 4,5:1 für normalen Text und 3:1 für großen Text (definiert als 18 Punkt oder 14 Punkt fett). Kriterium 1.4.11 erfordert 3:1 für Interface-Komponenten und bedeutungsvolle Grafiken.³ Scanner finden das meiste davon. Prüfe die Fälle, die sie übersehen: Text über einem Hero-Foto, Text über einem Verlauf (Gradient), deaktivierte Buttons. Teste Button-Text gegen die Füllfarbe des Buttons, nicht gegen den Seitenhintergrund.

Qualität der Alt-Texte, nicht nur ihre Existenz. Ein Scanner winkt alt="IMG_4021" durch. Ein Kunde hat davon nichts. Lies jedes alt-Attribut in deinem Sample und frag dich, ob es das vermittelt, was das Bild zeigt. Dekorative Bilder benötigen ein leeres alt="", damit Screenreader sie einfach überspringen. Unser Guide über das Hinzufügen von Alt-Texten in Shopify behandelt sowohl das Admin-Feld als auch die Theme-Seite.

Link- und Button-Namen. “Hier klicken”, “Mehr erfahren” und “Weiterlesen” fallen durch, wenn sie aus dem Kontext gerissen gelesen werden. Screenreader-Nutzer navigieren regelmäßig, indem sie sich eine Liste aller Links aufrufen. Benenne das Ziel konkret: “Zum Size Guide”.

Formular-Labels und Fehlermeldungen. Jeder Input braucht ein echtes, verknüpftes Label. Löse dann ganz bewusst die Validierung aus: Schick das Kontaktformular leer ab, gib eine fehlerhafte E-Mail-Adresse in das Newsletter-Feld ein. Der Fehler muss das betroffene Feld identifizieren, in Textform erklären, was falsch ist, und darf sich nicht nur auf einen roten Rahmen verlassen.

Video-Untertitel (Captions). Jedes Video mit gesprochenem Text braucht Untertitel. Autoplay-Hintergrundvideos benötigen einen Pause-Button.

Textvergrößerung und Zoom. Zoome auf 200 % und prüfe, ob nichts abgeschnitten wird oder überlappt. Verkleinere dann den Viewport auf 320 CSS-Pixel und stelle sicher, dass die Seite sich zu einer einzelnen Spalte ohne horizontales Scrollen anpasst (Reflow). Sticky-Header, breite Tabellen und mehrspaltige Sections sind hier die typischen Fehlerquellen.

Für eine kriterienbasierte Checkliste dieser Ebene nutze unsere WCAG 2.2 AA Checkliste für Shopify.

---

Wie du deine Ergebnisse festhältst

Ein Spreadsheet. Nicht vier Tool-Exporte und Screenshots in einem Chat-Verlauf. Jeder Fund bekommt eine Zeile:

Spalte	Warum sie da ist
Seite / Status	„Product Template“ oder „Cart Drawer, offen“, damit die Person, die es fixt, es reproduzieren kann.
Issue (Problem)	Ein Satz, der das Verhalten beschreibt, nicht die Theorie.
WCAG-Erfolgskriterium	Die Nummer, z. B. 2.1.2. Macht das Ergebnis belegbar und durchsuchbar.
Schweregrad (Severity)	Blockierend (blocking) oder einschränkend (degrading), siehe unten.
Wo es liegt	Theme-Code, Admin-Content oder eine App.
Zuständig (Owner)	Eine Person, kein Team.
Status	Offen, gefixt, verifiziert.

Die Spalte „Wo es liegt“ ist wichtiger, als es aussieht. Sie unterteilt die Arbeit in drei Kategorien: Theme-Code, den du selbst kontrollierst, Admin-Content, den jeder ohne Entwickler fixen kann, und App-injected Markup, das du vielleicht gar nicht ändern kannst.

Wie man die Fixes priorisiert

Zwei Fragen, in dieser Reihenfolge.

Ist es blockierend oder einschränkend? Ein blockierendes Problem bedeutet, dass die Aufgabe nicht abgeschlossen werden kann: ein Keyboard Trap im Cart Drawer, ein ungelabeltes Pflichtfeld im Checkout, ein Add-to-cart-Button ohne Accessible Name. Das sind verlorene Sales, und genau das beschreibt ein anwaltliches Abmahnschreiben (Demand Letter). Ein einschränkendes Problem macht die Aufgabe schwerer, aber immer noch machbar: eine Caption mit wenig Kontrast, vager Alt-Text, eine übersprungene Heading-Ebene. Behebe alle blockierenden Probleme, bevor du dich an die einschränkenden machst.

Welche Reichweite hat der Fix? Sortiere das, was übrig bleibt, danach, wie viele Seiten es betrifft. Ein fehlendes Label im Suchfeld des Headers ist eine Änderung, die den Fehler direkt für den gesamten Shop behebt. Ein schwacher Alt-Text bei einem Blog-Bild betrifft ein Bild. Gewichte nach Traffic, da deine Product- und Collection-Templates die meisten Sessions generieren.

Die Aufgabenliste, die sich aus diesen beiden Fragen ergibt, ist das eigentliche Endprodukt deines Audits.

Wie oft man Re-Audits machen sollte

Drei Auslöser (Triggers) plus eine Baseline.

• Nach einer Theme-Änderung. Ein Theme-Update, ein Redesign oder eine neue Custom Section. Mach ein Re-Audit der Templates, die davon betroffen sind.
• Nach einem Campaign-Build. Landingpages, die schnell für einen Launch oder BFCM gebaut wurden, sind genau die, die mit ungelabelten E-Mail-Feldern und 2,5:1-Rabatt-Badges online gehen.
• Nach der Installation einer App. Der wichtigste Punkt.
• Vierteljährlich, als Baseline, selbst wenn sich nichts geändert hat.

App-Installationen sind die häufigste Fehlerquelle. Eine Storefront-App schleust Markup ein, das du nicht geschrieben und nicht überprüft hast: ein Review-Widget, ein Upsell-Drawer, ein Pop-up, ein Currency-Switcher, eine Chat-Bubble. Es hält sich nicht an die Konventionen deines Themes, erbt nicht deine Focus-Styles und ist oft ein <div> mit einem Click-Handler, wo eigentlich ein <button> hingehört. Nichts in Shopify warnt dich davor, dass die App, die du gerade installiert hast, einen Focus Trap hinzugefügt hat.

Mache nach jeder Installation einer Storefront-App einen Scan und einen Tastatur-Test auf den Seiten, auf denen sie erscheint. Zwanzig Minuten reichen aus, um das Gröbste zu finden.

Ein Overlay ist kein Audit und kein Fix

Das muss erwähnt werden, weil es oft als Abkürzung für all das oben Genannte verkauft wird.

Third-Party Accessibility-Overlays ersetzen weder ein Audit noch die Fixes. Im April 2025 verabschiedete die FTC einen endgültigen Beschluss, der accessiBe zur Zahlung von 1 Million US-Dollar verurteilte, wegen der Behauptung, ihr AI-Produkt könne jede Website WCAG-konform machen.⁴ Websites, die Overlays nutzen, werden trotzdem verklagt, weil das zugrunde liegende Markup unverändert bleibt. Wir behandeln diesen Fall genauer in unserem Guide darüber, warum Accessibility-Overlays scheitern.

Die Alternative ist unglamourös, aber sie funktioniert: Finde die Probleme, fixe sie im Theme, überprüfe sie neu. Das ist das Modell, um das herum wir Fudge gebaut haben. Es liest dein Live-Theme, zeigt auf, was in deinem Liquid, CSS und JavaScript fehlschlägt, und fixt es direkt im nativen Theme-Code, anstatt eine Ebene darüber zu legen. Weil der Output echter Code ist, überlebt er eine Deinstallation, fügt kein zusätzliches Script zur Seite hinzu und reiht sich direkt in deine normale Arbeit als Shop-Editor ein.

---

FAQ

Footnotes

1. W3C Web Accessibility Initiative, “Selecting Web Accessibility Evaluation Tools”: “Tools cannot check all accessibility aspects automatically. Human judgement is required” und “Web accessibility evaluation tools can not determine accessibility, they can only assist in doing so.” https://www.w3.org/WAI/test-evaluate/tools/selecting/ ↩

2. Deque, “The Automated Accessibility Coverage Report”: 57,38 % der Issues, die durch Automatisierung in über 2.000 Erst-Audits auf mehr als 13.000 Seiten und bei fast 300.000 Issues erkannt wurden, gemessen am Issue-Volumen. Der Bericht weist darauf hin, dass die traditionelle kriterienbasierte Methode etwa 16 der 50 WCAG 2.1 Level AA-Kriterien abdeckt. https://www.deque.com/automated-accessibility-coverage-report/ ↩ ↩²

3. W3C, WCAG 2.2 Quick Reference: Das Erfolgskriterium 1.4.3 Contrast (Minimum) erfordert 4,5:1 für normalen Text und 3:1 für großen Text (18 Punkt oder 14 Punkt fett); 1.4.11 Non-text Contrast erfordert 3:1. https://www.w3.org/WAI/WCAG22/quickref/ ↩

4. Federal Trade Commission, “FTC Approves Final Order Requiring accessiBe to pay $1 Million”, April 2025. https://www.ftc.gov/news-events/news/press-releases/2025/04/ftc-approves-final-order-requiring-accessibe-pay-1-million ↩