Den Checkout auf Barrierefreiheit prüfen: Warenkorb, Anmeldung, Eingaben, Fehlermeldungen, Zahlung
6 Min. Lesezeit · DACH
Die meisten Prüfberichte zu Onlineshops sagen wenig über den Kaufprozess, weil sie ihn nie betreten haben. Ein Scan lädt Adressen und misst, was ohne Anmeldung, ohne Warenkorb und ohne Eingabe sichtbar ist. Der Checkout beginnt genau dort, wo das aufhört. Dieser Artikel beschreibt, wie man den Ablauf von der Produktseite bis zur Bestätigung als Kette prüft; er gilt für Shops in Deutschland, Österreich und der Schweiz und ist keine Rechtsberatung.
Redaktion Zugangscheck, veröffentlicht am . Wer dahintersteht
Keine Rechtsberatung. Quellen am Ende des Artikels.
Warum die Startseite den Kaufprozess nicht erfasst
Die Evaluationsmethodik des W3C, WCAG-EM 2.0, behandelt diesen Punkt ausdrücklich. Sie verlangt für die Stichprobe, dass alle Seiten eines vollständigen Prozesses aufgenommen werden: den Einstiegspunkt suchen und einbeziehen, mindestens die übliche Abfolge bis zum Abschluss aufnehmen und auch die Abzweigungen, die häufig genutzt und für den erfolgreichen Abschluss wesentlich sind. Eine Startseite ist keine Abfolge, sondern ein Einstieg.
Der Grund ist nicht formal, sondern praktisch. Ein Prozess ist nur so zugänglich wie sein schwächstes Glied. Wenn neun Schritte fehlerfrei sind und der zehnte eine Auswahl verlangt, die ohne Maus nicht bedienbar ist, ist der Kauf nicht möglich, und die neun sauberen Schritte ändern daran nichts. Die WCAG kennen dafür die Konformitätsbedingung für vollständige Vorgänge: Genügt eine Seite der Kette nicht, gilt die Aussage für keine Seite der Kette.
Hinweis: WCAG-EM 2.0 ist eine W3C Group Note, keine Empfehlung im formalen Sinn. Sie ist die verbreitete Methodik für Prüfberichte, aber kein Rechtstext, und eine Prüfung nach WCAG-EM ist keine Konformitätsbescheinigung.
Die Kette und was an jedem Glied zu prüfen ist
Die Glieder eines Kaufprozesses und der jeweils kritische Prüfpunkt
| Schritt | Kritischer Punkt | Wie prüfen |
|---|---|---|
| Produktseite | Varianten wählen, Menge ändern, Verfügbarkeit ansagen | Nur mit Tastatur wählen; danach hören, ob sich die Änderung im Preis ankündigt |
| Warenkorb | Menge ändern, Position entfernen, Zwischensumme | Nach jeder Änderung: Wohin springt der Fokus, wird die neue Summe angesagt? |
| Anmeldung oder Gastbestellung | Der Weg ohne Konto muss gleichwertig erreichbar sein | Mit Tastatur bis zur Gastbestellung; Fehlermeldung bei falschem Passwort auslösen |
| Adresse und Eingaben | Beschriftungen, Pflichtfelder, Formate, automatisches Ausfüllen | Jedes Feld mit Vorleseprogramm anhören; ein Pflichtfeld leer lassen und absenden |
| Versand und Zahlung | Auswahl per Tastatur, eingebettete Fenster fremder Anbieter | Tabulator durch die Auswahl; in eingebettete Bereiche hinein und wieder heraus |
| Prüfen und Bestellen | Änderungen zurück in frühere Schritte, endgültige Schaltfläche | Zurückspringen und wiederkommen, ohne dass Eingaben verloren gehen |
| Bestätigung | Bestellnummer, nächste Schritte, Seitentitel | Nach dem Absenden hören, was zuerst angesagt wird |
Zwei Glieder fallen in der Praxis am häufigsten durch: die Fehlermeldungen im Adressformular und die Zahlungsauswahl mit eingebetteten Fenstern eines fremden Anbieters. Beide sind Zustände, die ein Scan nicht erreicht.
Zustände, die kein Scan erreicht
Ein Scan kennt Adressen. Ein Kaufprozess kennt Zustände, und die meisten Zustände haben dieselbe Adresse wie der Zustand davor. Fünf Beispiele, die regelmässig ungeprüft bleiben:
- Der Warenkorb mit Inhalt, im Unterschied zum leeren Warenkorb. Erst der gefüllte zeigt Mengenfelder, Entfernen-Schaltflächen und Zwischensummen.
- Das Formular nach einem Fehler. Erst dann gibt es Fehlermeldungen, Kennzeichnungen am Feld und eine Frage, wohin der Fokus springt.
- Der angemeldete Zustand mit gespeicherten Adressen, der andere Bausteine zeigt als der Gastweg.
- Die Zahlungsansicht mit dem eingebetteten Fenster des Zahlungsanbieters, oft ein eigenes Dokument im Dokument.
- Dialoge, die während des Ablaufs aufgehen: Grössenberatung, Gutscheinfeld, Hinweis auf Lieferfristen, Einwilligungsfenster.
Für den letzten Punkt gibt es eine klare Regel aus dem Muster für modale Dialoge des W3C: Beim Öffnen wandert der Fokus in den Dialog, Tabulator und Umschalt mit Tabulator bleiben darin, die Escape-Taste schliesst, und beim Schliessen kehrt der Fokus zu dem Element zurück, das den Dialog geöffnet hat. Wie man das prüft, beschreibt der Artikel «Cookie-Banner und Dialoge mit der Tastatur prüfen».
Ein Befund aus dem Checkout, kommentiert
Der folgende Ausschnitt ist für diesen Artikel gebaut und zeigt den häufigsten Fall: Die Fehlermeldung steht sichtbar am Feld, aber sie ist mit dem Feld nicht verbunden und wird beim Erscheinen nicht angesagt.
Kommentierter Befund an einem selbst erstellten Beispiel-Checkout
| Teil | Inhalt |
|---|---|
| Stelle | Schritt Adresse, Feld Postleitzahl, nach dem Absenden mit leerem Pflichtfeld |
| Ausschnitt | <input id=plz><span class=fehler>Bitte ausfüllen</span> ohne aria-describedby am Feld und ohne Bereich, der die Meldung ansagt |
| Auswirkung | Das Vorleseprogramm sagt beim Betreten des Feldes nur die Beschriftung. Die Nutzerin hört nicht, dass etwas fehlt, und sucht den Grund, warum die Bestellung nicht weitergeht. |
| Korrektur | Der Meldung eine Kennung geben und sie am Feld über aria-describedby verknüpfen; die Meldungen zusätzlich als Liste am Anfang des Formulars ausgeben, jede mit Bezug auf die Beschriftung des Feldes; den Seitentitel auf den Fehlerfall anpassen. |
| Nachprüfung | Pflichtfeld leer absenden, mit Tastatur zum Feld gehen und die Ansage anhören; zusätzlich prüfen, ob der Fokus auf die erste fehlerhafte Stelle gesetzt wird. |
Das Vorgehen folgt dem Tutorial des W3C zu Meldungen in Formularen: Fehler oben auflisten, jede Meldung auf die Beschriftung des betroffenen Feldes beziehen, das Feld über aria-describedby mit der Meldung verbinden und für dynamisch eingeblendete Meldungen einen Bereich mit der Rolle alert verwenden. Der Seitentitel kann Erfolg und Fehler ebenfalls tragen, was Nutzerinnen von Vorleseprogrammen sofort erreicht.
Testvorlage für einen Durchlauf
Ein Durchlauf dauert rund eine Stunde und wird einmal nur mit der Tastatur, einmal mit einem Vorleseprogramm und einmal auf einem schmalen Bildschirm gefahren. Was dabei festgehalten wird, ist immer dasselbe: Schritt, Stelle, was passiert ist, was passieren sollte.
- Umfang festlegen: welcher Shop, welcher Weg, welche Zahlungsart, welche Geräte und Hilfsmittel.
- Einen echten Kauf bis zur Bestätigung durchspielen, nur mit der Tastatur; nach jedem Schritt notieren, wo der Fokus steht.
- Denselben Weg mit einem Vorleseprogramm gehen und mitschreiben, was angesagt wird, besonders nach Änderungen im Warenkorb.
- Fehler absichtlich auslösen: Pflichtfeld leer, falsches Format, falsches Passwort, abgelehnte Zahlung im Testbetrieb.
- Den Weg bei 200 Prozent Zoom und in schmaler Ansicht wiederholen; nichts darf abgeschnitten sein oder waagrecht scrollen.
- Jeden Befund mit Schritt, Stelle, Auswirkung und WCAG-Kriterium notieren und das Protokoll mit Datum und Methode abschliessen.
Was für den elektronischen Geschäftsverkehr gilt
Für Anbieter in Deutschland stellt § 19 der Verordnung zum BFSG zusätzliche Anforderungen an Dienstleistungen im elektronischen Geschäftsverkehr. Dazu gehören Informationen zur Barrierefreiheit der zum Verkauf stehenden Produkte und Dienstleistungen, soweit sie verfügbar sind, und die Anforderung, dass Identifizierungs- und Authentifizierungsmethoden, elektronische Signaturen und Zahlungsdienste wahrnehmbar, bedienbar, verständlich und robust sind.
Der letzte Punkt ist der unbequeme, weil Zahlung und Anmeldung oft von fremden Anbietern kommen. Die Anforderung richtet sich trotzdem an die Dienstleistung, die angeboten wird. Wer einen eingebetteten Bezahlvorgang nutzt, gehört in die Pflicht, ihn zu prüfen und gegebenenfalls einen anderen zu wählen oder einen zugänglichen zweiten Weg anzubieten. Welcher technische Massstab dabei gilt, beschreibt der Artikel «BFSG-Pflicht für Websites».
Ihre Website jetzt prüfen
Der Gratis-Check prüft bis zu fünf Seiten und die verlinkten PDFs im echten Browser und zeigt die wichtigsten Verstösse mit Beispiel und Anleitung. Kein Konto, kein Siegel, keine Rechtsberatung.
Häufige Fragen
Reicht es, wenn der Scan des Shops keine Verstösse meldet?
Nein. Ein Scan erreicht die Zustände nicht, in denen der Kauf stattfindet: gefüllter Warenkorb, Formular nach einem Fehler, angemeldeter Zustand, eingebettete Zahlung. WCAG-EM verlangt ausdrücklich, alle Seiten eines vollständigen Prozesses in die Stichprobe aufzunehmen, vom Einstieg bis zum Abschluss.
Muss ich einen echten Kauf abschliessen, um zu prüfen?
Einmal ja, im Testbetrieb des Zahlungsanbieters oder mit einer Bestellung, die danach storniert wird. Sonst bleibt der letzte Schritt ungeprüft, und gerade die Bestätigungsseite entscheidet, ob eine Nutzerin weiss, dass ihre Bestellung angekommen ist.
Was mache ich, wenn das Zahlungsfenster eines fremden Anbieters Barrieren hat?
Erst messen und den Befund festhalten, dann beim Anbieter melden, dann entscheiden: eine andere Zahlungsart als gleichwertigen Weg anbieten oder den Anbieter wechseln. Die Anforderung nach § 19 BFSGV richtet sich an die angebotene Dienstleistung, nicht nur an die selbst geschriebenen Teile.
Wie viele Seiten gehören in die Stichprobe?
So viele, wie der Prozess hat, und dazu eine strukturierte Auswahl der übrigen Seitentypen. WCAG-EM beschreibt eine strukturierte Stichprobe, die alle häufigen Ansichten und wesentlichen Funktionen abdeckt, dazu eine Zufallsauswahl im Umfang von zehn Prozent der strukturierten Stichprobe.
Wer soll den Durchlauf machen?
Jemand, der den Shop nicht gebaut hat, denn wer ihn gebaut hat, kennt die Wege auswendig und umgeht die Stellen, an denen es klemmt. Ideal ist ein Durchlauf zusätzlich mit Menschen, die täglich mit Tastatur oder Vorleseprogramm arbeiten.
Quellen
Abgerufen am 22.09.2026. Jeder Link öffnet ein neues Fenster.
- W3C: Website Accessibility Conformance Evaluation Methodology (WCAG-EM 2.0) (w3.org, neues Fenster)
- W3C WAI Tutorial: User Notifications in Formularen (w3.org, neues Fenster)
- BFSGV § 19 Zusätzliche Anforderungen im elektronischen Geschäftsverkehr (gesetze-im-internet.de, neues Fenster)
- W3C ARIA Authoring Practices: Dialog (Modal) Pattern (w3.org, neues Fenster)
Weiterlesen
- Cookie-Banner und Dialoge mit der Tastatur prüfen: Erreichbarkeit, Beschriftung, Fokusführung
Wie man ein Einwilligungsfenster mit der Tastatur prüft, warum ein gehaltener Fokus im Dialog erlaubt ist und wo die Tastaturfalle beginnt. Mit Beispiel.
- Prüfprotokoll für Agenturen: Barrierefreiheit nachvollziehbar an Kunden übergeben
Was ein Prüfprotokoll enthält: Umfang, Methode, geprüfte Prozesse, Hilfsmittel, behobene und offene Befunde und die Anforderungen, die niemand geprüft hat.
- BFSG-Pflicht für Websites: wer ab wann betroffen ist
Welche Websites und Onlineshops seit dem 28. Juni 2025 unter das BFSG fallen, was verlangt wird, wer prüft und was ein Verstoss kostet. Mit Quellen.
- Barrierefreiheit testen: was Werkzeuge finden, was nur Menschen sehen
Wie man eine Website auf Barrierefreiheit prüft: automatisch, mit Tastatur, Vorleseprogramm und Zoom. Mit Checkliste und dem, was Software nicht kann.
Stand der Rechtslage: 22.09.2026. Dieser Artikel erklärt, was in Gesetz, Verordnung und Norm steht, und ersetzt keine Rechtsberatung. Bei Zweifeln hilft die Bundesfachstelle Barrierefreiheit oder eine Anwältin.