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

Das Wichtigste in Kürze

• Ein Website Accessibility Audit besteht aus vier Ebenen: einem automatischen Scan, einem Tastatur-Check, einem Screenreader-Check sowie Inhalts- und Design-Prüfungen. Nur den ersten Schritt auszuführen, ist kein Audit.
• Das W3C sagt ganz klar, dass Tools „die Barrierefreiheit nicht feststellen, sondern nur dabei helfen können“. Eine Maschine kann nachweisen, dass ein Bild kein alt-Attribut hat. Sie kann aber nicht beurteilen, ob der Alt-Text nützlich ist.
• Deine Startseite zu scannen, bedeutet nicht, deinen ganzen Shop zu scannen. Nimm dir eine Seite pro Template vor, plus die interaktiven Zustände: Cart Drawer, Mobile Menu, Popups und Quick View.
• Erfasse alle gefundenen Probleme in einem einzigen Issue-Log mit Seite, WCAG-Erfolgskriterium, Schweregrad und zuständiger Person. Priorisiere zuerst blockierende Probleme, danach gehst du danach, wie viele Seiten der Fix betrifft.
• Führe ein Re-Audit nach Theme-Änderungen, neuen Kampagnen und App-Installationen durch. App-Installationen sind die häufigste Ursache für Rückschritte, weil 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, von dem sie denken, sie hätten ihn erledigt, weil sie einmal einen Scanner laufen ließen und einen Score bekommen haben. Ein Score ist ein Startpunkt. Es ist kein Audit und verrät dir nicht, ob jemand mit einer Tastatur den Checkout abschließen kann.

Dieser Guide behandelt die Audit-Methode, nicht die Fixes oder die rechtliche Lage. Vier Ebenen, alle kostenlos auf einem echten Shop durchführbar, von jemandem, der kein Accessibility-Spezialist ist. Wenn du stattdessen den rechtlichen Überblick brauchst, starte mit unserem Guide zur Shopify ADA- und WCAG-Compliance.

Warum du uns vertrauen kannst

Jacques hat über 15 Jahre Entwicklungserfahrung und vielen Shopify-Brands geholfen, barrierefreie und schnelle Storefronts zu launchen. Wir sind seit über vier Jahren im Shopify-Umfeld tätig und haben mit hunderten Shopify-Brands an ihren Storefronts gearbeitet. Wir entwickeln Fudge, einen AI-Storefront-Editor mit einer 5.0-Bewertung im Shopify App Store und “Built for Shopify”-Status. Wir verbringen unsere Tage also in der Theme-Ebene, wo diese Probleme tatsächlich auftreten.

---

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 Extension)	Chrome, Edge, Firefox	Der Standard für den ersten Scan. Nutzt die axe-core-Engine und prüft nach WCAG 2.0, 2.1 und 2.2 (Level A, AA und AAA).
WAVE	Chrome, Firefox, Edge	Visuelles Overlay der Probleme direkt auf der Seite. Läuft lokal, funktioniert also auch auf passwortgeschützten und Dev-Seiten.
Lighthouse	In Chrome DevTools integriert	Ein einzelner Accessibility Score sowie eine separate Liste manueller Checks, die explizit nicht automatisiert werden können.
Accessibility Insights for Web	Chrome, Edge	Der „FastPass“ liefert in unter fünf Minuten automatisierte Checks sowie eine visuelle Darstellung der Tab-Reihenfolge.

WAVE läuft komplett im Browser. Es werden keine Daten an einen Server gesendet, sodass du auch passwortgeschützte Preview-Themes scannen kannst. Du startest es mit Strg + Umschalt + U (bzw. Cmd + Umschalt + U auf dem Mac). Accessibility Insights for Web ist Open Source und kostenlos, entwickelt von Microsoft. Auch Shopifys eigene Dokumentation zur Theme-Barrierefreiheit empfiehlt es zusammen mit Lighthouse und WAVE.

Noch ein Hinweis zu Lighthouse: Der Accessibility Score ist ein gewichteter Durchschnitt aus bestandenen und nicht bestandenen Tests. Eine Seite bekommt keine Punkte für teilweise bestandene Checks. Sieh ihn als Rauchmelder, nicht als Zertifikat. Shopify sagt über seine eigenen Richtlinien das Gleiche: „Nur die Best Practices auf dieser Seite zu befolgen, garantiert nicht, dass dein Theme vollständig barrierefrei ist.“

Ein Scan deiner Startseite ist kein Scan deines Shops

Deine Startseite ist ein Template. Dein Shop besteht aus einem Dutzend Templates, von denen jedes andere Sections mit eigenen Bildern, Formularen und Controls rendert. Ein fehlerfreier Scan der Startseite sagt absolut nichts über deine Product Page aus, und die Product Page ist die Seite, auf die es ankommt.

Wähle eine Seite pro Template als Sample aus und scanne sie dann alle:

• Startseite (Home)
• Eine Collection Page, idealerweise mit Filtern und Pagination
• Eine Product Page, idealerweise mit Varianten, einem Size Guide und Reviews
• Die Cart Page (und den Cart Drawer separat, siehe unten)
• Suchergebnisse, inklusive des Empty States (keine Ergebnisse gefunden)
• Eine Content-Seite: Eine Über-uns-Seite, ein Blogpost oder eine FAQ
• Eine Kundenkonto-Seite, falls Accounts in deinem Shop aktiviert sind
• Den Checkout, so weit du kommst

Für den Checkout gibt es einen Vorbehalt. Die checkout.liquid ist nur für Shopify Plus-Händler verfügbar. In anderen Plänen stammt das Core-Markup des Checkouts von Shopify und nicht von dir. Geh ihn trotzdem durch und notiere, was du findest, aber die Fixes dafür liegen in den meisten Fällen nicht in deinem Theme.

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

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

Öffne den State zuerst und scanne dann. Ein Scan bei geschlossenem Drawer liefert keine Ergebnisse über den Drawer.

Das meiste, was Ebene eins ausspuckt, ist dieselbe Handvoll wiederkehrender Issues: Kontrast, Alt-Texte, Labels, leere Links und Buttons. Wie man das repariert, zeigen wir in Wie man die 6 häufigsten Shopify-Accessibility-Fehler 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 (gemessen am Volumen) wurden von der Automatisierung bei über 2.000 Erst-Audits, mehr als 13.000 Seiten und knapp 300.000 Problemen erkannt. Der Bericht merkt an, 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 ↩