Zahlungsarten barrierefrei im Online-Shop: PayPal, Klarna, Kreditkarte ohne Checkout-Reibung

Viele Shops verlieren Bestellungen nicht im Warenkorb, sondern erst bei der Auswahl der Zahlungsart. Sobald Payment-Logos, eingebettete Provider-Fenster oder Pflicht-Checkboxen per Tastatur, Screenreader oder Mobilgeraet holprig werden, bricht der Kunde kurz vor dem Kauf ab.

Wo Payment-Flows regelmaessig scheitern

• Logos statt echter Beschriftung: Nutzer sehen PayPal oder Klarna, Screenreader aber nur leere Buttons.
• Custom Tiles ohne Fokus: Die aktive Zahlungsart ist per Tastatur nicht erkennbar.
• Provider-Overlays: Pop-ups oder iFrames oeffnen sich, ohne dass der Fokus sauber mitwandert.
• Pflicht-Checkboxen ohne Kontext: AGB, Datenschutz oder Lastschriftzustimmung sind unklar verknuepft.
• Fehler erst nach Redirect: Abgelehnte Zahlungen enden auf einer diffusen Fehlseite ohne klaren naechsten Schritt.

Die 5 Pflichtpruefungen fuer barrierefreie Zahlungsarten

1. Jede Zahlungsart braucht einen echten Namen

Der sichtbare Name der Zahlungsart muss auch technisch vorhanden sein. Ein Logo allein reicht nicht. Nutzer muessen hoeren und sehen koennen, ob sie PayPal, Kreditkarte, Rechnung oder Klarna auswaehlen.

2. Auswahlgruppen semantisch korrekt bauen

Zahlungsarten gehoeren in eine klare Radio-Group mit beschrifteter Ueberschrift. Wer nur div-Kacheln klickbar macht, verliert schnell Tastatur- und Screenreader-Nutzer.

3. Fokus bei Redirects und Modals sichern

Wenn der Zahlungsanbieter ein Overlay oder eine externe Maske oeffnet, muss der Fokus sauber uebergeben und nach dem Schliessen zurueckgefuehrt werden. Sonst landen Nutzer im Nirgendwo.

4. Fehler konkret am Problemfeld zeigen

Eine abgelehnte Kreditkarte oder fehlende Zustimmung darf nicht nur als globaler roter Balken erscheinen. Nutzer brauchen Klartext direkt am betroffenen Bereich, sonst versuchen sie denselben Schritt wieder und springen ab.

5. Ruecksprung in den Checkout pruefen

Wenn ein Payment fehlschlaegt, muss der Weg zurueck in den Checkout stabil bleiben. Warenkorb, Adresse und Versandoptionen duerfen nicht verloren gehen.

WCAG-Hotspots auf der Payment-Stufe

• 1.3.1 Info and Relationships: Zahlungsoptionen und Pflicht-Hinweise sind technisch nicht sauber gruppiert.
• 2.1.1 Keyboard: Payment-Auswahl oder eingebettete Provider sind nicht vollstaendig tastaturbedienbar.
• 2.4.3 Focus Order: Der Fokus springt bei Modals oder Redirects unlogisch.
• 2.4.7 Focus Visible: Nutzer sehen nicht, welche Zahlungsart gerade aktiv ist.
• 3.3.1 Error Identification: Zahlungsfehler bleiben zu vage und kosten Abschluesse.

Schneller Praxistest fuer Shop-Betreiber

1. Jede Zahlungsart einmal nur mit Tastatur bis zum letzten Klick durchtesten.
2. PayPal, Rechnung und Kreditkarte jeweils mit absichtlichem Fehler simulieren.
3. Auf Mobilgeraeten pruefen, ob Modals und externe Provider-Fenster sauber lesbar bleiben.
4. Kontrollieren, ob AGB-/Datenschutz-Checkboxen sichtbar beschriftet sind.
5. Startseite und Checkout mit dem kostenlosen BFSG-Scanner vorpruefen.

Quick Wins fuer diese Woche

Wenn Sie nur drei Dinge priorisieren, machen Sie die Zahlungsart-Beschriftungen eindeutig, pruefen Sie den Fokus in Payment-Modals und schreiben Sie echte Fehlermeldungen fuer abgelehnte Zahlungen. Genau dort verschwinden haeufig kaufbereite Nutzer.

Ratenkauf und Rechnungskauf: Zusatzformulare barrierefrei gestalten

Sobald ein Kunde Ratenkauf oder Kauf auf Rechnung wählt, öffnen sich meist zusätzliche Formulare: Geburtsdatum, Personalausweisnummer, Bonitätsprüfung oder eine Weiterleitung zu einem externen Finanzierungspartner. Diese Zusatzschritte werden im Test häufig übersehen, weil sie erst nach der eigentlichen Zahlartauswahl erscheinen und deshalb seltener geprüft werden als der Hauptcheckout.

Jedes zusätzliche Eingabefeld braucht dieselbe Sorgfalt wie die Standardfelder im Checkout: eine sichtbare Beschriftung, ein klar erkennbares Pflichtfeld-Kennzeichen und eine Fehlermeldung, die direkt am Feld erscheint statt nur oben auf der Seite. Bei Datumsfeldern für das Geburtsdatum ist ein einfaches Texteingabefeld mit erklärtem Format oft zugänglicher als ein grafischer Kalender, der zusätzlich noch Tastaturnavigation und Screenreader-Ansagen korrekt umsetzen müsste.

Wird die Bonitätsprüfung oder der Ratenkauf über einen externen Anbieter abgewickelt, öffnet sich häufig ein eingebettetes Fenster oder eine neue Ebene innerhalb der Seite. Genau wie bei anderen Payment-Overlays muss der Tastaturfokus beim Öffnen in dieses Fenster wandern und beim Schließen wieder zur auslösenden Stelle zurückspringen. Bleibt der Fokus im Hintergrund hängen, navigieren Screenreader-Nutzer blind durch eine Seite, die für sie unsichtbar unter dem Overlay liegt.

Ablehnungen bei der Bonitätsprüfung sind ein besonders sensibler Moment. Die Meldung sollte sachlich und verständlich erklären, dass die gewählte Zahlungsart aktuell nicht möglich ist, und einen Weg zu einer Alternative aufzeigen, statt den Kunden mit einer kryptischen Fehlermeldung oder einem kommentarlosen Abbruch zurückzulassen. Wer stattdessen direkt zur Zahlartauswahl zurückführt, ohne bereits eingegebene Adress- und Warenkorbdaten zu verlieren, verhindert einen kompletten Neustart des Bestellvorgangs und damit einen wahrscheinlichen Kaufabbruch.

Mobile Payment-Wallets und Barrierefreiheit

Apple Pay, Google Pay und ähnliche Wallet-Lösungen wirken auf den ersten Blick barrierefrei, weil sie auf die Bedienhilfen des jeweiligen Betriebssystems zurückgreifen. Das stimmt nur teilweise: Das Zahlungsfenster selbst folgt tatsächlich den Accessibility-Standards von iOS oder Android, aber der Weg dorthin liegt vollständig in der Verantwortung des Shops.

Der Wallet-Button muss wie jedes andere Bedienelement per Tastatur oder Sprachsteuerung erreichbar sein und eine eindeutige Bezeichnung tragen, die vorgelesen werden kann. Reine Bild-Buttons ohne technischen Namen, die nur über ihr Logo erkennbar sind, führen dazu, dass Screenreader lediglich „Schaltfläche“ ohne weitere Information ankündigen. Nutzer wissen dann nicht, welche Zahlungsart sich hinter dem Button verbirgt, bevor sie ihn aktivieren.

Sobald das Wallet-Fenster sich öffnet, verlässt die Interaktion den eigentlichen Shop und läuft im systemeigenen Zahlungsdialog weiter. Wichtig für den Shop ist, was danach passiert: Bricht der Kunde die Zahlung im Wallet ab, muss die Rückkehr in den Shop sauber funktionieren, mit erkennbarem Status und ohne verlorene Warenkorbinhalte. Ein Wallet-Abbruch darf nicht dieselbe Wirkung haben wie ein technischer Fehler, bei dem der Kunde von vorn beginnen muss.

Für kleinere Bildschirme, auf denen Wallet-Zahlungen besonders häufig genutzt werden, kommt eine zusätzliche Anforderung dazu: Der Button darf nicht so klein oder so dicht neben anderen Elementen platziert sein, dass er versehentlich falsch getroffen wird. Ausreichend große Klickflächen mit genügend Abstand zu Nachbarelementen helfen nicht nur Nutzern mit motorischen Einschränkungen, sondern reduzieren generell Fehlklicks auf dem Weg zur Zahlung.

Testen mit echten Nutzern statt nur mit Tools

Automatisierte Scanner finden zuverlässig fehlende Labels, niedrige Kontraste oder doppelte IDs. Was sie nicht erkennen, ist, ob eine Zahlungsstrecke sich für einen Menschen, der tatsächlich mit Tastatur oder Screenreader arbeitet, sinnvoll bedienen lässt. Diese Lücke lässt sich nur durch Tests mit echten Nutzern schließen.

Für den Einstieg reicht oft schon ein moderierter Test mit zwei oder drei Personen, die regelmäßig mit unterstützender Technologie arbeiten. Wichtig ist, sie den kompletten Zahlungsvorgang selbstständig durchklicken zu lassen, ohne einzugreifen oder Hinweise zu geben. Genau die Stellen, an denen die Testperson zögert, noch einmal zurückgeht oder den Vorgang abbricht, zeigen die eigentlichen Barrieren – oft ganz andere als die, die ein Scanner gemeldet hätte.

Wer keinen direkten Zugang zu Testpersonen mit Behinderung hat, kann über spezialisierte Testagenturen oder Selbsthilfeorganisationen Kontakt aufnehmen. Auch eine Zusammenarbeit mit lokalen Blinden- und Sehbehindertenverbänden funktioniert in der Praxis gut und liefert Rückmeldungen, die weit über technische Konformität hinausgehen.

Zwischen den größeren moderierten Tests lohnt sich ein einfacher interner Tastatur-Test als Routine: Ein Teammitglied durchläuft den gesamten Zahlungsvorgang ausschließlich mit Tab, Umschalt-Tab, Leertaste und Eingabetaste, ohne die Maus anzufassen. Bleibt der Fokus irgendwo hängen, verschwindet er unsichtbar, oder lässt sich ein Element nicht erreichen, ist das ein verlässliches Warnsignal, das schon vor dem nächsten großen Nutzertest behoben werden kann.

Die Kombination aus automatisiertem Scan, internem Tastatur-Test und punktuellen Nutzertests deckt in der Praxis deutlich mehr ab als jede einzelne Methode allein und verhindert, dass sich ein Shop auf ein grünes Scanner-Ergebnis verlässt, das die eigentlichen Kaufhürden gar nicht sieht.

Häufig gestellte Fragen