Accessibility

Barrierefreier Checkout: Vom Warenkorb bis zur Zahlungsbestätigung

20. Februar 2026Zensations

Ein barrierefreier Checkout ermöglicht Kund:innen, Produkte und Varianten auszuwählen, ihre Bestellung zu prüfen, Daten einzugeben und eine Zahlung selbstständig abzuschließen. Entscheidend ist nicht nur das Bestellformular: Auch Warenkorb, Anmeldung, Zahlungsdienst und Bestätigung gehören zur Kaufstrecke. Wenn beispielsweise die Variantenauswahl mit der Tastatur nicht funktioniert oder ein Zahlungsfehler nur rot markiert wird, hilft ein ansonsten gut zugänglicher Bestellbutton nicht weiter.

Prüfen Sie deshalb vollständige Einkaufswege einschließlich Fehlern und Unterbrechungen. Als technisches Ziel eignet sich WCAG 2.2 auf Stufe AA mit allen anwendbaren Kriterien der Stufen A und AA. Die folgenden Beispiele sind hypothetische Prüfszenarien, keine Aussagen über konkrete Shops oder Kund:innenprojekte. Sie zeigen, welche Umsetzung erforderlich ist und welche Beobachtungen eine belastbare Abnahme unterstützen.

1. Prüfrahmen und Verantwortung festlegen

Definieren Sie vor der Umsetzung, welche Wege Ihr Shop tatsächlich anbietet: Gastbestellung, Kundenkonto, Lieferoptionen, Gutscheine und unterschiedliche Zahlungsarten. Dokumentieren Sie außerdem, wo externe Systeme übernehmen. Dazu zählen eingebettete Zahlungsfelder, Weiterleitungen zur Bank und Identitätsprüfungen. Eine Prüfung, die am Übergang zum Zahlungsdienst endet, beantwortet nicht, ob Kund:innen ihren Einkauf abschließen können.

In Österreich gilt das BaFG seit 28. Juni 2025 für erfasste Dienstleistungen, nicht automatisch für jede Website. Bei Dienstleistungen sind Kleinstunternehmen ausgenommen, wenn sie weniger als zehn Personen beschäftigen und entweder höchstens zwei Millionen Euro Jahresumsatz oder höchstens zwei Millionen Euro Jahresbilanzsumme haben. Reine Informationsangebote und ausschließliches B2B sind grundsätzlich kein Verbrauchere-Commerce; die Einordnung eines Kontaktformulars allein ist laut WKO: Barrierefreiheitsgesetz im E-Commerce – FAQ umstritten. Einzelheiten finden Sie in unserem Leitfaden zur barrierefreien Website in Österreich. WCAG und EN 301 549 sind nicht austauschbar; ein technisches Audit ist kein vollständiger Nachweis rechtlicher Compliance.

2. Variantenwahl als Teil des Checkouts verstehen

Ein hypothetischer Einkauf beginnt mit einem Schuh in einer bestimmten Größe und Farbe. Jede Auswahl braucht eine verständliche Bezeichnung, einen erkennbaren Zustand und Tastaturbedienbarkeit. Native Auswahlelemente oder korrekt umgesetzte Radiogruppen sind oft robuster als frei programmierte Kacheln. Farbmuster benötigen zusätzlich Farbnamen. Nicht verfügbare Größen müssen als solche verständlich sein, statt lediglich blasser dargestellt zu werden.

Ändert eine Variante Preis, Verfügbarkeit oder Lieferzeit, müssen diese Informationen vor dem Hinzufügen zum Warenkorb zugänglich sein. Eine kurze Statusmeldung kann relevante Änderungen mitteilen, ohne den Fokus zu verschieben. Prüfen Sie konkret: Lässt sich die gewünschte Variante ohne Maus wählen? Vermittelt der Screenreader Auswahl und Nichtverfügbarkeit? Enthält die hinzugefügte Warenkorbposition anschließend genau diese Variante? Ein visuell gesetztes Häkchen ohne programmatisch erkennbaren Zustand besteht diese Prüfung nicht.

3. Warenkorbänderungen nachvollziehbar machen

Im Warenkorb müssen Produkt, Variante, Menge und Preis eindeutig zusammengehören. Mehrere Schaltflächen mit dem Namen „Entfernen“ sind für sich genommen wenig hilfreich; ihre zugängliche Bezeichnung sollte die jeweilige Position identifizieren. Mengenfelder benötigen Labels und verständliche Grenzen. Nach einer Änderung sollten sowohl die Position als auch die Gesamtsumme konsistent aktualisiert werden. Ein Hintergrundprozess darf nicht unbemerkt einen anderen Preis beim Bestellabschluss verwenden.

Ein hypothetischer Fehler: Nach dem Entfernen eines Artikels springt der Fokus an den Seitenanfang. Die Korrektur besteht nicht nur in einer Erfolgsmeldung. Legen Sie einen sinnvollen nächsten Fokus fest, etwa beim nächsten Artikel oder bei der Überschrift des leeren Warenkorbs. Qualifizierende Statusmeldungen sollen ohne Fokuswechsel programmatisch erfassbar sein; nicht der gesamte Warenkorb muss ständig neu vorgelesen werden. Abnahmebeleg ist eine nachvollziehbare Bedienfolge mit verständlicher Rückmeldung und ohne verlorene Orientierung.

4. Gastbestellung und Dateneingabe vereinfachen

Wenn Sie Gastbestellungen anbieten, sollte dieser Weg neben der Anmeldung klar auffindbar sein. Verstecken Sie ihn nicht als unauffälligen Text unter einer dominanten Kontoerstellung. Erfragen Sie nur Daten, die für den jeweiligen Vorgang benötigt werden, und unterscheiden Sie Pflichtangaben von optionalen Angaben durch Text. Liefer- und Rechnungsadresse brauchen klare Gruppierungen; sichtbare Labels müssen technisch mit ihren Feldern verbunden sein.

Die WAI Forms Tutorial erläutern Beschriftungen, Gruppierung und Rückmeldungen als zusammenhängende Aufgaben. Verwenden Sie passende Eingabezwecke und Autocomplete-Attribute, statt Autofill zu behindern. Bereits im selben Prozess eingegebene Informationen sollten entsprechend WCAG 2.2 nicht unnötig erneut verlangt werden; beachten Sie die vorgesehenen Ausnahmen. Für eine abweichende Rechnungsadresse ist ein gezieltes Aufklappen sinnvoller als ein zweiter vollständiger Adressblock, den alle Kund:innen bearbeiten müssen.

Prüfen Sie mit einer hypothetischen Adresse, die einen langen Straßennamen und eine Türnummer enthält. Bleiben Eingaben nach einem Validierungsfehler erhalten? Akzeptiert das Formular plausible Schreibweisen, statt ausschließlich das eigene Muster? Beschreibt ein Formatbeispiel tatsächlich eine Anforderung? Diese Fragen decken Barrieren auf, die ein Test mit kurzen Musterdaten häufig übersieht.

5. Anmeldung ohne unnötige Gedächtnistests ermöglichen

Kontobasierte Käufe benötigen zugängliche Anmeldung und Wiederherstellung. Passwortmanager, Einfügen aus der Zwischenablage und verständlich beschriftete Passwortanzeigen unterstützen unterschiedliche Nutzungsweisen. Ein hypothetisches Problem sind sechs einzelne Codefelder, die Einfügen verhindern und bei jeder Eingabe den Fokus unvorhersehbar verschieben. Ein zusammenhängendes Feld oder eine sorgfältig implementierte Mehrfeldlösung kann diese Hürde beseitigen.

Das WCAG-Kriterium zur Accessible Authentication (Minimum) begrenzt kognitive Funktionstests, berücksichtigt aber Alternativen, unterstützende Mechanismen und Ausnahmen. Es bedeutet nicht, dass jedes CAPTCHA pauschal verboten wäre. Prüfen Sie den tatsächlich angebotenen Weg einschließlich abgelaufenem Code und Kontowiederherstellung. Sicherheit bleibt erforderlich; sie sollte nicht von einer einzigen sensorischen Fähigkeit oder vom Abschreiben abhängen. Ein zugänglicher Alternativweg muss auffindbar und im realen Ablauf nutzbar sein.

6. Tastatur, Fokus und mobile Vergrößerung zusammen prüfen

Die vollständige Bestellung muss ohne Maus bedienbar sein. Die Fokusreihenfolge soll dem Arbeitsablauf entsprechen, und ein sichtbarer Fokus muss Orientierung ermöglichen. Klebende Kopfzeilen, Cookie-Hinweise oder eine fixe Bestellleiste dürfen das fokussierte Element nach WCAG 2.2 AA nicht vollständig verdecken. Vollständig sichtbarer Fokus ist das bessere Gestaltungsziel, geht aber über diese konkrete Mindestanforderung hinaus.

Ein hypothetischer Versanddialog benötigt einen passenden Anfangsfokus, eine geschlossene Tab-Reihenfolge innerhalb des modalen Dialogs, Schließen per Escape und eine sinnvolle Fokusrückgabe. ARIA-Attribute allein erzeugen dieses Verhalten nicht. Prüfen Sie außerdem Textvergrößerung bis 200 Prozent und Umbruch bei 320 CSS-Pixeln Breite unter Berücksichtigung der vorgesehenen Ausnahmen. Ein Bestellbutton darf nicht außerhalb eines nicht scrollbar erreichbaren Bereichs verschwinden. Testen Sie den offenen Dialog, nicht nur die darunterliegende Seite.

Nach den Web Content Accessibility Guidelines (WCAG) 2.2 gelten für normale Texte grundsätzlich 4,5:1 Kontrast und für große Texte 3:1. Relevante Bedienelementgrenzen und grafische Informationen benötigen dort, wo das Kriterium anwendbar ist, 3:1. Zielgrößen auf AA-Stufe betragen grundsätzlich 24 mal 24 CSS-Pixel, mit Ausnahmen; daraus folgt kein pauschaler Pflichtabstand von 24 Pixeln. Kontrollieren Sie insbesondere kleine Mengenregler und Löschsymbole.

7. Fehler so melden, dass Korrektur gelingt

Validierung muss erklären, was falsch ist und wie Kund:innen weiterkommen. „Ungültige Eingabe“ reicht bei einer Postleitzahl selten aus. Eine konkrete Meldung kann darauf hinweisen, dass die Postleitzahl nicht zum ausgewählten Lieferland passt. Verbinden Sie die Meldung technisch mit dem Feld und kennzeichnen Sie den Fehler nicht ausschließlich durch Farbe. Bei mehreren Fehlern kann eine Zusammenfassung mit Links zu den betreffenden Feldern helfen.

Ein hypothetisches Formular löscht nach einer fehlerhaften Telefonnummer die komplette Adresse. Die Korrektur ist zunächst Datenerhalt, nicht eine freundlichere Fehlermeldung. Legen Sie anschließend eine konsistente Fokusstrategie fest, etwa zur Fehlerzusammenfassung nach dem Absenden. Die Abnahme umfasst den erneuten Versuch: Lassen sich alle Fehler erreichen und beheben, ohne korrekte Daten neu einzugeben? Verschwindet eine behobene Fehlermeldung zuverlässig? Wird eine serverseitige Ablehnung ebenso verständlich behandelt wie ein lokaler Formatfehler?

8. Zahlungsdienste als Teil des eigenen Kaufwegs behandeln

Externe Zahlungsanbieter sind keine unsichtbare technische Einzelheit. Kund:innen erleben eingebettete Kartenfelder, Bankfreigaben und Rückleitungen als zusammenhängenden Einkauf. Prüfen Sie deshalb jeden angebotenen Zahlungsweg in einer geeigneten Testumgebung. Bei eingebetteten Frames sind verständliche Titel, Feldbeschriftungen, Fokusübergänge und erreichbare Fehlermeldungen wichtig. Bei Weiterleitungen müssen Zweck und nächster Schritt klar sein, ohne sich ausschließlich auf ein neues Fenster zu verlassen.

Ein hypothetischer Testfall: Die Bankfreigabe wird abgebrochen, danach landet die Person in einem leeren Warenkorb. Eine geeignete Korrektur bewahrt den Bestellkontext und erklärt, ob bereits eine Bestellung oder Zahlung vorliegt. Erfassen Sie Barrieren beim Anbieter mit reproduzierbaren Schritten und vereinbaren Sie Zuständigkeiten für die Behebung. Eine andere Zahlungsart kann praktisch helfen, macht einen unzugänglichen Weg aber nicht automatisch konform. Testen Sie auch Rückkehr, Zeitüberschreitung und erneute Autorisierung.

9. Finanzielle Fehler vor dem Abschluss verhindern

Vor einer kostenpflichtigen Bestellung müssen Kund:innen erkennen können, was sie kaufen und welcher Gesamtbetrag gilt. Zeigen Sie Varianten, Mengen, Versandkosten, gewählte Zahlungsart und relevante Lieferangaben verständlich an. Änderungen müssen vor dem verbindlichen Abschluss erreichbar sein. Eine Bearbeitung der Adresse darf nicht unbemerkt die zuvor gewählte Versandart oder den Preis verändern. Falls eine Änderung Auswirkungen hat, müssen diese erneut nachvollziehbar werden.

Das Kriterium Error Prevention (Legal, Financial, Data) verlangt für anwendbare Vorgänge mindestens eine der vorgesehenen Sicherungen: Rückgängigmachen, Prüfung mit Korrekturmöglichkeit oder Überprüfung mit Bestätigung und Korrektur. Eine gut umgesetzte Bestellübersicht ist dafür ein naheliegender Ansatz, nicht bloß ein zusätzlicher Bildschirm. Prüfen Sie hypothetisch eine falsche Menge: Wird sie erkannt, lässt sie sich ändern und zeigt die abschließende Bestätigung tatsächlich den korrigierten Betrag?

10. Unklare Zahlungszustände und Doppelbestellungen vermeiden

Nach dem Auslösen einer Zahlung kann eine Netzwerkunterbrechung einen unklaren Zustand erzeugen. „Fehler, bitte erneut versuchen“ ist gefährlich, wenn die Zahlung möglicherweise bereits verarbeitet wurde. Unterscheiden Sie fachlich zwischen abgelehnt, abgebrochen, ausstehend und bestätigt. Die Oberfläche muss diesen Zustand verständlich vermitteln und eine sichere nächste Handlung nennen. Ein laufender Prozess sollte zugänglich angekündigt werden, ohne sekündlich dieselbe Meldung vorzulesen.

Technisch sollten wiederholte Anfragen nicht versehentlich doppelte Bestellungen oder Belastungen erzeugen. Geeignete serverseitige Mechanismen wie Idempotenz ergänzen die zugängliche Oberfläche; sie ersetzen sie nicht. Testen Sie hypothetisch einen Doppelklick, eine erneute Übermittlung und die Browser-Zurück-Funktion. Ein deaktivierter Button allein ist kein ausreichender Nachweis. Entscheidend ist, dass Oberfläche, Bestellsystem und Zahlungsstatus auch nach einer Unterbrechung einen konsistenten Vorgang abbilden.

11. Bestätigung und Abnahme belastbar gestalten

Die Bestätigungsseite soll klar sagen, ob die Bestellung eingegangen ist und ob die Zahlung bestätigt wurde oder noch aussteht. Zeigen Sie Bestellreferenz, Zusammenfassung und nächste Schritte als zugänglichen Text. Eine E-Mail ergänzt die Bestätigung, darf aber nicht die einzige Möglichkeit sein, den unmittelbaren Erfolg zu erkennen. Falls Belege als PDF bereitgestellt werden, brauchen auch diese eine zugängliche Struktur; ein optisch korrektes Dokument allein genügt nicht.

Kombinieren Sie automatisierte Prüfungen mit manuellen Tastatur-, Screenreader- und Vergrößerungstests. Dokumentieren Sie für jeden Befund Ausgangszustand, Schritte, erwartetes und tatsächliches Verhalten sowie Browser und Hilfsmittel. Abnahme bedeutet, denselben Weg nach der Korrektur erneut zu durchlaufen, einschließlich negativer Fälle. Prüfen Sie zusätzlich, ob die Änderung andere Zahlungsarten beeinträchtigt. Verankern Sie solche Szenarien in Release-Checks, besonders nach Änderungen an Formularbibliotheken, Zahlungsintegrationen oder gemeinsamen Dialogkomponenten.

12. Häufige Fragen und nächster Schritt

Reicht ein automatisierter Checkout-Test?

Nein. Automatisierte Werkzeuge finden bestimmte technische Fehler, beurteilen aber nicht zuverlässig die vollständige Bestellung, verständliche Korrekturwege oder alle Fokusübergänge. Manuelle Tests bleiben notwendig.

Muss jeder Shop eine Gastbestellung anbieten?

WCAG schreibt nicht pauschal eine Gastbestellung vor. Wenn ein Konto erforderlich ist, müssen jedoch Anmeldung, Authentifizierung und Wiederherstellung innerhalb des betrachteten Prozesses zugänglich sein.

Ist ein Zahlungsanbieter außerhalb des Prüfbereichs?

Für die Bewertung der tatsächlichen Einkaufsreise sollten Sie ihn nicht ausklammern. Halten Sie technische Grenzen und Zuständigkeiten fest, statt einen erfolgreichen Abschluss ohne Prüfung anzunehmen.

Beweist WCAG 2.2 AA die vollständige BaFG-Erfüllung?

Nein. Technische Konformität und rechtliche Pflichten sind nicht identisch. Der konkrete Anwendungsbereich und weitere Anforderungen müssen gesondert beurteilt werden.

Wenn Sie Ihre Kaufstrecke systematisch untersuchen möchten, ist ein Barrierefreiheit-Audit von Zensations ein sinnvoller nächster Schritt. Bringen Sie Zahlungsarten, bekannte Fehlerfälle und Zugang zur Testumgebung mit. Darauf lässt sich ein prüfbarer Umfang vom Produkt bis zur Bestätigung aufbauen. Unsere Accessibility-Leistungen unterstützen auch die anschließende Umsetzung und Qualitätssicherung, ohne pauschale Konformitätsversprechen.

Quellen

Inhaltlich geprüft am 7. November 2026.