Barrierefreier Checkout: Kunden nicht verlieren

Das Fundament eines barrierefreien Checkouts sind korrekt beschriftete Formularfelder. Jedes Eingabefeld muss ein zugehöriges <label>-Element besitzen, das programmatisch mit dem Feld verknüpft ist. Placeholder-Text allein reicht nicht aus, da er beim Eintippen verschwindet und von Screenreadern nicht konsistent als Beschriftung erkannt wird. Der WebAIM Million Report (2024) identifiziert fehlende Formular-Labels als drittgrößtes Barrierefreiheitsproblem mit 48,6% (WebAIM Million Report, 2024) aller geprüften Startseiten.

Pflichtfelder müssen sowohl visuell als auch programmatisch gekennzeichnet werden. Ein roter Stern allein genügt nicht: Das Attribut aria-required="true" oder das HTML-Attribut required teilt assistiven Technologien mit, dass das Feld ausgefüllt werden muss. Zusätzlich sollte am Anfang des Formulars ein Hinweis stehen, der die Bedeutung der Pflichtfeldmarkierung erklärt.

Autocomplete-Attribute nach dem HTML-Standard sind ein weiterer wichtiger Baustein. Felder wie autocomplete="given-name", autocomplete="family-name", autocomplete="street-address" und autocomplete="postal-code" ermöglichen Browsern und Hilfstechnologien, gespeicherte Daten automatisch einzufügen. Das reduziert die Eingabelast erheblich, besonders für Nutzer, die Schwierigkeiten mit der manuellen Texteingabe haben. Der barrierefreie Shop implementiert diese Attribute für alle relevanten Felder.

Adressformulare im Checkout stellen besondere Herausforderungen an die Barrierefreiheit. Ein typisches Adressformular enthält sechs bis zehn Felder, die logisch gruppiert und beschriftet werden müssen. Die HTML-Elemente <fieldset> und <legend> fassen zusammengehörige Felder zu Gruppen zusammen: Ein Fieldset für die Rechnungsadresse, ein weiteres für die Lieferadresse. Screenreader lesen die Legend vor, wenn der Nutzer in die Gruppe navigiert, und geben so Kontext.

Ein besonders häufiges Problem ist das PLZ-Feld: Viele Shops akzeptieren nur bestimmte Formate, kommunizieren die Formatanforderung aber nicht klar. Ein barrierefreies PLZ-Feld gibt das erwartete Format in einer Hilfsinformation unterhalb des Feldes an, die per aria-describedby mit dem Feld verknüpft ist. Bei internationalen Shops, die verschiedene Adressformate unterstützen, muss das Formular dynamisch auf die Länderauswahl reagieren und die Feldstruktur entsprechend anpassen.

Die Option, die Rechnungsadresse als Lieferadresse zu übernehmen, erfüllt direkt das WCAG 2.2 Kriterium 3.3.7 (Redundant Entry). Die Umsetzung erfolgt über eine Checkbox mit klarem Label, die bei Aktivierung die Lieferadressfelder automatisch befüllt und gegebenenfalls visuell ausblendet. Screenreader müssen den Zustand der Checkbox und die Auswirkung auf die weiteren Felder korrekt kommuniziert bekommen.

Multi-Step-Checkouts verwenden Fortschrittsanzeigen, um dem Nutzer zu zeigen, an welcher Stelle im Prozess er sich befindet. Für sehende Nutzer ist das oft ein visueller Balken oder eine Schrittfolge mit nummerierten Kreisen. Für Screenreader-Nutzer muss diese Information programmatisch verfügbar sein. Das Attribut aria-current="step" markiert den aktuellen Schritt, während eine Übersicht aller Schritte als geordnete Liste implementiert werden kann.

Beim Wechsel zwischen Schritten muss der Fokus korrekt gesetzt werden. Wenn der Nutzer den Adressschritt abschließt und zum Zahlungsschritt wechselt, sollte der Fokus auf die Überschrift oder den ersten Formularfeldblock des neuen Schritts gesetzt werden. Ein Seitenwechsel ohne Fokusmanagement führt dazu, dass Screenreader-Nutzer nicht wissen, wo sie sich befinden, und Tastaturnutzer vom Anfang der Seite navigieren müssen.

Eine barrierefreie Fortschrittsanzeige kommuniziert außerdem, welche Schritte bereits abgeschlossen sind, ob der Nutzer zu einem früheren Schritt zurückkehren kann und wie viele Schritte insgesamt noch folgen. Abgeschlossene Schritte können als Links implementiert werden, die eine Rückkehr ermöglichen. Die Gesamtzahl der Schritte wird beim Betreten des Checkouts angekündigt, etwa: Schritt 2 von 4.

Jeder einzelne Schritt im Checkout muss vollständig per Tastatur bedienbar sein. Das bedeutet: Formularfelder sind per Tab erreichbar, Radio-Gruppen per Pfeiltasten navigierbar, Checkboxen per Space aktivierbar und Buttons per Enter und Space auslösbar. Modale Dialoge, wie sie bei der Adressvalidierung oder der Zahlungsbestätigung eingesetzt werden, müssen einen Fokustrap implementieren und per Escape schließbar sein.

Ein häufiges Problem sind Custom-Dropdowns für die Länderauswahl, die zwar visuell wie native Select-Elemente aussehen, aber nicht die gleiche Tastaturbedienbarkeit bieten. Die Empfehlung: Wo immer möglich native HTML-Elemente verwenden. Wenn Custom-Widgets nötig sind, müssen sie das vollständige Tastaturinteraktionsmuster des nativen Pendants implementieren, einschließlich Type-Ahead-Suche bei langen Listen.

Skip-Links am Anfang jedes Checkout-Schritts ermöglichen es Tastaturnutzern, direkt zum relevanten Formular zu springen, ohne Header und Navigation erneut durchlaufen zu müssen. Bei Shops mit umfangreichen Headern spart das erhebliche Zeit und reduziert die Frustration. Die barrierefreie Webentwicklung implementiert Skip-Links als Standard auf jeder Seite.

Der mobile Checkout stellt zusätzliche Anforderungen an die Barrierefreiheit. Touch-Ziele müssen nach WCAG 2.2 mindestens 24x24 CSS-Pixel groß sein (Kriterium 2.5.8). Auf mobilen Geräten, wo die Bedienung mit dem Finger weniger präzise ist als mit der Maus, empfiehlt sich eine Zielgröße von 44x44 Pixeln oder mehr. Buttons, Checkboxen und Radio-Buttons im Checkout müssen diese Mindestgrößen einhalten.

Die Eingabetastatur auf mobilen Geräten kann durch das inputmode-Attribut gesteuert werden: inputmode="numeric" für PLZ und Telefonnummer, inputmode="email" für E-Mail-Adressen, inputmode="tel" für Telefonnummern. Das erleichtert die Eingabe erheblich und reduziert Fehler. In Kombination mit dem type-Attribut und den Autocomplete-Werten entsteht ein mobiler Checkout, der die Eingabelast minimiert. Laut Baymard Institute haben 17 Prozent (Baymard Institute, 2025) der befragten US-Onlinekäufer eine Bestellung abgebrochen, weil der Checkout zu lang oder zu kompliziert war – passende Bildschirmtastaturen und Autocomplete verringern genau diesen Aufwand.

Zoom muss im mobilen Checkout vollständig unterstützt werden. Die Meta-Viewport-Direktive user-scalable=no blockiert das Zoomen und verstößt gegen WCAG 1.4.4. Formularfelder mit einer Schriftgröße unter 16 Pixel lösen auf iOS einen automatischen Zoom aus, was die Nutzererfahrung stört. Die Lösung: Alle Eingabefelder auf mindestens 16 Pixel Schriftgröße setzen und dem Nutzer die Kontrolle über die Zoomstufe belassen.