Zum Inhalt springen
BFSG-Compliance seit 2025

Barrierefreier Checkout: der letzte Meter, auf dem Bestellungen verloren gehen

Diese Seite behandelt ausschließlich den Bestell- und Bezahlprozess: Warenkorb, Adressformular, Versand- und Zahlungsauswahl, Fehlerdialoge, Anmeldung und Bestellbestätigung. Wir prüfen jeden Schritt mit Tastatur und Screenreader gegen die WCAG 2.2 AA und beheben die Befunde im bestehenden Code — Prüfung ab 2.480 € netto.

Checkout-Prüfung ab 2.480 € netto Bußgeld bis 100.000 € (BFSG §37) Diese Seite erfüllt selbst WCAG 2.2 AA

3.3

WCAG-Abschnitt Eingabehilfe — der Kern des Checkouts

6

Schritte vom Warenkorb bis zur Bestellbestätigung

28.06.2025

BFSG-Pflicht in Kraft

50+

barrierefreie Projekte

Der Bestellprozess ist der rechtlich heikelste Teil Ihres Shops

Das Barrierefreiheitsstärkungsgesetz (BFSG) verpflichtet Onlineshops im Verbrauchergeschäft zur Barrierefreiheit nach WCAG 2.2 AA. Betroffen ist ausdrücklich auch der Abschluss eines Vertrags — also genau der Checkout. Bei Verstößen drohen Anordnungen der Marktüberwachung und Bußgelder von bis zu 100.000 € (BFSG §37). Dass Barrierefreiheit im Alltag funktioniert, zeigen wir am eigenen Beispiel: Diese Seite erfüllt selbst WCAG 2.2 AA.

Ein Shop verdient erst Geld, wenn die Bestellung abgeschickt ist. Genau dort scheitern Menschen, die auf assistive Technologien angewiesen sind, am häufigsten: an einer Fehlermeldung, die nur rot eingefärbt ist, an einem Zahlungsformular in einem fremden iFrame, an einem Bestell-Button, der per Tastatur nicht erreichbar ist. Diese Seite behandelt deshalb ausschließlich den Kaufabschluss — vom Warenkorb bis zur Bestellbestätigung samt Beleg. Wie wir einen kompletten Shop technisch barrierefrei machen, also auch Kategorien, Suche, Filter und Produktseiten, beschreibt die Seite zum barrierefreien Online-Shop. Welche BFSG-Pflichten für Händler, Marktplätze und den Omnichannel-Handel insgesamt gelten, ordnet die Seite barrierefreier E-Commerce ein. Den rechtlichen Rahmen liefert das Barrierefreiheitsstärkungsgesetz.

Ein Feld im Bezahlvorgang — vorher und nachher

Barrierefreier Checkout · WCAG 2.2 AA
Aus einer Checkout-Barriere wird ein bedienbarer Kaufabschluss
Genau die Stelle, an der Bestellungen abbrechen — Adressfeld im Bezahlvorgang
Vorher · Checkout3 kritische Barrieren
E-Mail
Kein Label — Screenreader liest nur „Eingabefeld“
Kontrast 2,4:1 — unter 4,5:1 (WCAG 1.4.3)
Fehler nur rot markiert, ohne Text
VS
Nachher · CheckoutWCAG 2.2 AA
E-Mail-Adresse *
Sichtbares Label, programmatisch verknüpft
Kontrast 5,1:1 — AA erfüllt
Fehlertext per aria-describedby, Fokus gesetzt
Konformität Bestellstrecke · vorher61 %
Konformität Bestellstrecke · nachher92 %
Checkout-Prüfungab 2.480 € netto
Geprüft mit NVDA und VoiceOverpriorisierte Befundliste
Beispielhafte Gegenüberstellung eines Adressfelds im Checkout vor und nach der Behebung. Darstellung illustrativ, die Konformitätswerte stammen nicht aus einem konkreten Kundenprojekt.

Checkout und Bezahlprozess prüfen

ab 2.480 € Festpreis netto
  • Warenkorb, Adressformular, Versand, Zahlung, Prüfen, Bestätigung
  • Test mit NVDA und VoiceOver sowie reiner Tastaturbedienung
  • Fehlerdialoge und Validierung nach WCAG 3.3 im Detail geprüft
  • Einstieg mit dem BFSG-Quick-Check bereits ab 490 €

Preis für das WCAG-2.2-AA-Audit einer KMU-Website bis 30 Seiten inklusive Bestellstrecke. Reine Bestellstrecken ohne restlichen Shop kalkulieren wir nach Zahl der Schritte und Zahlarten. Alle Zahlen im Überblick auf der Seite Preise.

Die sechs Schritte der Bestellstrecke — und was in jedem zu prüfen ist

Der Checkout bündelt die anspruchsvollsten Erfolgskriterien der WCAG 2.2, weil hier fast ausschließlich Formulare, Zustandswechsel und rechtsverbindliche Eingaben zusammenkommen. Maßgeblich ist der Abschnitt 3.3 (Eingabehilfe): Beschriftungen oder Anweisungen (3.3.2), Fehlererkennung (3.3.1), Fehlerbeschreibung mit Korrekturvorschlag (3.3.3) und Fehlervermeidung bei rechtsverbindlichen Transaktionen (3.3.4). Dazu kommen zwei Kriterien, die WCAG 2.2 neu eingeführt hat und die den Bestellprozess unmittelbar treffen: Redundant Entry (3.3.7) verbietet, bereits erfasste Daten ohne Grund erneut abzufragen, und Accessible Authentication (3.3.8) untersagt kognitive Funktionstests bei der Anmeldung, etwa Bilderrätsel ohne Alternative (Quelle: W3C WCAG 2.2). Hinzu kommen die generellen Anforderungen an Tastaturbedienbarkeit (2.1.1), sichtbaren Fokus (2.4.7) und die neue Regel, dass der fokussierte Bereich nicht von Sticky-Elementen verdeckt sein darf (2.4.11).

1. Warenkorb und Mengenänderung

Mengenfelder mit eigenem Label je Position, Entfernen-Buttons mit eindeutigem Bezug zum Artikel statt „Löschen“ dreimal untereinander. Änderungen der Summe werden über eine Live-Region angekündigt, damit Screenreader-Nutzer die Neuberechnung überhaupt bemerken.

2. Adress- und Kontaktdaten

Sichtbare, programmatisch verknüpfte Labels statt Platzhaltertext. Korrekte autocomplete-Attribute, damit gespeicherte Adressen automatisch einsetzbar sind (WCAG 1.3.5). Pflichtfelder werden nicht nur mit einem Sternchen markiert, sondern auch programmatisch ausgezeichnet.

3. Versandart und Lieferoptionen

Versandarten als echte Radio-Gruppe mit Fieldset und Legend, per Pfeiltasten bedienbar. Preis- und Lieferzeitänderungen werden beim Wechsel angekündigt. Zeitfenster-Auswahlen und Kalender-Widgets müssen ohne Ziehbewegung bedienbar sein (WCAG 2.5.7).

4. Zahlungsauswahl

Zahlarten als Radio-Gruppe, nicht als klickbare Kacheln ohne Rolle. Nachgeladene Felder — etwa IBAN bei Lastschrift — werden angekündigt und erhalten den Fokus in logischer Reihenfolge. Eingebettete Anbieterformulare prüfen wir gesondert.

5. Prüfen und bestellen

Die Übersicht vor dem Absenden erfüllt WCAG 3.3.4: Alle Angaben sind prüfbar, korrigierbar und bestätigungspflichtig. Der Bestell-Button trägt eine eindeutige, aus sich heraus verständliche Beschriftung und ist per Tastatur erreichbar, ohne von einem Sticky-Footer verdeckt zu werden.

6. Bestätigung und Beleg

Die Bestätigungsseite kündigt den Erfolg über eine Statusmeldung an, nicht nur über ein grünes Häkchen. Bestellnummer und Zusammenfassung stehen als Text zur Verfügung. Rechnungs-PDFs müssen ebenfalls zugänglich sein — siehe PDF-Barrierefreiheit.

Fehlerdialoge: der häufigste Grund für einen Abbruch

Ein sehender Nutzer orientiert sich visuell: Er sieht den roten Rahmen um ein fehlerhaft ausgefülltes Feld und den Fehlertext darunter. Ein Screenreader-Nutzer bekommt davon nichts mit, wenn das Feld nicht programmatisch mit der Fehlermeldung verknüpft ist. Ein Nutzer mit motorischen Einschränkungen, der nur die Tastatur verwendet, kann den Bestell-Button nicht erreichen, wenn er außerhalb der Tab-Reihenfolge liegt. Und wer die Seite auf 200 Prozent vergrößert, verliert die Fehlermeldung aus dem Blick, wenn sie am Seitenanfang steht, der Fokus aber am Seitenende bleibt. Fehlerbehandlung ist deshalb kein Detail des Bestellformulars, sondern seine kritischste Funktion.

Wir setzen Fehlerbehandlung im Checkout nach einem festen Muster um. Jedes Formularfeld erhält ein programmatisch verknüpftes Label. Pflichtfelder werden über aria-required und einen sichtbaren Hinweis gekennzeichnet, nicht allein über Farbe. Fehlermeldungen werden über aria-describedby mit dem jeweiligen Feld verknüpft, in Textform ausgegeben und zusätzlich in einer Fehlerzusammenfassung am Formularbeginn gebündelt, deren Einträge auf das betroffene Feld verlinken. Nach einem Validierungsfehler wandert der Fokus automatisch auf den ersten fehlerhaften Eintrag. Die Fehlermeldung benennt nicht nur das Problem, sondern auch den Korrekturweg — „Bitte geben Sie eine E-Mail-Adresse mit @ an“ statt „Ungültige Eingabe“. Wie das technisch umgesetzt wird, vertieft der Beitrag zu barrierefreien Fehlermeldungen.

Gastbestellung, Konto und barrierefreie Anmeldung

Vor dem eigentlichen Bezahlvorgang steht in vielen Shops eine Hürde, die WCAG 2.2 erstmals ausdrücklich adressiert: die Anmeldung. Erfolgskriterium 3.3.8 (Accessible Authentication, Stufe AA) verlangt, dass kein Authentifizierungsschritt einen kognitiven Funktionstest erfordert, sofern keine Alternative angeboten wird. Bilderrätsel, Rechenaufgaben und das Abtippen verzerrter Zeichenfolgen fallen darunter. Ebenso problematisch ist es, das Einfügen aus der Zwischenablage im Passwortfeld zu unterbinden, weil damit Passwortmanager ausgehebelt werden. Beides begegnet uns in Audits regelmäßig — und beides ist mit überschaubarem Aufwand zu beheben.

Praktisch heißt das: Passwortfelder erlauben Einfügen und Autofill und tragen die passenden autocomplete-Werte. Zwei-Faktor-Codes werden ebenfalls per autocomplete unterstützt, damit sie nicht abgetippt werden müssen. Wo ein Spam-Schutz nötig ist, setzen wir auf Verfahren, die keine kognitive Leistung verlangen — etwa serverseitige Prüfungen oder unsichtbare Verfahren mit dokumentierter Alternative. Und weil die schnellste barrierefreie Anmeldung die ist, die entfällt, empfehlen wir eine vollwertige Gastbestellung ohne Kontozwang. Wo ein Konto verpflichtend ist, muss auch die Registrierung selbst den Kriterien genügen. Der Beitrag zur barrierefreien Authentifizierung beschreibt die Varianten im Detail.

Das barrierefreie Adressformular im Detail

Vier Eigenschaften, an denen ein Bestellformular hängt

Das Adressformular ist der längste zusammenhängende Eingabeblock im Checkout. Hier entscheidet sich, ob eine Bestellung ohne Maus und ohne Blick auf den Bildschirm abgeschlossen werden kann. Wir bauen es so um, dass Label, Autofill, Fehlerbezug und Fokusführung zusammenspielen, statt sich gegenseitig zu blockieren.

  • Sichtbares Label je Feld, programmatisch verknüpft (WCAG 3.3.2)
  • autocomplete-Attribute für Name, Straße, PLZ, Ort und E-Mail (WCAG 1.3.5)
  • Fehlertext am Feld plus verlinkte Fehlerzusammenfassung (WCAG 3.3.1, 3.3.3)
  • Bereits erfasste Daten werden nicht erneut abgefragt (WCAG 3.3.7)
Fehlerzusammenfassung
1 Eingabe prüfen: E-Mail-Adresse
Eintrag verlinkt direkt auf das betroffene Feld
Lieferadresse
Vorname *
Straße und Hausnummer *
E-Mail-Adresse *
„Bitte geben Sie eine E-Mail-Adresse mit @ an.“
Fokus springt nach der Prüfung auf das erste fehlerhafte Feldautocomplete aktiv

Zahlarten und ihre typischen Barrieren

Karteneingabe im fremden iFrame

Kartenfelder liegen fast immer im iFrame eines Zahlungsdienstleisters. Typische Befunde: iFrame ohne title-Attribut, Felder ohne Label, Fehlerausgabe nur farblich. Wir prüfen jedes eingebettete Feld, dokumentieren, was außerhalb Ihres Codes liegt, und stimmen Änderungen mit dem Anbieter ab.

Rechnung und Lastschrift

Bei Auswahl werden zusätzliche Felder nachgeladen — IBAN, Kontoinhaber, Mandatstext. Diese dynamischen Blöcke müssen angekündigt werden und den Fokus in logischer Reihenfolge erhalten. Der Mandatstext gehört als lesbarer Text in die Seite, nicht als Grafik oder als nicht scrollbares Overlay.

Weiterleitungs- und Wallet-Verfahren

Bei Verfahren mit Sprung auf eine externe Seite bricht der Kontext. Der Rücksprung muss den Fokus sinnvoll setzen und den neuen Status ansagen. Öffnet sich ein Popup, braucht es einen erkennbaren Hinweis vorab und einen Weg zurück ohne Maus.

Ratenkauf und Bonitätsabfragen

Diese Strecken enthalten häufig lange Bedingungstexte, Zeitlimits und zusätzliche Identitätsprüfungen. Zeitbegrenzungen müssen verlängerbar sein (WCAG 2.2.1), Bedingungen als strukturierter Text vorliegen und Identitätsprüfungen dürfen keinen kognitiven Funktionstest verlangen.

Verantwortung für externe Zahlungsanbieter

Die Zahlungsabwicklung ist der Bereich, in dem Shop-Betreiber am stärksten auf Dritte angewiesen sind. Eingebettete Zahlungsformulare können eigene Barrierefreiheitsprobleme mitbringen: iFrames ohne zugänglichen Titel, Kreditkartenfelder ohne Labels, Prüfverfahren, die sich mit einem Screenreader nicht lösen lassen. Rechtlich entbindet Sie das nicht: Das BFSG richtet sich an den Anbieter der Dienstleistung, und das sind gegenüber Ihren Kunden Sie. Wir prüfen deshalb die Zugänglichkeit der integrierten Anbieter, dokumentieren Barrieren, die außerhalb Ihrer Kontrolle liegen, und empfehlen bei Bedarf alternative Zahlungswege.

Wo möglich, konfigurieren wir die Zahlungsanbieter für maximale Zugänglichkeit: korrektes Labeling der eingebetteten Felder, barrierefreie Fehlerbehandlung und zugängliche Bestätigungsseiten. Bleibt eine Einschränkung bestehen, gehört sie transparent in die Barrierefreiheitserklärung — zusammen mit einem alternativen Weg zum Vertragsabschluss, etwa telefonisch oder per E-Mail. Diese Dokumentation ist kein Eingeständnis, sondern genau das, was BFSG §14 verlangt. Wie eine belastbare Erklärung aufgebaut ist, steht auf der Seite zur Barrierefreiheitserklärung.

Eingebettete Zahlungsformulare unter der Lupe

Wo iFrames die Barrierefreiheit gefährden

Zahlungsformulare von Drittanbietern liegen oft in einem iFrame, dessen Zugänglichkeit Sie nicht selbst steuern. Wir prüfen jedes eingebettete Feld, dokumentieren Barrieren, die außerhalb Ihrer Kontrolle liegen, und sichern den Kaufabschluss über einen barrierefreien Alternativweg ab.

  • iFrame-Titel und Feld-Labels systematisch geprüft
  • Prüfverfahren ohne Screenreader-Alternative erkannt und benannt
  • Fehlerausgabe des Anbieters auf Screenreader-Tauglichkeit getestet
  • Transparente Dokumentation in der Barrierefreiheitserklärung
iFrame · Zahlungsanbieter (Fremdcode)Fremd-iFrame
Kartennummer — Label vorhanden
Gültig bis — Label vorhanden
Prüfziffer — Label fehlt, im Bericht notiert
Prüfverfahren ohne Screenreader-Alternative
Alternativweg: Bestellung per Telefon oder E-Mail abschließbar
Befund fließt in die Barrierefreiheitserklärung eindokumentiert

Drei Prüfmittel, mit denen wir jeden Checkout-Schritt durchgehen

Screenreader-Durchlauf

Wir legen einen Artikel in den Warenkorb und bestellen mit NVDA und VoiceOver bis zur Bestätigungsseite — und hören dabei, was tatsächlich angesagt wird, statt nur den Code zu lesen.

Tastatur-Durchlauf

Die gesamte Bestellstrecke wird ausschließlich per Tab-, Pfeil- und Eingabetaste durchlaufen, inklusive bewusst falscher Eingaben, um Fokusfallen und unerreichbare Buttons aufzudecken.

Vergrößerung 200 %

Formulare und Zusammenfassungen werden auf 200 Prozent vergrößert, um Überlappungen, abgeschnittene Fehlertexte und von Sticky-Leisten verdeckte Felder sichtbar zu machen (WCAG 1.4.4, 2.4.11).

Unser Prüfablauf für Bestellstrecke und Bezahlung

Wir erfassen, wie viele Schritte Ihr Checkout hat, welche Zahlarten aktiv sind, ob es einen Gastbestellweg gibt und welche Anbieter eingebettet sind. Daraus ergibt sich der Prüfumfang — nicht aus der Zahl der Produkte im Katalog.

Wir bestellen einmal komplett bei Ihnen — mit Screenreader

In über 50 barrierefreien Projekten (Projekterfahrung) haben wir Bestellstrecken vom Warenkorb bis zur Bestätigungsseite zugänglich gemacht. Lassen Sie uns zeigen, wo Ihr Checkout heute steht.

Abbruchgründe, die nichts mit dem Preis zu tun haben

Wenn über Kaufabbrüche gesprochen wird, geht es meist um Versandkosten, Lieferzeiten oder fehlende Zahlarten. Für Menschen, die auf assistive Technologien angewiesen sind, liegt der Abbruchgrund oft eine Ebene darunter: Das Formular sagt nicht, was falsch ist. Der Bestell-Button ist per Tastatur nicht erreichbar. Das Zeitlimit im Zahlungsschritt läuft ab, bevor die Eingabe fertig ist. In Deutschland leben rund 7,8 Millionen (Statistisches Bundesamt, 2023) schwerbehinderte Menschen, dazu kommen Millionen mit temporären oder altersbedingten Einschränkungen. Diese Gruppe bricht nicht ab, weil sie nicht kaufen will, sondern weil sie nicht kaufen kann.

Der zweite Effekt ist breiter: Ein Checkout, der ohne Maus, mit vergrößerter Schrift und mit klaren Fehlermeldungen funktioniert, funktioniert auch für alle anderen besser. Sinnvolle autocomplete-Attribute sparen jedem Kunden Tipparbeit. Eine verständliche Fehlermeldung statt „Ungültige Eingabe“ verhindert Rückfragen im Support. Eine Übersicht, die vor dem Absenden alle Angaben zeigt, senkt Fehlbestellungen und Retouren. Barrierefreiheit im Checkout ist damit selten nur eine Compliance-Ausgabe, sondern zugleich eine Investition in die Qualität der Bestellstrecke.

Damit dieser Zustand erhalten bleibt, sollte das Team wissen, worauf es ankommt. Unsere Schulungen vermitteln Entwicklung und Redaktion, wie neue Checkout-Funktionen von Anfang an zugänglich gebaut werden. Für die laufende Absicherung nach der Umsetzung gibt es das BFSG-Monitoring, das Regressionen nach Updates meldet, bevor sie Bestellungen kosten.

Weiterlesen und weiterklicken

Den Kaufabschluss im Zusammenhang beschreibt der Beitrag zum barrierefreien Checkout im E-Commerce. Wie Formulare und ihre Validierung technisch sauber aufgebaut werden, vertieft der Beitrag zu barrierefreien Formularen. Warum Anmeldeverfahren mit Rätselaufgaben nicht konform sind, klärt der Beitrag zur barrierefreien Authentifizierung. Und weil im Checkout viele Bausteine von außen kommen, lohnt der Beitrag zu Drittanbieter-Widgets und BFSG-Verantwortung. Für den Shop jenseits der Kasse — Suche, Filter, Produktseiten, Umsetzung im Code — ist die Seite barrierefreier Online-Shop der richtige Einstieg; die Pflichten für Händler insgesamt ordnet barrierefreier E-Commerce ein, eingebettet in Barrierefreiheit nach Branche.

Das Wichtigste in Kürze

  • Der Checkout ist der Bereich mit der höchsten Dichte an WCAG-Kriterien — Abschnitt 3.3 (Eingabehilfe) plus die neuen Kriterien 3.3.7 und 3.3.8 aus WCAG 2.2
  • Fehlerdialoge entscheiden über Abbruch oder Abschluss: Fehlertext am Feld, verlinkte Zusammenfassung, Fokus auf dem ersten fehlerhaften Eintrag
  • Anmeldung ohne kognitiven Funktionstest, Passwortmanager erlaubt, Gastbestellung als einfachster barrierefreier Weg
  • Eingebettete Zahlungsformulare bleiben Ihre Verantwortung gegenüber dem Kunden — prüfen, dokumentieren, Alternativweg anbieten
  • Prüfung der Bestellstrecke im WCAG-2.2-AA-Audit ab 2.480 € netto, Einstieg über den BFSG-Quick-Check ab 490 €

Häufige Fragen zum barrierefreien Checkout

So könnte das Kundenportal von Stadtwerken aussehen

Der Entwurf zeigt Aufbau und Bedienung: kurze Wege zu Zählerstand und Abschlag, ein Formular mit Fehlerhinweis am Feld, Leichte Sprache und Schriftgröße im Kopf. Der Versorger darin ist erfunden.

Entwurf
Kommunaler Versorger

Kundenportal mit Selbstbedienung und Leichter Sprache

Ein Entwurf für ein Stadtwerke-Portal: Zählerstand melden, Abschlag ändern und Umzug eintragen liegen als sechs kurze Wege nebeneinander, das Formular prüft die Eingaben und stellt den Fehler als Text direkt an das Feld. Der Meldeweg bei Störungen steht in vier Schritten da, der Tarifvergleich als Tabelle mit beschrifteten Spalten und Zeilen. Schriftgröße und Leichte Sprache lassen sich im Kopf der Seite umschalten.

Leichte SpracheSchriftgrößeFormularprüfungStörungsmeldung

Exemplarische Layoutentwürfe zur Veranschaulichung. Die gezeigten Betriebe sind erfunden; es handelt sich nicht um Kundenprojekte.

Worum geht es?

Ein Klick genügt — alles Weitere ist freiwillig.

Erzählen Sie kurz vom Projekt

Alle Angaben hier sind freiwillig.

Wann soll es losgehen? (optional)
Grober Budgetrahmen (optional)

Freiwillig — festlegen müssen Sie sich damit nicht.

Wie erreichen wir Sie?

Wir melden uns in der Regel innerhalb eines Werktages.

Mit dem Absenden stimmen Sie der Verarbeitung Ihrer Angaben zur Bearbeitung der Anfrage zu. Details in der Datenschutzerklärung.

Passende Branchen und Regionen