Kurz gesagt: Ein barrierefreier Checkout lässt sich vom Warenkorb bis zur Bestellbestätigung allein mit der Tastatur und mit einem Screenreader bedienen. Jedes Feld hat eine sichtbare Beschriftung, Fehler werden benannt und erklärt, Änderungen am Warenkorb werden angesagt, und der Bestellbutton sagt eindeutig, dass jetzt bezahlt wird. Testen Sie jeden Schritt mit echten Bestellungen – eine automatische Prüfung erreicht nur einen Teil davon.
Die Kaufstrecke ist der Teil eines Shops, der unter dem BFSG am meisten zählt. Hier wird die Dienstleistung erbracht, um die es dem Gesetz geht: der Abschluss eines Vertrags. Und hier kostet jede Barriere direkt Umsatz, denn wer den Bestellbutton nicht erreicht, kauft woanders. Dieser Beitrag geht die Strecke Schritt für Schritt durch und endet mit einem Testprotokoll. Was das BFSG sonst von Shops verlangt, steht im Leitfaden für Onlineshops.
Warum der Checkout über den Umsatz entscheidet
Auf einer Produktseite kann ein Kunde eine Barriere umgehen: das Bild nicht sehen, aber den Text lesen; den Filter nicht bedienen, aber die Suche nutzen. Im Checkout gibt es keine Umwege. Jeder Schritt muss gelingen, sonst gibt es keine Bestellung. Deshalb ist die Kaufstrecke die erste Strecke, die Sie prüfen sollten, und die, die Sie nach jedem Update wieder prüfen sollten.
Dazu kommt eine Besonderheit: Checkouts bestehen oft aus Bausteinen verschiedener Hersteller. Das Theme liefert den Warenkorb, ein Plugin die Adressprüfung, der Zahlungsdienstleister die Kartenfelder, ein weiterer Anbieter die Express-Buttons. Jeder dieser Bausteine kann die Strecke unterbrechen.
Warenkorb: Mengen, Gutscheine, Statusmeldungen
Der Warenkorb ist ein kleines Formular mit vielen Zuständen. Prüfen Sie:
- Mengenfelder haben einen Namen, der das Produkt nennt – nicht fünfmal „Menge“. Plus- und Minus-Buttons sind echte Buttons mit Namen wie „Menge von Wanderschuh Alpina erhöhen“.
- Entfernen ist ein Button mit Namen, nicht nur ein Mülleimer-Icon.
- Änderungen werden angesagt. Wenn sich Summe oder Versandkosten nach einer Änderung ohne Neuladen aktualisieren, muss ein Screenreader davon erfahren. Das leistet eine Statusmeldung (4.1.3 Statusmeldungen).
- Gutscheinfelder melden Erfolg und Fehler in Text, nicht nur durch eine grüne oder rote Umrandung.
<p role="status" class="visually-hidden" id="cart-status"></p>// nach erfolgreicher Aktualisierung des Warenkorbs
document.getElementById('cart-status').textContent =
'Warenkorb aktualisiert. Zwischensumme 84,90 Euro.'Der leere Container muss schon beim Laden der Seite im Dokument stehen; erst dann wird eine spätere Textänderung zuverlässig angesagt.
Adresse und Gastbestellung
Adressformulare sind der Ort, an dem die meisten Checkouts scheitern. Die Grundlagen – sichtbare Beschriftungen, Fehlermeldungen, Pflichtfelder – erklärt unser Beitrag Barrierefreie Formulare. Für den Checkout kommen drei Punkte dazu:
- Autocomplete. Name, E-Mail, Straße, Postleitzahl, Ort, Land und Telefon brauchen die passenden
autocomplete-Werte, damit Browser und Hilfstechnik sie ausfüllen können (1.3.5 Eingabezweck bestimmen). - Keine doppelte Eingabe. Die Rechnungsadresse ist standardmäßig gleich der Lieferadresse, und wer sich im Kundenkonto angemeldet hat, muss seine Adresse nicht noch einmal tippen (3.3.7 Redundante Eingabe).
- Gastbestellung ohne Hürden. Eine Pflichtregistrierung mit Passwortregeln und Captcha ist für viele Menschen die erste Wand. Bieten Sie die Gastbestellung gleichwertig an, und wenn es eine Anmeldung gibt, muss sie ohne Merk- oder Rätselaufgabe funktionieren (3.3.8 Barrierefreie Authentifizierung).
<label for="postal">Postleitzahl</label>
<input id="postal" name="postal" autocomplete="shipping postal-code" inputmode="numeric">Versand- und Zahlungsauswahl
Versand- und Zahlungsarten sind fast immer Auswahlgruppen – und fast immer als Kacheln gestaltet. Unter der Gestaltung sollten native Radiobuttons in einer Gruppe mit Legende stecken:
<fieldset>
<legend>Versandart</legend>
<input type="radio" id="ship-std" name="shipping" value="standard" checked>
<label for="ship-std">Standard, 2–4 Werktage, 4,90 Euro</label>
<input type="radio" id="ship-exp" name="shipping" value="express">
<label for="ship-exp">Express, nächster Werktag, 9,90 Euro</label>
</fieldset>Die Beschriftung enthält Preis und Lieferzeit, nicht nur ein Logo. Pfeiltasten wechseln innerhalb der Gruppe, Tab springt zur nächsten Gruppe – so erwarten es Tastaturnutzer. Ändert die Auswahl den Gesamtpreis, gehört das in eine Statusmeldung. Und die Auswahl darf nicht von selbst zur nächsten Seite springen: Eine Änderung des Kontexts beim bloßen Auswählen widerspricht 3.2.2 Bei Eingabe.
Zahlungs-Iframes und Express-Buttons
Kartenfelder kommen meist vom Zahlungsdienstleister, in einem Iframe. Den Inhalt des Iframes gestaltet der Anbieter; Sie verantworten, wie er eingebettet ist:
- Das Iframe hat einen
title, der sagt, was es enthält, etwa „Kreditkartendaten“. Die Regel frame-title prüft das. - Die Tab-Reihenfolge führt in das Iframe hinein und wieder heraus, ohne dass der Fokus verloren geht.
- Fehlermeldungen des Anbieters erscheinen dort, wo das Feld ist, und werden angesagt. Wenn nicht: Fragen Sie den Anbieter nach seiner Dokumentation zur Barrierefreiheit.
Express-Buttons wie PayPal, Apple Pay oder Google Pay kommen ebenfalls von außen. Sie müssen einen zugänglichen Namen haben, mit der Tastatur erreichbar sein und dürfen die eigentliche Kaufstrecke nicht verdrängen. Prüfen Sie, dass der Fokus nach einem abgebrochenen Express-Vorgang wieder im Checkout landet.
Fehler und der Bestellbutton
Kurz vor dem Ende steht die Seite, die rechtlich und praktisch am meisten zählt. Drei Anforderungen treffen hier zusammen:
- Prüfen, bevor es verbindlich wird. Bei Seiten, die eine Zahlung auslösen, muss der Nutzer seine Angaben vor dem Absenden prüfen und korrigieren können – etwa auf einer Übersichtsseite (3.3.4 Fehlervermeidung).
- Fehler verständlich melden. Wenn etwas fehlt – die Zustimmung zu den AGB, ein Pflichtfeld –, wird der Fehler in Text benannt, und der Fokus führt zu ihm.
- Der Bestellbutton. Nach § 312j Abs. 3 BGB muss die Schaltfläche, mit der die Bestellung abgeschickt wird, gut lesbar mit „zahlungspflichtig bestellen“ oder einer entsprechend eindeutigen Formulierung beschriftet sein [2]. Für die Barrierefreiheit heißt das: Der zugängliche Name muss den sichtbaren Text enthalten. Ein
aria-label="Weiter"auf einem Button mit der Aufschrift „Zahlungspflichtig bestellen“ bricht 2.5.3 Beschriftung im Namen – und Sprachsteuerung findet den Button nicht mehr.
<button type="submit" class="btn-order">Zahlungspflichtig bestellen</button>Nach dem Absenden bekommt die Bestätigungsseite einen eindeutigen Titel und eine Überschrift, die den Erfolg nennt. Der Fokus landet auf dieser Überschrift oder am Seitenanfang, nicht irgendwo im Footer.
Zeitlimits und abgelaufene Sitzungen
Viele Checkouts haben Zeitlimits, die niemand bewusst eingeführt hat: eine Sitzung, die nach 15 Minuten abläuft, ein reservierter Warenkorb mit Countdown, eine Zahlungsseite, die nach einer Weile neu geladen werden muss. Wer mit Screenreader, Sprachsteuerung oder Schaltersteuerung einkauft, braucht für dieselbe Strecke oft deutlich länger. 2.2.1 Zeitbegrenzungen anpassbar verlangt, dass solche Limits sich abschalten, anpassen oder verlängern lassen – etwa über einen Hinweis kurz vor Ablauf mit einem Button „Mehr Zeit“. Und wenn eine Sitzung doch abläuft, dürfen die eingegebenen Daten nicht verloren gehen.
Ein Testprotokoll zum Mitnehmen
Gehen Sie die Strecke mit einer echten Testbestellung durch, einmal nur mit der Tastatur und einmal mit einem Screenreader – NVDA unter Windows oder VoiceOver auf dem Mac. Notieren Sie pro Schritt, was funktioniert und was nicht.
- Produkt in den Warenkorb legen, nur mit der Tastatur. Wird der Erfolg angesagt, und wo steht danach der Fokus?
- Im Warenkorb die Menge ändern und einen Artikel entfernen. Haben alle Buttons Namen, und werden neue Summen angesagt?
- Einen ungültigen Gutscheincode eingeben. Wird der Fehler in Text genannt?
- Zur Kasse gehen und als Gast bestellen. Ist die Gastbestellung genauso gut erreichbar wie die Anmeldung?
- Die Adresse eingeben und dabei einmal ein Pflichtfeld leer lassen. Werden Fehler benannt, und springt der Fokus zum Fehler oder zu einer Fehlerübersicht?
- Versand- und Zahlungsart mit den Pfeiltasten wählen. Sind Preis und Lieferzeit Teil der Beschriftung, und bleibt die Seite stehen?
- Kartendaten im Zahlungs-Iframe eingeben. Kommt der Fokus hinein und wieder heraus, und haben die Felder Namen?
- Auf der Übersichtsseite die Angaben prüfen und eine davon ändern. Geht das, ohne alles neu einzugeben?
- Den Bestellbutton suchen. Heißt er „zahlungspflichtig bestellen“, ist er fokussiert sichtbar, und nennt der Screenreader denselben Text?
- Die Bestätigungsseite lesen. Sagt die Überschrift, dass die Bestellung eingegangen ist?
Wiederholen Sie das Protokoll nach jedem Theme-, Plugin- oder Zahlungsanbieter-Update. Für die Shopsysteme im Einzelnen helfen unsere Leitfäden zu Shopware, Shopify und WordPress mit WooCommerce.
Was Reviseberg dabei prüft – und was nicht
Reviseberg crawlt die öffentlich erreichbaren Seiten Ihres Shops und führt auf jeder die axe-core-Regeln aus: fehlende Beschriftungen, Buttons ohne Namen, ungültige autocomplete-Werte, Iframes ohne Titel, zu geringer Kontrast. Der Tastatur-Agent drückt auf der Seite, die Sie als Startseite angeben, Tab, Umschalt+Tab und Escape und zeigt Schritt für Schritt, wohin der Fokus geht, ob er sichtbar ist und ob etwas unerreichbar bleibt – geben Sie ihm etwa Ihre Warenkorb- oder Checkout-Einstiegsseite.
Bei einem Crawl aus Ihrem Konto füllt Reviseberg außerdem die Formulare auf einer Seite je Template mit Testdaten aus – nie mit echten Zahlungsdaten – und schickt sie ab, wobei jedes Absenden abgefangen wird, sodass Ihr Server nichts davon erfährt. Es meldet etwa Felder, deren Zweck kein autocomplete nennt, Beschriftungen, die beim Tippen verschwinden, Fehler, die nicht als Text genannt oder nicht angesagt werden, und gesperrtes Einfügen in Anmeldefeldern. Was Reviseberg nicht tut: Es legt nichts wirklich in den Warenkorb und schickt keine Bestellung ab. Was Ihr Server auf ein Absenden antwortet – seine Fehlermeldungen, der nächste Schritt hinter einem gefüllten Warenkorb –, sieht es nur auf einer Staging-Kopie, für die ein Admin Formularübermittlungen erlaubt hat; die Zahlung selbst nie. Diese Schritte testen Sie mit dem Protokoll oben von Hand.