Barrierefreier Checkout & Formulare: die Anleitung für Online-Shops
Kurz gefasst — an der Kasse zahlt sich Barrierefreiheit aus
Eine Lieferadresse eintragen, eine Karte eingeben, ein Konto anlegen, einen Einmalcode tippen: Diese Formulare sind der Ort, an dem ein Online-Kauf gewonnen oder verloren wird. Sind sie schlecht gebaut — ein Label, das verschwindet, ein Fehler, der nur als roter Rahmen erscheint, ein Passwort, das man nicht einfügen kann —, kann ein Kunde mit Behinderung den Kauf schlicht nicht abschließen, und der Warenkorb wird abgebrochen. Das Barrierefreiheitsstärkungsgesetz (BFSG) (EN 301 549 / WCAG 2.1 AA), seit dem 28. Juni 2025 für den E-Commerce verbindlich, verlangt insbesondere:
- ein klares, dauerhaft sichtbares Label an jedem Feld — nicht nur einen Platzhaltertext, der verschwindet (3.3.2, Stufe A);
- den Zweck jedes Feldes deklariert, damit Browser und Passwort-Manager es automatisch ausfüllen können (1.3.5, Stufe AA);
- Eingabefehler erkannt, dem Feld zugeordnet und angekündigt für Screenreader (3.3.1, Stufe A · 4.1.3, Stufe AA);
- eine Prüf- und Korrekturmöglichkeit, bevor eine rechtlich oder finanziell bindende Bestellung bestätigt wird (3.3.4, Stufe AA).
Eine Grenze, die man kennen sollte: barrierefreie Authentifizierung — das Passwort oder den Code einfügen können, kein kognitives Rätsel — sind die Kriterien 3.3.8 und 3.3.7 der WCAG 2.2. Das BFSG richtet sich derzeit über EN 301 549 nach WCAG 2.1, diese beiden sind also dringend empfohlen, aber noch nicht formal Pflicht. Sie umzusetzen bleibt eine der rentabelsten Korrekturen — genau hier häufen sich die Abbrüche.
Ein Geschäft wird an seiner Kasse beurteilt. Ist die Schlange verwirrend, verlangt das Formular Unmögliches oder weist ein Feld einen stillschweigend ab, geben manche Kunden mit vollem Korb auf. Online ist diese Kasse dein Checkout und deine Kontoformulare: Versand, Zahlung, Anmeldung, Einmalcodes. Es ist einer der Orte, an denen Barrieren den größten Schaden anrichten, weil sie blockierend sind: kein gültiges Formular, keine Bestellung. Hier sind die WCAG-Regeln, damit alle durchkommen, was das BFSG genau verlangt und wo die Grenze zu den neueren Empfehlungen der WCAG 2.2 verläuft.
Warum der Checkout so oft ausschließt
Ein Checkout bündelt fast alle Barriere-Fallen auf einmal: viele Felder, Vorgaben (Kartenformat, Postleitzahl), Fehlermeldungen, manchmal einen Anti-Roboter-Test und einen Einmalcode. Für jemanden mit Screenreader ist ein Feld ohne angekündigtes Label nur ein anonymes „Eingabefeld". Für jemanden mit motorischer Behinderung bedeutet ein Passwort oder eine Adresse, die man nicht einfügen kann, langsames, fehleranfälliges Tippen. Für jemanden mit kognitiver Einschränkung ist ein hartes Zeitlimit oder ein CAPTCHA aus verzerrten Buchstaben eine unüberwindbare Mauer. Und weil das Formular der letzte Schritt vor der Zahlung ist, wird jede dieser Barrieren direkt zum abgebrochenen Warenkorb.
Das BFSG stützt sich auf EN 301 549, aufgebaut auf WCAG 2.1 Stufe AA. Für Formulare sind die entscheidenden Kriterien die Grundlagen der Stufen A und AA: 3.3.2 (Beschriftungen oder Anweisungen), 1.3.1 (Info und Beziehungen), 1.3.5 (Eingabezweck bestimmen), 3.3.1 (Fehlererkennung), 3.3.3 (Fehlervorschlag), 3.3.4 (Fehlervermeidung), 4.1.3 (Statusmeldungen), 2.1.1 (Tastatur) und 2.2.1 (Zeitliche Anpassung). WCAG 2.2 hat 2023 zwei checkout-freundliche Kriterien ergänzt — 3.3.7 und 3.3.8 —, die noch nicht Teil des BFSG-Fundaments sind, die wir aber hier behandeln, weil sie die häufigsten Abbrüche beseitigen.
Die 6 Regeln für einen barrierefreien Checkout & barrierefreie Formulare
Ein Platzhaltertext ist kein Label
Jedes Feld — E-Mail, Adresse, Kartennummer, Postleitzahl — muss ein im Code zugeordnetes Label haben (<label for> oder aria-label), das beim Tippen sichtbar bleibt. Der Platzhalter (grauer Text im Feld) genügt nicht: Er verschwindet, sobald man tippt, wird von Screenreadern nicht zuverlässig angekündigt, und sein Kontrast ist oft zu schwach. Nützliche Hinweise (akzeptierte Kartentypen, erwartetes Format) gehören vor das Feld und werden mit aria-describedby verknüpft.
<label for="plz">Postleitzahl</label> über dem Feld; das akzeptierte Format sichtbar und per aria-describedby verknüpft.→ Siehe auch die vollständige BFSG-Checkliste für Online-Shops.
Autofill und Passwort-Manager sind assistive Technik
An Feldern, die Nutzerdaten erfassen, das Attribut autocomplete mit dem richtigen Wert ergänzen: email, name, street-address, postal-code, cc-number für die Zahlung, current-password für die Anmeldung, one-time-code für einen Code. Das ist Kriterium 1.3.5: Es erlaubt Browsern, Passwort-Managern und assistiver Technik, Felder zu erkennen und vorauszufüllen — ein echter Gewinn für Menschen mit motorischen oder kognitiven Behinderungen und weniger Tippfehler für alle. Deaktiviere das Einfügen nie „aus Sicherheitsgründen": Es erzwingt mühsame manuelle Eingabe und bricht Passwort-Manager.
<input autocomplete="postal-code"> an der PLZ, autocomplete="cc-number" am Kartenfeld; Einfügen bleibt überall erlaubt.→ Siehe auch BFSG: was dein Online-Shop tun muss (der vollständige Leitfaden).
Sag, was falsch ist, wo, und kündige es an
Wenn ein Feld ungültig ist oder die Zahlung fehlschlägt, muss die Meldung in Textform vorliegen (nicht nur ein roter Rahmen), dem richtigen Feld zugeordnet sein und wo möglich eine Korrektur vorschlagen (3.3.1, 3.3.3): „Die Postleitzahl muss 5 Ziffern haben." Entscheidend: Da die Meldung nach dem Absenden ohne vollständigen Seitenneuaufbau erscheint, muss sie Screenreadern dynamisch angekündigt werden — über eine Live-Region (role="alert" oder aria-live) —, sonst erfährt eine blinde Person nie, dass ihre Bestellung fehlschlug (4.1.3). Setze den Fokus auf das erste fehlerhafte Feld, damit Tastaturnutzende dort landen.
role="alert" „Deine Karte wurde abgelehnt — prüfe Nummer und Ablaufdatum", sofort angekündigt; Fokus zurück auf das Kartenfeld.Keine unumkehrbare Bestellung ohne Prüfschritt
Bei jeder Bestellung mit Zahlung oder rechtlicher Bindung muss die nutzende Person ihre Angaben vor der endgültigen Bestätigung prüfen, korrigieren oder abbrechen können (Kriterium 3.3.4): eine Bestellübersicht, ein ausdrücklicher Schritt „Bestätigen und bezahlen" oder die Möglichkeit, einen Schritt zurückzugehen, ohne das Eingegebene zu verlieren. Das schützt alle vor einem kostspieligen Ausrutscher und ist besonders entscheidend für Menschen mit kognitiven Behinderungen. Verlange keine Angabe, die im selben Vorgang bereits gemacht wurde (3.3.7 der WCAG 2.2, Redundante Eingabe) — dieselbe Adresse zwischen Schritten neu tippen zu lassen schließt mehr aus, als es schützt.
Gib Zeit — Warenkörbe, Sitzungen und Einmalcodes
Ein Warenkorb, der sich leert, eine Sitzung, die endet, oder ein Zahlschritt, der ausläuft, ist Kriterium 2.2.1 (Zeitliche Anpassung): Ein hartes Limit muss sich abschalten, anpassen oder verlängern lassen, außer es ist wesentlich. Für einen Einmalcode: Lass ihn einfügen und ergänze autocomplete="one-time-code", damit das System ihn automatisch anbietet; lass ein komfortables Zeitfenster und einen „Code erneut senden"-Button. Einen Code auf mehrere Kästchen aufzuteilen ist nur in Ordnung, wenn er sich in einem Zug einfügen und per Tastatur bedienen lässt.
autocomplete="one-time-code" und einem „Erneut senden"-Button.Tabben ohne Fallen, den Fokus sehen, keine unmöglichen Widgets
Das gesamte Formular muss allein mit der Tastatur erreichbar und bedienbar sein, in einer logischen Reihenfolge, ohne Fokus-Falle und mit sichtbarem Fokus (2.1.1, 2.1.2, 2.4.7). Eigene Widgets sind meist die Übeltäter: eine Datumsauswahl, die sich mit der Tastatur nicht öffnet, ein „Land"-Dropdown, das man nicht bedienen kann, ein Karten-iframe, das den Fokus schluckt. Jedes muss ein echtes, beschriftetes Bedienelement bereitstellen. Und halte die Authentifizierung barrierefrei: Passwort oder Code einfügen erlauben, kein kognitives Rätsel (3.3.8 der WCAG 2.2) — heute eher empfohlen als streng verlangt, aber eine der günstigsten Korrekturen mit dem höchsten Ertrag.
→ Siehe auch den BFSG-Test: ist dein Online-Shop barrierefrei? (2 Min.)
Pflicht vs. empfohlen: was das BFSG heute verlangt
| Prüfpunkt | Stufe | BFSG-Status |
|---|---|---|
| Dauerhaftes Label & Anweisungen — 3.3.2 / 1.3.1 | A | Pflicht |
| Feldzweck (autocomplete) — 1.3.5 | AA | Pflicht |
| Fehler erkannt, vorgeschlagen & angekündigt — 3.3.1 / 3.3.3 / 4.1.3 | A · AA | Pflicht |
| Prüfen & korrigieren vor der Bestellung — 3.3.4 | AA | Pflicht |
| Kein unveränderbares Zeitlimit — 2.2.1 | A | Pflicht |
| Tastaturbedienbar, Fokus sichtbar — 2.1.1 / 2.4.7 | A · AA | Pflicht |
| Barrierefreie Authentifizierung — Code einfügen, kein Rätsel (3.3.8) | AA (2.2) | Empfohlen |
| Keine redundante Eingabe — nicht neu tippen lassen (3.3.7) | A (2.2) | Empfohlen |
Wie du deinen eigenen Checkout prüfst
Ein paar konkrete Tests für die Schritte Warenkorb, Versand, Zahlung, Anmeldung und Einmalcode:
- Klicke jedes Label an: landet der Fokus im passenden Feld? (Beweis einer korrekten Zuordnung)
- Probiere Autofill und deinen Passwort-Manager: werden Adress- und Kartenfeld erkannt? Funktioniert das Einfügen?
- Erzwinge einen Fehler (falsche Karte, leere PLZ) und höre mit einem Screenreader: wird die Meldung angekündigt und dem Feld zugeordnet?
- Mach den ganzen Checkout mit der Tastatur: erreichst und bedienst du jedes Element, mit immer sichtbarem Fokus, bis „Bezahlen"?
- Suche den Prüfschritt: kannst du die Bestellung prüfen und korrigieren, bevor sie belastet wird?
Ein Teil davon ist automatisch feststellbar: Ein Scanner meldet ein Feld ohne Label, ein fehlendes autocomplete, unzureichenden Kontrast, ein Strukturproblem. Ob ein Fehler laut angekündigt wird, ob das Einfügen blockiert ist oder ob ein Prüfschritt existiert, erfordert einen echten Durchlauf mit Tastatur und Screenreader. Unser Bericht meldet die feststellbaren Verstöße auf der analysierten Seite und listet die von Hand zu prüfenden Punkte auf.
Führe den automatischen Scan deines Shops durch
DeclareAccess scannt eine Seite deiner Website nach WCAG 2.1 AA, sendet dir einen quantifizierten Bericht der Nichtkonformitäten (Formularbeschriftungen, autocomplete, Kontrast, Struktur…) und erzeugt anschließend das veröffentlichungsfertige Barrierefreiheitsdokument im anwendbaren Muster — deutsch („Informationen zur Barrierefreiheit", § 14 BFSG), englisch, französisch (RGAA), italienisch oder spanisch. Kostenloser Audit, ohne Kreditkarte.
WCAG-Bericht per E-Mail innerhalb von 1 Werktag.
Erhalten. Deine Audit-Anfrage ist gespeichert — du erhältst deinen WCAG-Bericht per E-Mail innerhalb von 1 Werktag.
Häufige Fragen
Kann ein Platzhalter das Label eines Feldes ersetzen?
Nein. Platzhaltertext verschwindet, sobald man tippt, sein Kontrast ist oft zu schwach, und er wird von Screenreadern nicht zuverlässig angekündigt. Kriterium 3.3.2 verlangt ein echtes, im Code zugeordnetes und jederzeit sichtbares Label. Ein Platzhalter kann ein Beispielformat neben dem Label zeigen, nie an seiner Stelle.
Soll ich das Einfügen in Karten- und Passwortfeld wirklich erlauben?
Ja. Das Einfügen „aus Sicherheitsgründen" zu blockieren ist ein falscher Freund: Es hindert Passwort-Manager an der Arbeit, entmutigt also starke Passwörter, und benachteiligt Menschen mit motorischen Behinderungen stark. Ein Passwort oder einen Code einfügen zu können, gehört zur barrierefreien Authentifizierung der WCAG 2.2 (3.3.8): heute vom BFSG eher empfohlen als streng verlangt, aber eine der einfachsten Korrekturen mit dem höchsten Ertrag.
Ist ein Prüfschritt vor der Bestätigung wirklich Pflicht?
Bei Bestellungen mit Zahlung oder rechtlicher Bindung ja — das ist WCAG 3.3.4 (Fehlervermeidung, Stufe AA), Teil des BFSG-Fundaments. Nutzende müssen ihre Angaben vor der endgültigen Bestätigung prüfen, korrigieren oder abbrechen können. Eine Übersichtsseite mit „Ändern"-Links je Zeile und einem ausdrücklichen „Bestätigen und bezahlen"-Button erfüllt es und verringert kostspielige Fehler für alle.
Prüft ein automatischer Scan ein Checkout-Formular?
Teilweise. Ein Werkzeug erkennt ein Feld ohne Label, ein fehlendes autocomplete-Attribut, unzureichenden Kontrast oder ein Strukturproblem. Ob eine Fehlermeldung laut angekündigt wird, ob das Einfügen blockiert ist oder ob ein Prüfschritt existiert, erfordert aber einen echten Durchlauf mit Tastatur und Screenreader. Unser Bericht verbindet die automatisch feststellbaren Verstöße mit der Liste der von Hand zu prüfenden Punkte.
Ist barrierefreie Authentifizierung (WCAG 2.2) vom BFSG verlangt?
Noch nicht formal. Das BFSG stützt sich auf EN 301 549, das derzeit auf WCAG 2.1 ausgerichtet ist. Die Kriterien 3.3.8 (Barrierefreie Authentifizierung) und 3.3.7 (Redundante Eingabe) kamen 2023 mit WCAG 2.2 und sind nicht Teil des aktuellen Fundaments. Es sind aber starke Empfehlungen: Die Normen bewegen sich Richtung 2.2, und diese Kriterien beseitigen die blockierendsten Checkout-Hürden. Sie jetzt umzusetzen ist eine sichere Investition.