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 Schichten: einem automatisierten Scan, einem Tastatur-Test, einem Screenreader-Test sowie Inhalts- und Design-Checks. Nur den ersten Teil durchzuführen, ist noch lange kein Audit.
• Das W3C sagt ganz klar, dass Tools „Barrierefreiheit nicht bestimmen können, sie können nur dabei helfen.“ Eine Maschine kann zwar beweisen, dass ein Bild kein alt-Attribut hat. Sie kann aber nicht beurteilen, ob der Alt-Text sinnvoll ist.
• Das Scannen deiner Startseite ist nicht das Scannen deines Stores. Nimm dir eine Seite pro Template vor, plus die interaktiven Zustände: Cart Drawer, Mobile-Menü, Pop-ups und Quick View.
• Erfasse deine Ergebnisse in einem einzigen Issue-Log mit Seite, WCAG-Erfolgskriterium, Schweregrad und Zuständigem. Priorisiere blockierende Probleme zuerst, danach sortierst du danach, auf wie viele Seiten sich der Fix auswirkt.
• Führe nach Theme-Änderungen, neuen Kampagnen und App-Installationen ein Re-Audit durch. App-Installationen sind die häufigste Ursache für Regressionen, weil sie Markup in deinen Code injizieren, das du nicht selbst geschrieben hast.

Um deinen Shopify-Store auf Barrierefreiheit (Accessibility) zu prüfen, solltest du vier Schichten durcharbeiten: kostenlose automatisierte Scanner, einen Tastatur-Test, einen Screenreader-Test und Inhalts-Checks. Protokolliere dann jedes gefundene Problem. Die meisten Shopify-Händler denken, sie hätten ein Website Accessibility Audit durchgeführt, nur weil sie einmal einen Scanner haben laufen lassen und einen Score bekommen haben. Ein Score ist aber nur ein Ausgangspunkt. Er ist kein Audit und verrät dir nicht, ob ein Shopper, der nur mit der Tastatur navigiert, den Checkout abschließen kann.

Dieser Guide behandelt die Audit-Methode und weniger die genauen Fixes oder die rechtliche Lage. Es geht um vier Schichten, die alle kostenlos, an einem echten Store und von jemandem durchgeführt werden können, der kein Spezialist für Barrierefreiheit ist. Wenn du dich stattdessen für die rechtliche Seite interessierst, starte am besten mit unserem Guide zur Shopify ADA- und WCAG-Compliance.

Warum du uns vertrauen kannst

Jacques hat über 15 Jahre Entwicklungserfahrung und vielen Shopify-Marken geholfen, barrierefreie, schnelle Storefronts live zu bringen. Wir sind seit über vier Jahren im Shopify-Ökosystem unterwegs und haben mit Hunderten von Shopify-Marken an ihren Storefronts gearbeitet. Wir entwickeln Fudge, den KI-Operator für Shopify-Stores, mit einer Bewertung von 4.9 im Shopify App Store und „Built for Shopify“-Status. Daher verbringen wir unsere Tage in der Theme-Ebene, wo diese Probleme tatsächlich auftreten.

Warum ein automatisierter Scan kein Audit ist

Automatisierte Tools sind nützlich, aber eingeschränkt. Deshalb besteht ein echtes Audit aus mehr als einer Schicht.

Die W3C Web Accessibility Initiative bringt diese Grenze klar 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 bestimmen können, sie können nur dabei helfen.“¹

Wie viel sie übersehen, hängt davon ab, was du zählst.

• Zählt man die Erfolgskriterien, deckt Automatisierung nur eine Minderheit ab. Deques eigener Bericht stellt fest, dass die traditionelle Methode bei Tools etwa 16 der 50 WCAG 2.1 Level AA-Kriterien abdeckt.²
• Zählt man das Fehlervolumen, ist die Zahl höher. In über 2.000 Erstaudits, 13.000 Seiten und fast 300.000 Problemen stellte Deque fest, dass Automatisierung 57,38 % der erfassten Fehler aufdeckte.²

Beides stimmt, denn es werden unterschiedliche Dinge gemessen. Automatisierung findet einen großen Teil der Vorkommnisse, weil sich einige 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 sieht immer ähnlich aus:

Alles in der rechten Spalte wird durch die Schichten 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.

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.

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 Phase ist Beurteilungsarbeit: Kriterien klären, die ein Scanner als „Überprüfung erforderlich“ markiert, und inhaltliche Probleme finden, die kein Scanner sieht.

Farbkontrast. WCAG 2.2 Kriterium 1.4.3 erfordert ein Verhältnis von 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 aussagekräftige Grafiken.³ Scanner erkennen das meiste davon. Überprüfe die Fälle, die sie übersehen: Text über einem Hero-Bild, Text über einem Farbverlauf, deaktivierte Buttons. Teste den Button-Text gegen die Hintergrundfarbe des Buttons, nicht gegen den Hintergrund der Seite.

Alt-Text-Qualität, nicht nur Vorhandensein. Ein Scanner lässt alt="IMG_4021" durchgehen. Ein Shop-Besucher hat jedoch nichts davon. Lies dir jedes alt-Attribut in deiner Stichprobe durch und frage dich, ob es dieselbe Aussage wie das Bild vermittelt. Dekorative Bilder benötigen ein leeres alt="", damit Screenreader sie überspringen. Unser Guide, wie man Alt-Texte in Shopify hinzufügt, deckt das Admin-Feld und die Umsetzung im Theme ab.

Link- und Button-Namen. „Hier klicken“, „Mehr erfahren“ und „Weiterlesen“ versagen, wenn sie aus dem Kontext gerissen gelesen werden. Screenreader-Nutzer navigieren oft, indem sie sich eine Liste aller Links aufrufen lassen. Benenne das Ziel: „Zur Größentabelle“.

Formular-Labels und Fehlermeldungen. Jedes Eingabefeld braucht ein echtes, verknüpftes Label. Löse dann gezielt eine Validierung aus: Schicke das Kontaktformular leer ab, gib eine ungültige E-Mail-Adresse ins Newsletter-Feld ein. Die Fehlermeldung muss das Feld benennen, in Textform erklären, was falsch ist, und darf sich nicht allein auf einen roten Rahmen verlassen.

Video-Untertitel. Jedes Video mit Sprache benötigt Untertitel. Automatisch abspielende Hintergrundvideos brauchen einen Pause-Button.

Textgröße und Zoom. Zoome auf 200% und prüfe, ob nichts abgeschnitten wird oder sich überlappt. Verkleinere dann den Viewport auf 320 CSS-Pixel und prüfe, ob die Seite in ein einspaltiges Layout umbricht, ohne dass horizontales Scrollen nötig ist. Sticky Header, breite Tabellen und mehrspaltige Abschnitte sind die üblichen Fehlerquellen.

Für eine detaillierte, nach Kriterien geordnete Version dieses Schritts, 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:

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

Erwähnenswert, weil es als Abkürzung für all das oben Genannte verkauft wird.

Accessibility-Overlays von Drittanbietern sind kein Ersatz für ein Audit oder die eigentlichen Fehlerbehebungen. Im April 2025 verabschiedete die US-Behörde FTC eine rechtskräftige Anordnung, die accessiBe zur Zahlung von 1 Million US-Dollar verpflichtet – wegen der Behauptung, dass ihr KI-Produkt jede Website WCAG-konform machen könne.⁴ Websites, die Overlays nutzen, werden trotzdem verklagt, da das zugrunde liegende Markup unverändert bleibt. Wir behandeln den Fall genauer in unserem Guide darüber, warum Accessibility-Overlays scheitern.

Die Alternative ist unglamourös, aber sie funktioniert: Finde die Probleme, behebe sie im Theme, prüfe sie erneut. Fudge folgt genau diesem Modell. Wenn du Fudge nach einem Accessibility-Audit fragst, liest es dein Live-Theme, listet die Fehler in deinem Liquid, CSS und JavaScript auf und entwirft die Fixes im nativen Theme-Code, anstatt einfach eine weitere Schicht darüberzulegen. Dein Team schaut sich jeden Fix in der Vorschau an, bevor er live geht. Behalte die Tastatur- und Screenreader-Tests in jedem Fall bei, denn kein Tool kann sie ersetzen. Da das Ergebnis echter Code ist, bleibt er auch nach einer Deinstallation erhalten, fügt der Seite keine zusätzlichen Skripte hinzu und reiht sich nahtlos in deine restliche Arbeit am Shop ein.

FAQ