Barrierefreier Checkout: die kritischen Punkte für Onlineshops

Von Manuel Hack, ihp media · Aktualisiert am 29. Juni 2026

Ein barrierefreier Checkout ist seit dem 28. Juni 2025 für viele gewerbliche Onlineshops Pflicht, geregelt im Barrierefreiheitsstärkungsgesetz. Fürs Geschäft zählt ein zweiter Grund mindestens genauso: Ein zugänglicher Bezahlprozess reduziert Abbrüche. Wer Menschen mit Seheinschränkungen, motorischen oder kognitiven Einschränkungen im Checkout verliert, verschenkt abgeschlossene Käufe. Dieser Beitrag zeigt, an welchen konkreten Punkten die meisten Shops scheitern, was die WCAG 2.2 konkret verlangt, und wie eine konforme Umsetzung im Markup aussieht.

Warum der Checkout der kritischste Schritt im Shop ist

Der Checkout scheitert deshalb so häufig an der Barrierefreiheit, weil er der informationsdichteste Bereich eines Shops ist. Wer einen Produktfilter benutzt, kann eine Seite neu laden und es erneut versuchen. Wer im Checkout steckt, verlässt den Shop. Das ist der entscheidende Unterschied für die Conversion.

Viele Shop-Themes und Standard-Plugins sind optisch ansprechend, aber technisch nicht konform. Ein Akkordeon für Versandoptionen wirkt aufgeräumt, bleibt für Screenreader unsichtbar, wenn die nötigen ARIA-Attribute fehlen. Dasselbe gilt für selbst gebaute Checkboxen, bei denen das eigentliche Eingabeelement per CSS ausgeblendet und durch ein gestyltes div ersetzt wird. Diese Technik bricht die Tastatursteuerung: Ein div ist nicht von sich aus fokussierbar.

Warum gerade die WCAG der Maßstab ist, ergibt sich aus einer Normenkette. Das BFSG nennt selbst keine Detailkriterien, sondern arbeitet mit einer Konformitätsvermutung: Wer die harmonisierte europäische Norm EN 301 549 erfüllt, bei dem gilt die Barrierefreiheit als erfüllt. Diese Norm verweist in ihrem Web-Kapitel auf die WCAG, deshalb sind die WCAG-Kriterien der praktische Prüfmaßstab. Den Verstoß verfolgt die Marktüberwachungsstelle der Länder (MLBF) in Magdeburg: Sie kann Mängelbeseitigung anordnen und bei ausbleibender Umsetzung Bußgelder bis zu 100.000 Euro verhängen (§ 37 BFSG).

Was Barrierefreiheit im Onlineshop grundsätzlich bedeutet und wen das BFSG betrifft, klärt der Überblicksartikel BFSG und Onlineshop: Was Händler 2026 wissen müssen. Hier geht es gezielt um den Checkout.

Die kritischen WCAG-Punkte im Checkout auf einen Blick

Die folgende Tabelle zeigt die häufigsten Checkout-Barrieren, das zugehörige WCAG-Kriterium und eine konkrete Lösung. Sie ist sortiert nach Auftretenshäufigkeit in der Praxis.

Unsere Einschätzung: Wer begrenzte Zeit hat, beginnt nicht beim Kontrast, sondern bei der Tastatur. Ein per Tastatur blockierter Kaufpfad ist ein Totalausfall, ein zu blasser Hilfetext nur eine Hürde. Die sinnvolle Reihenfolge: erst den gesamten Checkout einmal ohne Maus durchklicken und jeden Stopp beseitigen, dann Labels und Fehlertexte, zuletzt Kontrast und Feinheiten. Overlays, die das per JavaScript überdecken sollen, lösen keinen dieser Punkte und stehen zu Recht in der Kritik.

Formularlabels, Fehlerbehandlung und Eingabehilfen

Barrierefreie Formularfelder haben sichtbare und programmatisch verknüpfte Beschriftungen, eine klare Fehlerrückmeldung in Textform und Hinweise zur erwarteten Eingabe. Das klingt selbstverständlich, ist aber der häufigste Fehlertyp im Checkout.

Jedes Feld braucht ein <label>, das über das for-Attribut mit der id des Feldes eindeutig verbunden ist. Ein Platzhaltertext allein genügt nicht: Er verschwindet beim Tippen und wird von manchen Screenreadern gar nicht vorgelesen. WCAG 2.2 Kriterium 3.3.2 verlangt Beschriftungen oder Anweisungen für Eingabefelder auf Stufe A; ein reiner Platzhalter erfüllt das nicht, weil er beim Tippen verschwindet.

Bei Fehlern verlangt Kriterium 3.3.1, dass das Problem in Textform benannt wird. Ein Feld nur rot einzufärben reicht nicht: Eine Person mit Screenreader nimmt die Farbe nicht wahr. Die Meldung sollte über aria-describedby mit dem betroffenen Feld verknüpft sein, damit sie beim Fokussieren mit vorgelesen wird. Falls das System Fehlerkorrekturen vorschlagen kann, kommt Kriterium 3.3.3 (Fehlerkorrekturvorschlag) hinzu, das auf Stufe AA ebenfalls Pflicht ist.

Für wiederkehrende Eingaben wie Straße, Postleitzahl oder Kartennummer gehört das autocomplete-Attribut mit standardisierten Werten an das Feld. Das erleichtert die Eingabe für alle und entlastet besonders Menschen mit motorischen Einschränkungen. Kriterium 1.3.5 (Eingabezweck) fordert das auf Stufe AA. Mehr zu barrierefreien Formularen allgemein zeigt der Artikel Barrierefreie Formulare: Schritt für Schritt.

Tastaturbedienung ohne Fallstricke

Der Fokus muss dabei sichtbar sein. Die Standard-Umrandung des Browsers genügt in vielen Fällen, wird aber durch verbreitete CSS-Resets mit outline: none unterdrückt. WCAG 2.2 Kriterium 2.4.7 fordert einen sichtbaren Fokus auf Stufe AA. Eine strukturierte Prüfanleitung dafür steht im Leitfaden Tastaturbedienung testen: So prüfen Sie ohne Maus.

Modale Dialoge für Datenschutzhinweise oder Versandoptionen sind eine bekannte Falle. Der Fokus muss beim Öffnen in den Dialog wandern und beim Schließen an die auslösende Stelle zurückkehren. Bleibt er im Hintergrund der Seite, läuft die Tastaturbedienung ins Leere. Das ist nicht durch automatische Tools zu finden, sondern nur durch manuelles Testen.

Für die Auswahl von Land oder Zahlart sind native <select>-Elemente die zuverlässige Wahl, weil alle Hilfsmittel sie ohne Zusatzaufwand verstehen. Wer ein eigenes Dropdown baut, trägt die volle Verantwortung für korrekte ARIA-Auszeichnung und Tastaturlogik selbst. Wann ARIA sinnvoll ist und wann es mehr schadet als nützt, erklärt ARIA Barrierefreiheit richtig einsetzen.

Kontrast und visuelle Gestaltung im Bezahlprozess

Der Mindestkontrast für normalen Text liegt bei 4,5:1 gegenüber dem Hintergrund (WCAG 2.2 Kriterium 1.4.3, Stufe AA). Für großen Text ab 18 Punkt oder ab 14 Punkt fett genügen 3:1. Diese Werte gelten für jeden Text im Checkout, also auch für grau gehaltene Hilfetexte, blass dargestellte Preise und dezent gesetzte Warenkorbsummen. Zum Messen und Dokumentieren von Kontrasten gibt es einen eigenen Leitfaden: Farbkontrast nach WCAG richtig prüfen.

Besondere Aufmerksamkeit verdienen deaktivierte Schaltflächen. Der Kaufen-Button, der ausgegraut bleibt, bis alle Pflichtfelder ausgefüllt sind, gilt technisch als deaktiviert und fällt damit aus der Kontrastanforderung heraus. Das ist formal korrekt, in der Praxis aber aus UX-Sicht problematisch: Niemand erkennt, warum der Button nicht reagiert. Empfehlenswert ist, die Schaltfläche aktiv zu lassen und beim Klick gezielt auf die fehlenden Felder hinzuweisen. Eine WCAG-Pflicht ist das nicht.

Wichtige Informationen dürfen nicht allein über Farbe vermittelt werden (Kriterium 1.4.1, Stufe A). Ein Pflichtfeld nur mit einem roten Sternchen zu markieren reicht nicht. Ein kurzer Hinweis wie * Pflichtfeld am Anfang des Formulars schafft Klarheit.

Zahlungsauswahl und externe Widgets

Die Zahlungsauswahl ist heikel, weil Anbieter wie PayPal, Klarna oder Kreditkartendienstleister eigene iframes einbetten, die Sie als Shopbetreiber nicht unmittelbar steuern. Die Verantwortung für den gesamten Kaufprozess bleibt nach dem Gesetzeswortlaut dennoch grundsätzlich bei Ihrem Shop. Sie sind Dienstleistungserbringer im Sinne von § 2 Nr. 4 BFSG und müssen Ihre Dienstleistung nach § 3 Abs. 1 BFSG insgesamt barrierefrei anbieten, eingebettete Fremd-Widgets eingeschlossen. Wie die Marktüberwachung unbeeinflussbare Drittkomponenten im Einzelfall bewertet, ist allerdings noch nicht abschließend geklärt.

Lässt sich ein Zahlungs-Widget nicht per Tastatur bedienen oder kann ein Screenreader darin nicht navigieren, ist Ihr Checkout nicht konform. Fragen Sie Anbieter aktiv nach ihrer Barrierefreiheitsdokumentation. Einige veröffentlichen Accessibility-Statements zu ihren Komponenten, aber ein veröffentlichtes Statement ersetzt nicht die eigene Prüfung im konkreten Shop.

Für die Auswahl zwischen mehreren Zahlarten sind Radiobuttons die semantisch richtige Wahl. Wer klickbare Kacheln gestaltet, muss die Rollen radiogroup und radio mitsamt dem Zustand aria-checked vergeben und die Bedienung über die Pfeiltasten nachbilden. Das ist fehleranfällig und wird von manchen Themes einfach vergessen.

<!-- Typisch, aber nicht konform -->
<input type="text" placeholder="PLZ" />

<!-- Konform nach WCAG 2.2 AA -->
<div class="field-wrap">
  <label for="plz">Postleitzahl <span aria-hidden="true">*</span></label>
  <input
    type="text"
    id="plz"
    name="billing_postcode"
    autocomplete="postal-code"
    inputmode="numeric"
    required
    aria-required="true"
    aria-describedby="plz-hint plz-error"
  />
  <span id="plz-hint" class="field-hint">5-stellige Postleitzahl</span>
  <span id="plz-error" class="field-error" role="alert"></span>
</div>

Ein typischer Fall: der Weiter-Button als div

Ein häufiges Muster zeigt, wie eine einzige Zeile den Kauf blockiert. In vielen WooCommerce-Themes ist der Weiter-Button im Bestellschritt ein klickbares div ohne Tastaturfokus. Mit der Maus lässt sich der Bezahlvorgang problemlos abschließen, mit der Tastatur endet er an dieser Stelle. Für sehende Mauskunden ist das unsichtbar, für jeden Tastaturnutzer das harte Ende der Bestellung. Automatische Scanner wie WAVE oder Lighthouse finden Kontrastfehler und fehlende Labels zuverlässig, einen als Schaltfläche getarnten div-Button erkennen sie aber nur teilweise. Dafür braucht es den manuellen Tastaturtest: Kein Scanner prüft, ob ein Element an seiner Stelle semantisch Sinn ergibt, sondern nur, ob es technisch fokussierbar ist.

<!-- Theme-Originalcode, nicht konform -->
<div class="weiter" onclick="next()">Weiter</div>

<!-- Korrektur -->
<button type="button" class="weiter">Weiter</button>

Ein echtes button-Element ist von Haus aus per Tab erreichbar, löst bei Enter und Leertaste aus und meldet sich dem Screenreader als Schaltfläche. Das div müsste man mit tabindex, role="button" und eigenen Tastatur-Handlern nachrüsten, und genau das wird beim Theme-Bau übersehen. Die Korrektur ist eine Zeile, ihre Wirkung ist der Unterschied zwischen einem abgeschlossenen und einem abgebrochenen Kauf.

Bestellübersicht und Bestätigungsseite

Die letzte Seite vor dem Kauf und die Bestätigung danach werden bei der Barrierefreiheit häufig übersehen. Die Bestellübersicht sollte als strukturierte Tabelle ausgezeichnet sein, damit ein Screenreader den Zusammenhang von Produktname, Menge und Preis herstellen kann. Eine saubere <table> mit Kopfzellen (<th scope="col">) ist deutlich robuster als tief verschachtelte div-Konstruktionen (WCAG 2.2 Kriterium 4.1.2).

Nach dem Abschluss muss die Erfolgsmeldung programmatisch angekündigt werden. Lädt die Seite still nach oder tauscht JavaScript nur einen Bereich aus, ohne den Screenreader zu informieren, weiß Ihr Kunde nicht, ob die Bestellung angekommen ist. Eine aria-live-Region mit einer klaren Statusmeldung oder die Weiterleitung auf eine vollständige Bestätigungsseite lösen das Problem zuverlässig.

Sofort-Checkliste für den Checkout

Diese Punkte prüfen Sie ohne Spezialwissen: Gehen Sie den Checkout einmal komplett mit der Tastatur durch, ohne Maus. Was klemmt, ist meist einer der folgenden Punkte.

• Hat jedes Formularfeld ein sichtbares <label>, das beim Fokussieren mit vorgelesen wird?
• Benennen Fehlermeldungen in Textform, welches Feld fehlt und warum?
• Ist der Kaufen-Button und jeder Weiter-Link mit der Tabulatortaste erreichbar?
• Ist beim Durchtabben immer sichtbar, welches Element gerade aktiv ist?
• Erfüllen Hilfetexte, Preise und Labels den Mindestkontrast von 4,5:1?
• Sind Pflichtfelder neben der Farbe auch durch einen Texthinweis erkennbar?
• Haben Adress- und Zahlungsfelder das passende autocomplete-Attribut?
• Fängt ein modaler Dialog (Versand, Datenschutz) den Fokus und gibt ihn beim Schließen zurück?
• Ist die Bestellübersicht als Tabelle ausgezeichnet, nicht als verschachtelte divs?
• Wird die Kaufbestätigung dem Screenreader aktiv mitgeteilt?
• Haben Sie die Zahlungsanbieter-Widgets auf Tastaturbedienung getestet?

Häufige Fragen

Gilt das Barrierefreiheitsstärkungsgesetz auch für kleine Onlineshops?

Das BFSG nimmt Kleinstunternehmen aus, die Dienstleistungen anbieten oder erbringen (§ 3 Abs. 3 BFSG). Als Kleinstunternehmen gilt, wer weniger als zehn Beschäftigte hat und zugleich entweder einen Jahresumsatz oder eine Jahresbilanzsumme von höchstens zwei Millionen Euro aufweist (BFSG § 2 Nr. 17). Wichtig für Onlineshops: Der Betrieb eines Shops ist rechtlich eine Dienstleistung im elektronischen Geschäftsverkehr (§ 1 Abs. 3 Nr. 5 BFSG), auch wenn darüber physische Waren verkauft werden. Die verkauften Standardwaren selbst sind keine Produkte im Sinne des BFSG. Damit greift die Kleinstunternehmer-Ausnahme auch für reine Warenshops. Voraussetzung bleibt, dass sich der Shop an Verbraucher richtet; ein reiner B2B-Shop, der Verbraucher klar ausschließt, kann ganz aus dem Dienstleistungsbereich des BFSG fallen. Wer dagegen zehn oder mehr Personen beschäftigt, fällt unter das Gesetz, unabhängig von den Finanzwerten. Auch wer formal ausgenommen ist, fährt mit einem zugänglichen Shop oft besser, denn die Conversion-Vorteile gelten unabhängig vom Gesetz. Die Details erklärt der Artikel BFSG und Onlineshop: Was Händler 2026 wissen müssen.

Müssen bestehende Shops nachgerüstet werden oder gilt das nur für Neuentwicklungen?

Es gibt keinen Bestandsschutz. Das BFSG gilt seit dem 28. Juni 2025 und unterscheidet nicht zwischen alten und neuen Angeboten. Wer einen Shop betreibt, der unter das Gesetz fällt, muss ihn konform halten, unabhängig davon, wann er ursprünglich umgesetzt wurde. Die Marktüberwachungsstelle der Länder (MLBF) kann Mängelbeseitigung anordnen und bei ausbleibender Umsetzung Bußgelder bis zu 100.000 Euro verhängen (§ 37 BFSG).

Reicht es, ein Overlay oder ein Accessibility-Plugin zu installieren?

Nein. Overlays, die per JavaScript nachträglich Korrekturen einblenden, lösen die eigentlichen technischen Probleme im Quellcode nicht und werden von Barrierefreiheits-Fachleuten, gebündelt im Overlay Fact Sheet, abgelehnt. Sie können sogar mit den Einstellungen vorhandener Hilfsmittel kollidieren. Eine konforme Umsetzung erfordert Eingriffe direkt im Code.

Wie teste ich den Checkout ohne großes Budget auf Barrierefreiheit?

Gehen Sie den gesamten Checkout nur mit der Tabulatortaste durch, ohne Maus, und prüfen Sie, ob Sie jedes Feld erreichen, ausfüllen und den Kauf abschließen können. Ergänzend schalten Sie WAVE oder Lighthouse zu. Das deckt die gröbsten Probleme auf. Für eine vollständige WCAG-konforme Bewertung ist danach fachliche Unterstützung sinnvoll. Für einen typischen WooCommerce-Checkout ohne Sonderentwicklungen dauert ein fokussierter Checkout-Audit meist zwei bis vier Stunden und liefert statt einer langen To-do-Liste einen fertigen Prüfbericht. Diese Prüfung übernehmen wir auf Wunsch, eine Übersicht steht unter unseren Leistungen.

Was ist der häufigste einzelne Fehler im Checkout?

Fehlende oder nur über einen Platzhalter angedeutete Formular-Labels. Unsere Auswertung von 157 Shop-Startseiten zeigt, wie verbreitet das ist: Von den 134 Seiten mit prüfbaren Eingabefeldern hatte gut jede dritte bis zweite (40 Prozent) mindestens ein Feld ohne programmatisch verknüpftes Label, gemessen an den sichtbaren Feldern als Stellvertreter für die Formularqualität des Gesamtshops. Der Platzhaltertext ist kein Ersatz, er verschwindet beim Tippen und wird von Screenreadern nicht immer als Feldname erkannt. Ein <label for="..."> mit passender id am Input kostet keine Entwicklungszeit und löst das Problem dauerhaft.

Fallen externe Zahlungs-Widgets unter meine Pflicht?

Ja. Als Dienstleistungserbringer (§ 2 Nr. 4 BFSG) verantworten Sie nach § 3 Abs. 1 BFSG den gesamten Kaufprozess, auch eingebettete iframes von PayPal, Klarna oder anderen Anbietern. Fragen Sie Anbieter nach ihren Accessibility-Statements und testen Sie die Widgets konkret in Ihrem Shop, nicht nur theoretisch am Anbieter-Demo.