Barrierefreier Checkout: die kritischen Schritte

Das Wichtigste in Kürze

• Der Checkout ist die Stelle, an der eine Barriere unmittelbar Geld kostet. Jeder Abbruch an dieser Stelle ist ein verlorener Kauf – ganz gleich, wie gut die Produktseite davor funktioniert hat.
• Die immer gleichen Befundmuster: Felder ohne programmatisch verknüpfte Beschriftung, Fehlermeldungen, die nur rot eingefärbt sind, und ein Fokus, der nach Schrittwechsel oder Dialog ins Leere fällt.
• Für den ersten Durchgang brauchen Sie kein Spezialwerkzeug: Tastatur statt Maus, Browser-Zoom auf 200 und 400 Prozent und ein absichtlich falsch ausgefülltes Formular decken den größten Teil auf.
• Genau hier leistet ein automatisierter Scan am wenigsten. Er sieht einen Zustand, der Checkout hat viele. Automatisierte Prüfung deckt die maschinell prüfbaren Kriterien ab; eine vollständige Konformitätsbewertung erfordert zusätzlich manuelle Prüfung.
• Dieser Artikel arbeitet den Ablauf der Reihe nach ab und nennt zu jedem Punkt drei Dinge: das Problem, den Test und die technische Lösung mit dem zugehörigen WCAG-Erfolgskriterium.

Warum der Checkout anders bewertet werden muss

Auf einer Produktseite ist eine Barriere ärgerlich – man kann sie umgehen, weitersuchen, den Artikel anderswo ansehen. Im Bestellprozess gibt es keinen Umweg. Wer das Mengenfeld nicht bedienen kann, wer nicht erfährt, warum das Formular nicht abgeschickt wird, wer nach dem Schrittwechsel nicht mehr weiß, wo er ist, bricht ab. Das ist kein reines Compliance-Thema, sondern schlicht Umsatz, der nicht entsteht.

Hinzu kommt eine fachliche Besonderheit: Die WCAG behandeln Bestellprozesse strenger als gewöhnliche Seiten. Erfolgskriterium 3.3.4 Fehlervermeidung (rechtliche, finanzielle, Daten) (AA) gilt für Vorgänge, die eine finanzielle Verpflichtung auslösen. Es verlangt, dass Eingaben entweder umkehrbar sind, auf Fehler geprüft werden oder vor dem endgültigen Absenden geprüft, korrigiert und bestätigt werden können. Ein Checkout, aus dem heraus man eine Adresse nicht mehr ändern kann, ohne von vorn zu beginnen, erfüllt das nicht.

Ob Ihr Shop überhaupt in den Anwendungsbereich fällt, klärt der Artikel Ist mein Onlineshop BFSG-pflichtig?. Hier setzen wir voraus, dass diese Frage beantwortet ist, und gehen direkt in die Technik. Die folgende Übersicht ist zugleich der Aufbau dieses Artikels und eine Prüfliste, die Sie an Ihr Entwicklungsteam weitergeben können.

Ein Hinweis zur Testumgebung, bevor Sie loslegen: Legen Sie sich einen Testzugang und eine Testzahlungsart an, mit denen Sie den Prozess mehrfach vollständig durchspielen können, ohne echte Bestellungen auszulösen. Ohne diese Möglichkeit endet jede Prüfung an dem Punkt, an dem es interessant wird.

Schritt 1: Der Warenkorb

Der Warenkorb ist formal noch kein Checkout, gehört aber zum selben Ablauf. Er ist zugleich die Seite mit der höchsten Dichte an kleinen Bedienelementen: Mengenfelder, Plus- und Minus-Schaltflächen, Entfernen-Symbole, Gutscheinfeld, Aktualisieren-Button. Fast jedes davon ist in der Praxis ein Kandidat für einen Befund.

1. Das Mengenfeld hat keine Beschriftung

   Problem: Das Eingabefeld für die Menge steht ohne <label> in der Zeile, weil die Spaltenüberschrift „Menge“ optisch ausreicht. Für eine Ausgabe per Screenreader ist die Tabellenspalte aber nicht dasselbe wie eine Feldbeschriftung – angesagt wird „Eingabefeld, 1“, ohne zu welchem Artikel das gehört.

   Test: Klicken Sie auf die sichtbare Beschriftung des Feldes. Springt der Schreibcursor ins Feld, ist die Verknüpfung vorhanden. Passiert nichts, fehlt sie. Dieser Test dauert eine Sekunde und funktioniert bei jedem Formularfeld.

   Lösung: Jedes Mengenfeld bekommt ein eigenes, artikelbezogenes Label. Wo es optisch nicht auftauchen soll, wird es visuell versteckt – aber nicht mit display: none oder visibility: hidden, denn damit verschwindet es auch für assistive Technologien. Beispiel: <label for="menge-4711">Menge für Bio-Kaffee 500 g</label> mit <input id="menge-4711" type="number" min="0" inputmode="numeric">. Erfolgskriterien: 3.3.2 Beschriftungen oder Anweisungen (A) und 4.1.2 Name, Rolle, Wert (A).

2. Plus, Minus und Entfernen sind namenlose Symbole

   Problem: Mengensteuerung und Entfernen-Funktion sind Icon-Schaltflächen ohne Text. Angesagt wird nur „Schaltfläche“. Kommt derselbe Name mehrfach vor – zehn Zeilen, zehnmal „Entfernen“ –, ist außerdem nicht erkennbar, welcher Artikel betroffen ist. Sprachsteuerung kann solche Elemente gar nicht ansprechen.

   Test: Legen Sie die Maus weg und tabben Sie durch den Warenkorb. Erkennen Sie an jeder Station, welche Funktion gerade fokussiert ist? Zusätzlich: Sind die Schaltflächen überhaupt erreichbar, oder sind es <div>-Elemente mit Klick-Handler, die der Fokus überspringt?

   Lösung: Echte <button>-Elemente verwenden und jedem einen eindeutigen, artikelbezogenen Namen geben, etwa <button type="submit" aria-label="Bio-Kaffee 500 g aus dem Warenkorb entfernen">. Das SVG oder Icon-Zeichen im Button zusätzlich mit aria-hidden="true" versehen, damit es nicht doppelt vorgelesen wird. Erfolgskriterien: 4.1.2 Name, Rolle, Wert (A) und 2.1.1 Tastatur (A).

3. Nach dem Entfernen verschwindet der Fokus

   Problem: Der Entfernen-Button wird geklickt, die Zeile verschwindet – und mit ihr das Element, auf dem der Fokus lag. Der Browser setzt den Fokus dann auf den Seitenanfang zurück. Wer per Tastatur arbeitet, muss sich durch den halben Warenkorb zurückarbeiten und weiß nicht, ob überhaupt etwas passiert ist.

   Test: Entfernen Sie einen Artikel per Tastatur (Tab bis zum Button, dann Enter). Drücken Sie danach einmal Tab. Wo landen Sie? Direkt nach der Stelle des entfernten Artikels ist richtig, am Seitenanfang ist falsch.

   Lösung: Den Fokus nach dem Entfernen bewusst setzen – auf die nächste Warenkorbzeile, auf die Warenkorb-Überschrift oder auf die Statusmeldung. Ein Zielelement, das nicht von sich aus fokussierbar ist, bekommt dafür tabindex="-1". Erfolgskriterium: 2.4.3 Fokus-Reihenfolge (A).

4. Die Summe aktualisiert sich lautlos

   Problem: Mengenänderung oder Gutscheineingabe aktualisieren Zwischensumme, Versandkosten und Gesamtsumme per JavaScript, ohne dass die Seite neu lädt. Optisch ist das elegant. Für alle, die den Bildschirm nicht sehen, passiert schlicht nichts – die neue Summe steht zwar im Dokument, wird aber nicht angekündigt.

   Test: Ohne Werkzeug lässt sich das nur indirekt prüfen: Gibt es sichtbar eine kurze Rückmeldung („Menge aktualisiert“), oder ändert sich stumm nur eine Zahl? Im Quelltext genügt die Suche nach aria-live.

   Lösung: Eine Live-Region einrichten, die vor der Aktualisierung bereits im Dokument steht und danach mit Text gefüllt wird – ein Container, der erst zusammen mit der Meldung eingefügt wird, bleibt oft stumm. Beispiel: <p aria-live="polite" id="warenkorb-status"></p>, hineingeschrieben wird dann etwa „Menge geändert, neue Gesamtsumme 48,90 Euro“. Erfolgskriterium: 4.1.3 Statusmeldungen (AA).

5. Die Warenkorb-Tabelle ist eine Layout-Tabelle

   Problem: Die Positionen stehen in einer Tabelle ohne Kopfzellen – oder gar nicht in einer Tabelle, sondern in verschachtelten <div>-Elementen, die per CSS wie eine Tabelle aussehen. Der Zusammenhang zwischen „Bio-Kaffee 500 g“, „2“ und „19,80 Euro“ geht dabei verloren.

   Test: Blenden Sie im Browser testweise die Stile aus (in den Entwicklerwerkzeugen oder über die Lesedarstellung). Bleibt die Zuordnung von Artikel, Menge und Preis nachvollziehbar?

   Lösung: Echte Tabellensemantik mit <th scope="col"> für die Spaltenüberschriften und <th scope="row"> für den Artikelnamen. Erfolgskriterium: 1.3.1 Info und Beziehungen (A). Wo im Shopsystem diese Vorlagen liegen und wie Korrekturen update-fest bleiben, beschreibt der Artikel BFSG in Shopware, WordPress und WooCommerce.

Schritt 2: Anmelden oder als Gast bestellen

Die Weiche zwischen Konto und Gast-Bestellung ist der erste Punkt, an dem viele Bestellprozesse Menschen ausschließen – nicht durch fehlendes Markup, sondern durch Gestaltung. Danach folgt mit dem Login das Formular, dessen Fehlerbehandlung am häufigsten stumm bleibt.

1. Die Gast-Bestellung ist versteckt

   Problem: Anmeldung und Registrierung stehen als große Schaltflächen oben, die Gast-Bestellung als kleiner grauer Link darunter oder erst nach dem Aufklappen eines Bereichs. Wer die Seite vergrößert oder nur den Ausschnitt um den Fokus sieht, findet die Option nicht.

   Test: Zoomen Sie auf 200 Prozent und tabben Sie durch den Schritt. Erscheint die Gast-Option in der Fokusreihenfolge an einer Stelle, an der man sie erwartet?

   Lösung: Die drei Wege gleichrangig auszeichnen, jeden mit einer eigenen Überschrift, und die Gast-Bestellung nicht hinter ein Aufklapp-Element legen. Zusammengehörige Optionen semantisch gruppieren. Erfolgskriterium: 2.4.6 Überschriften und Beschriftungen (AA); zum Kontrast des grauen Links siehe 1.4.3 Kontrast (Minimum) (AA).

2. Der fehlgeschlagene Login meldet sich nicht

   Problem: Nach falschem Passwort lädt die Seite neu, die Felder sind leer, und irgendwo steht ein roter Kasten – der Fokus liegt aber wieder am Seitenanfang oder im ersten Feld. Wer den Kasten nicht sieht, erfährt nicht, warum nichts passiert.

   Test: Melden Sie sich absichtlich mit falschem Passwort an. Ist der Fehler in Textform vorhanden? Wird er beim erneuten Tabben vor den Feldern erreicht?

   Lösung: Die Meldung als Text ausgeben, oberhalb des Formulars platzieren und den Fokus nach dem Neuladen dorthin setzen (Container mit tabindex="-1"). Erfolgskriterium: 3.3.1 Fehlererkennung (A). Mehr dazu im Abschnitt über Fehlermeldungen.

3. Passwortfelder ohne autocomplete

   Problem: Ohne die passenden autocomplete-Werte füllen Passwortverwaltungen und Browser die Felder nicht zuverlässig aus. Für Menschen mit motorischen oder kognitiven Einschränkungen ist automatisches Ausfüllen kein Komfort, sondern der Unterschied zwischen bedienbar und nicht bedienbar.

   Test: Speichern Sie die Zugangsdaten im Browser und rufen Sie das Formular erneut auf. Werden beide Felder befüllt?

   Lösung: Am Benutzernamen- oder E-Mail-Feld autocomplete="username", beim Anmelden autocomplete="current-password", bei der Registrierung autocomplete="new-password". Das Einfügen aus der Zwischenablage darf nicht per JavaScript unterbunden werden. Erfolgskriterium: 1.3.5 Eingabezweck bestimmen (AA).

4. Die Schaltfläche „Passwort anzeigen“ hat keinen Zustand

   Problem: Das Augensymbol neben dem Passwortfeld ist ein Icon-Button ohne Namen. Ob das Passwort gerade sichtbar ist oder nicht, ist nur am Symbol erkennbar.

   Test: Tabben Sie auf das Symbol. Erkennen Sie ohne Blick auf das Icon, was es tut und in welchem Zustand es ist?

   Lösung: <button type="button" aria-pressed="false" aria-label="Passwort anzeigen"> und den Wert von aria-pressed beim Umschalten mitführen. Erfolgskriterium: 4.1.2 Name, Rolle, Wert (A).

5. Das Captcha ist ein Bild

   Problem: Ein verzerrtes Buchstabenbild ohne Alternative schließt blinde Nutzerinnen und Nutzer vollständig aus – und je nach Verzerrungsgrad auch viele sehende. Eine reine Bildbeschreibung im alt-Attribut hilft nicht, weil sie die Lösung verraten würde.

   Test: Lässt sich das Captcha ohne Sehen lösen? Gibt es eine zweite, gleichwertige Variante?

   Lösung: Wo möglich auf sichtbare Captchas verzichten und stattdessen serverseitige Verfahren einsetzen (Rate-Limiting, unsichtbare Prüfungen, Honeypot-Felder). Ist ein Captcha unverzichtbar, muss mindestens eine Alternative für einen anderen Sinneskanal angeboten und der Zweck des Captchas im Text benannt werden. Erfolgskriterium: 1.1.1 Nicht-Text-Inhalte (A).

Schritt 3: Die Adresseingabe

Die Adresseingabe ist das längste Formular im Shop und damit der Ort, an dem sich Beschriftungsfehler vervielfachen. Gleichzeitig ist sie der Schritt, der am stärksten von automatischem Ausfüllen profitiert – vorausgesetzt, die Felder verraten dem Browser, wofür sie da sind.

1. Beschriftung sichtbar und programmatisch verknüpft

   Problem: Ein Text steht optisch über dem Feld, ist im Markup aber ein <span> oder ein <label> ohne for. Optisch gibt es eine Beschriftung, programmatisch nicht. Das ist der mit Abstand häufigste Formularbefund unserer Prüfläufe.

   Test: Auf die Beschriftung klicken. Springt der Cursor ins Feld? Wenn nicht, ist die Verknüpfung defekt. Nebeneffekt: Ohne Verknüpfung ist auch die Klickfläche kleiner, was für Menschen mit motorischen Einschränkungen zusätzlich hinderlich ist.

   Lösung: <label for="plz">Postleitzahl</label> und <input id="plz" name="plz" autocomplete="postal-code" inputmode="numeric">. Wo kein sichtbares Label möglich ist, greift aria-label beziehungsweise aria-labelledby – aber als Ausnahme, nicht als Regel. Pro Feld genau ein Label; ergänzende Hinweise gehören an aria-describedby, nicht in ein zweites Label. Erfolgskriterien: 3.3.2 Beschriftungen oder Anweisungen (A) und 4.1.2 Name, Rolle, Wert (A).

2. Der Platzhalter ersetzt die Beschriftung

   Problem: Das Feld enthält nur placeholder="Postleitzahl". Sobald jemand tippt, ist die Beschriftung weg. Wer die Eingabe später kontrollieren will, sieht eine Zahl ohne Kontext. Zusätzlich ist Platzhaltertext in fast allen Themes zu hell und verfehlt damit den Mindestkontrast.

   Test: Füllen Sie das Formular komplett aus und schauen Sie es dann noch einmal an. Ist bei jedem Feld noch erkennbar, was drinsteht?

   Lösung: Ein dauerhaft sichtbares Label. Sogenannte schwebende Labels sind unkritisch, solange sie auf einem echten <label>-Element beruhen und im gefüllten Zustand lesbar bleiben. Platzhalter dann nur noch für Formatbeispiele verwenden. Erfolgskriterien: 3.3.2 (A) und 1.4.3 Kontrast (Minimum) (AA).

3. Pflichtfelder sind nur farbig oder nur ein Sternchen

   Problem: Pflichtangaben werden durch ein rotes Sternchen markiert, das nirgends erklärt wird – oder allein durch eine farbige Rahmenlinie. Farbe als einziges Unterscheidungsmerkmal ist ein eigener Verstoß, und ein Sternchen ohne Legende ist eine Konvention, die nicht alle kennen.

   Test: Stellen Sie sich das Formular in Graustufen vor oder machen Sie einen Screenshot und entsättigen ihn. Bleibt erkennbar, welche Felder Pflicht sind?

   Lösung: Das Sternchen beibehalten, aber im Formular erklären („Mit * gekennzeichnete Felder sind Pflichtfelder“), es in den Labeltext aufnehmen und die Felder zusätzlich mit dem HTML-Attribut required auszeichnen. Bei selbstgebauten Feldern aria-required="true". Erfolgskriterien: 1.4.1 Benutzung von Farbe (A) und 3.3.2 Beschriftungen oder Anweisungen (A).

4. Fehlende oder erfundene autocomplete-Werte

   Problem: Entweder fehlt autocomplete ganz, oder es stehen selbst ausgedachte Werte wie autocomplete="strasse" darin. Beides führt dazu, dass Browser und Hilfstechnologien den Eingabezweck nicht erkennen und nicht automatisch ausfüllen können.

   Test: Hinterlegen Sie im Browser eine Adresse und starten Sie das automatische Ausfüllen. Welche Felder bleiben leer?

   Lösung: Ausschließlich die in der HTML-Spezifikation definierten Werte verwenden – siehe die Tabelle unten. Erfolgskriterium: 1.3.5 Eingabezweck bestimmen (AA).

5. Auswahlfelder und Optionsgruppen ohne Gruppenbezug

   Problem: Die Anrede besteht aus drei einzelnen Optionsfeldern, die Länderauswahl ist ein <select> ohne Beschriftung. Angesagt wird dann „Auswahlliste“ – wofür, bleibt offen.

   Test: Tabben Sie in die Gruppe. Ist erkennbar, worüber gerade entschieden wird, ohne die Umgebung zu sehen?

   Lösung: Optionsgruppen in <fieldset> mit <legend>Anrede</legend> fassen, jede Auswahlliste mit einem <label> verknüpfen. Erfolgskriterien: 1.3.1 Info und Beziehungen (A) und 4.1.2 (A).

6. Adressvorschläge aus einem selbstgebauten Vorschlagsfeld

   Problem: Ein Eingabefeld blendet während des Tippens eine Vorschlagsliste ein, die aus <div>-Elementen besteht. Mit der Tastatur ist sie nicht erreichbar, die Anzahl der Treffer wird nicht angekündigt, und die Auswahl per Enter löst nichts aus.

   Test: Tippen Sie drei Buchstaben und versuchen Sie, ausschließlich mit Pfeiltasten und Enter einen Vorschlag zu übernehmen.

   Lösung: Entweder das Muster vollständig umsetzen – role="combobox" mit aria-expanded, aria-controls und aria-activedescendant, Bedienung über Pfeiltasten, Escape schließt die Liste, Trefferzahl in einer Live-Region – oder auf die Vorschlagsliste verzichten und ein normales Eingabefeld anbieten. Ein halb umgesetztes Muster ist schlechter als keines. Erfolgskriterien: 4.1.2 (A) und 2.1.1 Tastatur (A).

Schritt 4: Versandart und Zahlungsart wählen

Dieser Schritt besteht fast ausschließlich aus Optionsgruppen – und aus fremdem Code. Der Zahlungsteil kommt in vielen Shops von einem Dienstleister und wird in einem iframe eingebettet. Das ändert nichts daran, dass er auf Ihrer Seite erscheint und dort bedienbar sein muss.

1. Optionsgruppen ohne fieldset und legend

   Problem: Versandarten und Zahlungsarten stehen als lose Optionsfelder untereinander. Der gemeinsame Bezug – „hiervon wähle ich genau eines aus, und es geht um die Versandart“ – ist nur optisch vorhanden, etwa durch eine Überschrift, die technisch nichts mit der Gruppe zu tun hat.

   Test: Tabben Sie in die Gruppe und wechseln Sie mit den Pfeiltasten. Bei einer korrekt aufgebauten nativen Optionsgruppe springt Tab in die Gruppe hinein und beim nächsten Druck wieder heraus, während die Pfeiltasten zwischen den Optionen wechseln. Braucht es für jede einzelne Option ein Tab, ist die Gruppierung nicht vorhanden.

   Lösung: <fieldset><legend>Versandart</legend> … </fieldset> mit nativen <input type="radio">-Feldern, die alle denselben name tragen. Erfolgskriterien: 1.3.1 Info und Beziehungen (A) und 3.3.2 (A).

2. Selbstgebaute Auswahlkacheln

   Problem: Die Versandarten sind große anklickbare Kacheln aus <div>-Elementen mit einem Klick-Handler. Der Fokus erreicht sie nicht, ein Zustand „ausgewählt“ existiert nur als CSS-Klasse, und mit der Leertaste passiert nichts.

   Test: Versuchen Sie, die Versandart ausschließlich mit der Tastatur zu wechseln.

   Lösung: Die native Optionsgruppe behalten und lediglich per CSS als Kachel gestalten – das Optionsfeld visuell verstecken, das zugehörige <label> als Kachelfläche gestalten und den Fokuszustand über :focus-visible am Label sichtbar machen. Wer stattdessen role="radiogroup" und role="radio" nachbaut, muss zusätzlich aria-checked und die Pfeiltasten-Navigation selbst implementieren. Erfolgskriterien: 2.1.1 Tastatur (A), 4.1.2 (A) und 2.4.7 Fokus sichtbar (AA).

3. Zahlungsarten, die nur aus Logos bestehen

   Problem: Die Auswahl besteht aus Bildmarken ohne Text. Fehlt der Alternativtext oder enthält er nur den Dateinamen, ist die Zahlungsart nicht identifizierbar. Dasselbe gilt für die Logo-Leiste im Fußbereich, die als Vertrauenselement gedacht ist.

   Test: Blenden Sie in den Entwicklerwerkzeugen Bilder aus oder überprüfen Sie im Quelltext, ob jedes <img> in dieser Gruppe ein sinnvolles alt-Attribut trägt.

   Lösung: Neben das Logo einen sichtbaren Textnamen der Zahlungsart setzen. Ist das Logo dann reine Dekoration, bekommt es alt=""; steht es allein, muss das alt-Attribut die Zahlungsart benennen, etwa alt="Kreditkarte" – nicht das Bild beschreiben. Erfolgskriterium: 1.1.1 Nicht-Text-Inhalte (A).

4. Das Zahlungsfeld liegt in einem iframe ohne Titel

   Problem: Kartennummer, Ablaufdatum und Prüfziffer liegen in einem eingebetteten Frame des Zahlungsdienstleisters. Ohne title-Attribut wird der Frame nur als „Frame“ angekündigt. Häufig kommen zwei weitere Probleme dazu: Die Felder im Frame haben keine eigenen Labels, und Fehlermeldungen des Dienstleisters erscheinen nur innerhalb des Frames, während der Fokus außerhalb bleibt.

   Test: Tabben Sie in das Zahlungsfeld hinein und wieder heraus. Kommen Sie ohne Maus überall hin? Geben Sie eine ungültige Kartennummer ein – erfahren Sie in Textform, was falsch ist?

   Lösung: Jedem Frame ein beschreibendes title geben, etwa <iframe title="Kreditkartendaten eingeben">. Innerhalb des Frames sind Sie auf die Konfigurationsmöglichkeiten des Dienstleisters angewiesen: Sprache, Farben, Beschriftungen und Fehlerdarstellung lassen sich bei den meisten Anbietern setzen. Nutzen Sie das, und fragen Sie beim Anbieter aktiv nach dessen Angaben zur Barrierefreiheit – bei der Auswahl eines neuen Dienstleisters ist das ein Kriterium wie jedes andere. Erfolgskriterium: 4.1.2 Name, Rolle, Wert (A).

5. Die Auswahl löst einen unerwarteten Kontextwechsel aus

   Problem: Die Auswahl eines Lands oder einer Zahlungsart lädt die Seite sofort neu oder springt zum nächsten Schritt. Wer mit Pfeiltasten durch eine Optionsgruppe geht, löst dabei zwangsläufig jede Zwischenoption aus – und landet, bevor die Auswahl überhaupt getroffen war.

   Test: Durchlaufen Sie die Auswahlliste mit den Pfeiltasten, ohne Enter zu drücken. Bleiben Sie, wo Sie sind?

   Lösung: Eine Änderung der Auswahl darf den Kontext nicht automatisch wechseln. Aktualisierungen an Ort und Stelle vornehmen (Preisanzeige, verfügbare Zahlungsarten) und das Ergebnis über eine Live-Region ankündigen; für den Schrittwechsel eine ausdrückliche Schaltfläche anbieten. Erfolgskriterien: 3.2.2 Bei Eingabe (A) und 4.1.3 Statusmeldungen (AA).

Schritt 5: Prüfen und verbindlich bestellen

Der letzte Schritt entscheidet über die finanzielle Verpflichtung. Für ihn gilt Erfolgskriterium 3.3.4 Fehlervermeidung (rechtliche, finanzielle, Daten) (AA) in vollem Umfang: Die Bestellung muss vor dem Absenden prüfbar, korrigierbar und bestätigbar sein.

1. Die Zusammenfassung ist nur ein Layout

   Problem: Lieferadresse, Rechnungsadresse, Versandart, Zahlungsart und Positionen stehen in nebeneinanderliegenden Kästen ohne Überschriften. Beim Durchgehen ohne Bildschirm ist nicht erkennbar, welche Adresse gerade vorgelesen wird.

   Test: Lassen Sie die Seite von jemandem beschreiben, der nur den Text ohne Anordnung kennt – oder lesen Sie den Textinhalt der Seite linear von oben nach unten. Bleibt die Zuordnung eindeutig?

   Lösung: Jeder Block bekommt eine echte Überschrift („Lieferadresse“, „Rechnungsadresse“, „Zahlungsart“) in korrekter Hierarchie ohne Ebenensprünge, die Positionsliste bleibt eine Tabelle mit Kopfzellen. Erfolgskriterien: 1.3.1 Info und Beziehungen (A) und 2.4.6 Überschriften und Beschriftungen (AA).

2. Kein Weg zurück ohne Datenverlust

   Problem: Zu jedem Block fehlt eine Änderungsmöglichkeit, oder der Zurück-Link führt zum Anfang des Prozesses und leert die Felder. Wer einen Tippfehler in der Hausnummer bemerkt, gibt entweder alles neu ein oder bricht ab.

   Test: Gehen Sie von der Zusammenfassung zu jedem vorherigen Schritt zurück und wieder vor. Sind alle Eingaben noch da? Funktioniert auch die Zurück-Schaltfläche des Browsers, ohne den Zustand zu zerstören?

   Lösung: Je Block ein beschreibender Änderungs-Link – „Lieferadresse ändern“ statt „Ändern“, weil derselbe Linktext dreimal auf einer Seite nicht unterscheidbar ist. Der Zustand des Bestellprozesses gehört serverseitig gespeichert, nicht in den Seitenzustand. Erfolgskriterien: 3.3.4 (AA) und 2.4.4 Linkzweck (im Kontext) (A).

3. Die Checkbox für AGB und Widerrufsbelehrung

   Problem: Zwei Varianten sind verbreitet und beide fehlerhaft: Die Checkbox hat gar kein verknüpftes Label, oder das Label enthält Links, sodass ein Klick auf den Text ungewollt die Seite wechselt statt die Checkbox zu setzen. Fehlt die Zustimmung beim Absenden, wird der Bereich nur rot umrandet.

   Test: Klicken Sie auf den Beschriftungstext neben der Checkbox – setzt sich der Haken? Senden Sie das Formular ohne Haken ab: Erscheint ein Fehlertext, und ist er mit der Checkbox verknüpft?

   Lösung: Ein <label for="agb"> mit dem zustimmenden Text, die weiterführenden Links unmittelbar daneben außerhalb des Labels. Die Zustimmung als natives <input type="checkbox" id="agb" required> auszeichnen und den Fehler wie jeden anderen behandeln – als Text, verknüpft über aria-describedby. Erfolgskriterien: 4.1.2 (A), 3.3.1 Fehlererkennung (A) und 1.4.1 Benutzung von Farbe (A).

4. Der Bestell-Button ist mehrdeutig benannt

   Problem: Die Schaltfläche heißt „Weiter“ oder „Abschließen“, obwohl sie die Bestellung verbindlich auslöst. Oder – der subtilere Fall – sie trägt sichtbar „Zahlungspflichtig bestellen“, im Markup aber ein abweichendes aria-label="Bestellung senden". Sprachsteuerung reagiert dann auf den sichtbaren Text nicht mehr.

   Test: Vergleichen Sie sichtbaren Text und aria-label im Quelltext. Fragen Sie außerdem jemanden, der den Prozess nicht kennt, was beim Klick passiert.

   Lösung: Die Beschriftung eindeutig formulieren und den sichtbaren Text vollständig im zugänglichen Namen enthalten – am einfachsten, indem man auf ein zusätzliches aria-label verzichtet. Erfolgskriterien: 2.4.6 Überschriften und Beschriftungen (AA) und 2.5.3 Beschriftung im Namen (A).

5. Nach dem Absenden passiert scheinbar nichts

   Problem: Zwischen Klick und Bestätigungsseite liegen mehrere Sekunden Zahlungsabwicklung. In dieser Zeit gibt es keine Rückmeldung – der Button lässt sich erneut drücken. Auf der Bestätigungsseite liegt der Fokus danach wieder am Seitenanfang, die eigentliche Nachricht steht weiter unten.

   Test: Bestellung per Tastatur auslösen und danach nur Tab drücken. Erreichen Sie die Bestätigung, oder tabben Sie zuerst durch die gesamte Navigation?

   Lösung: Den Button während der Verarbeitung sperren, den Zustand über eine Live-Region ankündigen („Bestellung wird verarbeitet“) und auf der Bestätigungsseite den Fokus auf die Bestätigungsüberschrift setzen. Der Seitentitel im Browser-Tab sollte den Erfolg ebenfalls benennen. Erfolgskriterien: 4.1.3 Statusmeldungen (AA) und 2.4.2 Seitentitel (A).

Fehlermeldungen, die tatsächlich weiterhelfen

Fehlerbehandlung ist der Bereich, in dem im Checkout die meisten Abbrüche entstehen und der zugleich am seltensten geprüft wird – weil man dafür absichtlich etwas falsch machen muss. Genau das ist der Test: Formular leer absenden, Postleitzahl mit Buchstaben füllen, E-Mail ohne At-Zeichen, Kartennummer zu kurz.

1. Fehler werden gefärbt statt benannt

   Problem: Das fehlerhafte Feld bekommt einen roten Rahmen, mehr nicht. Für farbenblinde Menschen ist der Rahmen kaum vom normalen unterscheidbar, für blinde Menschen existiert er nicht, und selbst wer ihn sieht, weiß nicht, was falsch ist.

   Test: Machen Sie einen Screenshot des Fehlerzustands und entsättigen ihn. Ist noch erkennbar, welches Feld betroffen ist und warum?

   Lösung: Zu jedem Fehler ein Text direkt am Feld, dazu ein zweites nicht-farbliches Merkmal wie ein Symbol mit Textalternative oder eine deutlich dickere Rahmenlinie. Erfolgskriterien: 3.3.1 Fehlererkennung (A) und 1.4.1 Benutzung von Farbe (A).

2. Die Meldung ist nicht mit dem Feld verknüpft

   Problem: Der Fehlertext steht unter dem Feld, gehört technisch aber zu nichts. Wer per Tastatur ins Feld springt, hört nur die Beschriftung – die Meldung dazwischen wird beim Springen von Feld zu Feld übersprungen.

   Test: Senden Sie das Formular fehlerhaft ab und tabben Sie danach von Feld zu Feld. Erfahren Sie im Feld selbst, dass etwas nicht stimmt?

   Lösung: Die Meldung bekommt eine ID und wird über aria-describedby angebunden, das Feld zusätzlich mit aria-invalid="true" markiert:

   <input id="plz" autocomplete="postal-code" aria-invalid="true" aria-describedby="plz-fehler"> und <p id="plz-fehler">Bitte geben Sie eine fünfstellige Postleitzahl ein.</p>

   Erfolgskriterien: 3.3.1 (A) und 4.1.2 Name, Rolle, Wert (A).

3. Kein Einstieg in die Fehlerliste

   Problem: Ein Formular mit vierzehn Feldern meldet drei Fehler an verstreuten Stellen. Der Fokus bleibt nach dem Absenden auf dem Absende-Button stehen – also am Ende des Formulars, hinter allen Fehlern.

   Test: Formular fehlerhaft absenden, dann Tab drücken. Landen Sie bei einem Fehler oder in der Fußzeile?

   Lösung: Eine Fehlerübersicht am Anfang des Formulars ausgeben, die jeden Fehler als Link auf das betroffene Feld nennt, und den Fokus direkt nach dem Absenden in diese Übersicht setzen (Container mit tabindex="-1" und anschließendem focus()). Alternativ – bei nur einem Fehler – den Fokus direkt in das erste fehlerhafte Feld setzen. Erfolgskriterien: 3.3.1 (A) und 2.4.3 Fokus-Reihenfolge (A).

4. „Ungültige Eingabe“ statt eines Korrekturhinweises

   Problem: Die Meldung benennt das Problem, aber nicht die Lösung. Bei Datumsangaben, Postleitzahlen oder Kartennummern ist das erwartete Format oft nicht offensichtlich.

   Test: Lesen Sie jede Fehlermeldung Ihres Checkouts einzeln. Steht darin, was zu tun ist?

   Lösung: Wo das richtige Format bekannt ist, gehört es in die Meldung: „Bitte geben Sie das Ablaufdatum im Format MM/JJ ein“ statt „Ungültiges Datum“. Wo die Eingabe formal richtig, inhaltlich aber unbekannt ist (Adresse nicht auffindbar), sagt die Meldung, welche Alternativen es gibt. Erfolgskriterium: 3.3.3 Fehlerempfehlung (AA).

5. Validierung während des Tippens unterbricht die Eingabe

   Problem: Die Prüfung läuft bei jedem Tastendruck. Nach dem zweiten Zeichen der Postleitzahl erscheint schon „zu kurz“, bei einer aufdringlichen Live-Region wird das auch noch bei jedem Zeichen erneut angesagt.

   Test: Tippen Sie ein längeres Feld langsam aus. Wann erscheint die Meldung?

   Lösung: Erst prüfen, wenn das Feld verlassen wird, und Meldungen mit aria-live="polite" ausgeben statt mit assertive. role="alert" ist für Situationen gedacht, die sofortige Aufmerksamkeit erfordern – ein noch nicht fertig getipptes Feld gehört nicht dazu. Fehler dürfen außerdem nicht ausschließlich beim Überfahren mit der Maus erscheinen. Erfolgskriterien: 4.1.3 Statusmeldungen (AA) und 1.4.13 Inhalte bei Hover oder Fokus (AA).

Zustandsänderungen, Ladezustände und Dialoge

Moderne Checkouts laden keine neuen Seiten mehr, sondern tauschen Bereiche aus. Was optisch als flüssiger Ablauf wirkt, ist technisch eine Folge von Zustandswechseln, die angekündigt werden müssen – sonst merkt niemand etwas davon, der den Bildschirm nicht sieht.

1. Statusmeldungen ohne Live-Region

   Problem: „Gutschein eingelöst“, „Adresse gespeichert“, „Zahlungsart geändert“ erscheinen als kurze Einblendung und verschwinden nach drei Sekunden wieder. Ohne Live-Region bleibt die Meldung unbemerkt; ist sie zu schnell wieder weg, hat auch niemand Zeit, sie zu lesen.

   Test: Suchen Sie im Quelltext nach aria-live. Prüfen Sie außerdem, ob eingeblendete Meldungen lange genug stehen bleiben, um sie in Ruhe zu lesen.

   Lösung: Eine dauerhaft im Dokument vorhandene Live-Region, in die Meldungen hineingeschrieben werden: <div aria-live="polite" aria-atomic="true"></div>. Die Region darf beim Einfügen nicht neu erzeugt oder von display: none auf sichtbar geschaltet werden – beides führt dazu, dass die Meldung nicht ankommt. Erfolgskriterium: 4.1.3 Statusmeldungen (AA).

2. Ladezustände existieren nur als Animation

   Problem: Während der Versandkosten-Berechnung dreht sich ein Kreis. Ob gerade etwas passiert, ob es fehlgeschlagen ist oder ob man erneut klicken soll, ist ohne Blick auf die Animation nicht erkennbar.

   Test: Beobachten Sie den Zustand mit gedrosselter Netzwerkverbindung (in den Entwicklerwerkzeugen einstellbar). Gibt es außer der Animation eine textliche Rückmeldung?

   Lösung: Den Zustand in Text übersetzen – „Versandkosten werden berechnet“ in der Live-Region, danach das Ergebnis. Der auslösende Bereich bekommt währenddessen aria-busy="true", die Schaltfläche wird gesperrt, damit kein Doppelklick eine zweite Anfrage auslöst. Erfolgskriterium: 4.1.3 (AA).

3. Beim Schrittwechsel bleibt der Fokus zurück

   Problem: Ein Klick auf „Weiter zur Zahlung“ tauscht den Inhaltsbereich aus, ohne die Seite neu zu laden. Der Fokus bleibt am Button, der gerade aus dem Dokument entfernt wurde – und fällt damit auf den Anfang des Dokuments zurück. Der neue Schritt ist da, aber niemand wird dorthin geführt.

   Test: Wechseln Sie per Tastatur einen Schritt weiter und drücken Sie danach Tab. Landen Sie im neuen Schritt oder in der Hauptnavigation?

   Lösung: Nach dem Wechsel den Fokus auf die Überschrift des neuen Schritts setzen (tabindex="-1" plus focus()) und den Fortschritt textlich benennen, etwa „Schritt 3 von 4: Zahlung“. Der Seitentitel sollte den Schritt ebenfalls widerspiegeln. Erfolgskriterien: 2.4.3 Fokus-Reihenfolge (A) und 4.1.3 (AA).

4. Modale Dialoge ohne Ausweg

   Problem: Ein Dialog fragt nach einer korrigierten Adresse oder bestätigt die Zahlung. Der Fokus wird nicht hineingesetzt, sondern bleibt dahinter; oder er wird hineingesetzt und kommt nie wieder heraus, weil weder Escape noch eine Schließen-Schaltfläche funktionieren. Der zweite Fall ist eine Tastaturfalle und damit ein eigenständiger Verstoß.

   Test: Öffnen Sie den Dialog per Tastatur. Ist der Fokus danach im Dialog? Tabben Sie hindurch – bleiben Sie im Dialog oder landen Sie im Hintergrund? Schließt Escape den Dialog? Wo ist der Fokus danach?

   Lösung: Vier Regeln, die zusammengehören: Fokus beim Öffnen in den Dialog setzen, Fokus innerhalb des Dialogs halten, Escape und eine sichtbare Schließen-Schaltfläche anbieten, Fokus beim Schließen auf das auslösende Element zurückgeben. Am wenigsten Eigenbau erfordert das native <dialog>-Element mit showModal(). Erfolgskriterien: 2.1.2 Keine Tastaturfalle (A), 2.4.3 (A) und 4.1.2 (A).

5. Der Hintergrund ist nur optisch abgedeckt

   Problem: Hinter dem Dialog liegt eine halbtransparente Fläche. Die Elemente darunter sind weiterhin fokussierbar. Wer tabbt, wandert durch ein Formular, das er nicht sieht – oder der Hintergrund wurde per aria-hidden="true" ausgeblendet, enthält aber weiterhin fokussierbare Elemente, sodass der Fokus auf Stationen landet, die nicht angesagt werden.

   Test: Bei geöffnetem Dialog wiederholt Tab drücken und beobachten, ob der Fokusring irgendwann hinter dem Dialog auftaucht.

   Lösung: Den Hintergrund mit dem HTML-Attribut inert auszeichnen – das entfernt ihn zugleich aus der Tab-Reihenfolge und aus dem Zugriff assistiver Technologien. showModal() erledigt das beim nativen Dialog von selbst. Wer aria-hidden einsetzt, muss die enthaltenen Elemente zusätzlich aus der Tab-Reihenfolge nehmen. Erfolgskriterien: 4.1.2 (A) und 2.4.3 (A).

Zeitlimits: Session-Timeout und Warenkorb-Reservierung

Zeitlimits sind im Checkout doppelt heikel. Sie entstehen technisch – die Sitzung läuft ab – und fachlich, etwa wenn ein Kontingent für fünfzehn Minuten reserviert wird. Für Menschen, die langsamer eingeben, weil sie eine Bildschirmvergrößerung, eine Sprachsteuerung oder eine alternative Tastatur nutzen, ist ein knappes Zeitlimit der häufigste Grund, den Kauf nicht abschließen zu können.

Erfolgskriterium 2.2.1 Zeiteinteilung anpassbar (A) verlangt für jedes Zeitlimit mindestens eine dieser Möglichkeiten: das Limit abschalten, es vor dem Erreichen auf mindestens das Zehnfache einstellen, oder es nach einer Warnung mit einer einfachen Handlung verlängern – wobei die Warnung mindestens zwanzig Sekunden vorher erscheinen muss und die Verlängerung mindestens zehnmal möglich sein soll. Ausgenommen sind Zeitlimits, die für ein Echtzeit-Ereignis unvermeidbar sind (etwa ein tatsächlich begrenztes Ticketkontingent) oder für die Funktion wesentlich sind.

1. Die Sitzung läuft still ab

   Problem: Nach dreißig Minuten Inaktivität ist die Sitzung ungültig. Beim nächsten Klick landet man auf der Anmeldeseite, alle Eingaben sind verloren – ohne vorherige Warnung und ohne Möglichkeit, den Zustand zurückzubekommen.

   Test: Füllen Sie den Checkout halb aus, lassen Sie das Fenster offen liegen, kommen Sie nach der Timeout-Zeit zurück und klicken Sie auf „Weiter“. Was passiert mit den Daten?

   Lösung: Vor dem Ablauf einen Dialog anzeigen, der die verbleibende Zeit nennt und eine Schaltfläche „Sitzung verlängern“ anbietet – als korrekt gebauter Dialog mit Fokusführung, siehe oben. Zusätzlich die Eingaben serverseitig zwischenspeichern, sodass sie nach erneuter Anmeldung wieder da sind. Erfolgskriterium: 2.2.1 (A).

2. Der Countdown ist nur eine Zahl

   Problem: Ein Zähler läuft sichtbar herunter. Ohne Ankündigung bekommt niemand mit, dass die Zeit knapp wird – wird der Zähler dagegen in eine Live-Region gelegt, die sich jede Sekunde aktualisiert, wird das Vorlesen der Seite unbrauchbar, weil ständig unterbrochen wird.

   Test: Prüfen Sie im Quelltext, ob der Zähler in einer Live-Region liegt und wie oft er sich ändert.

   Lösung: Den laufenden Zähler nicht in eine Live-Region legen, sondern nur zu Meilensteinen melden (etwa bei fünf Minuten, bei einer Minute) und dabei aria-live="polite" verwenden. Der Zähler selbst bleibt sichtbar und per Fokus abrufbar. Erfolgskriterien: 2.2.1 (A) und 4.1.3 Statusmeldungen (AA).

3. Automatische Weiterleitung per meta refresh

   Problem: Nach der Zahlung leitet eine Zwischenseite per <meta http-equiv="refresh"> weiter. Die Seite wechselt mitten im Lesen, der Kontext geht verloren, und das Zeitlimit lässt sich nicht beeinflussen.

   Test: Suchen Sie im Quelltext der Zwischenseiten nach http-equiv="refresh".

   Lösung: Weiterleitungen serverseitig umsetzen (HTTP 301 oder 302) oder eine Schaltfläche anbieten, mit der man selbst weitergeht. Erfolgskriterium: 2.2.1 Zeiteinteilung anpassbar (A).

Wer es genauer nehmen möchte: WCAG 2.1 kennt mit 2.2.6 Timeouts noch ein Kriterium auf Stufe AAA, das verlangt, vor einem drohenden Datenverlust ausdrücklich zu warnen. Für die AA-Ebene ist es nicht gefordert, im Checkout aber eine naheliegende und billige Ergänzung.

Durchgängig zu prüfen: Tastatur, Zoom und Kontrast

Drei Prüfungen gelten nicht für einen einzelnen Schritt, sondern für den gesamten Ablauf. Sie sind zugleich die drei Tests, die am schnellsten gehen und am meisten finden.

Tastaturbedienung von Anfang bis Ende

Legen Sie die Maus beiseite und kaufen Sie einen Artikel. Nur Tab, Umschalt+Tab, Pfeiltasten, Leertaste, Enter und Escape. Vier Kriterien werden dabei gleichzeitig geprüft:

• 2.1.1 Tastatur (A): Jede Funktion muss erreichbar sein. Typische Ausfälle sind Kacheln und Symbole aus <div>-Elementen, Aufklapp-Bereiche und scrollbare Boxen – etwa das AGB-Fenster, das sich per Tastatur nicht scrollen lässt, weil dem Container tabindex="0" fehlt.
• 2.1.2 Keine Tastaturfalle (A): Aus jedem Bereich muss man auch wieder heraus. Kandidaten sind Dialoge, eingebettete Zahlungsfelder und Karten-Widgets.
• 2.4.3 Fokus-Reihenfolge (A): Der Fokus folgt der Reihenfolge im Markup, nicht der optischen Anordnung. Wird per CSS umsortiert (etwa mit order im Flexbox-Layout), springt der Fokus für Sehende unlogisch. Positive tabindex-Werte über null erzeugen dasselbe Problem und gehören entfernt.
• 2.4.7 Fokus sichtbar (AA): An jeder Station muss erkennbar sein, wo man ist. Ein outline: none ohne Ersatz im Theme macht den kompletten Checkout unbedienbar, ohne dass es beim Mausbetrieb je auffällt. Ersatz aufbauen mit :focus-visible und einem Ring, der auch auf farbigen Schaltflächen sichtbar bleibt.

Zoom und Reflow

Stellen Sie das Browserfenster auf etwa 1280 Pixel Breite und zoomen Sie auf 200 Prozent, danach auf 400 Prozent. Zwei Kriterien greifen hier:

• 1.4.4 Textgröße ändern (AA): Bei 200 Prozent darf kein Inhalt und keine Funktion verloren gehen. Häufigster Blocker ist eine Angabe wie user-scalable=no oder maximum-scale=1 im viewport-Meta-Tag, die das Vergrößern auf Mobilgeräten unterbindet.
• 1.4.10 Reflow (AA): Bei 400 Prozent – das entspricht rund 320 Pixel nutzbarer Breite – darf nicht in zwei Richtungen gescrollt werden müssen. Die klassischen Bruchstellen im Checkout: die Warenkorb-Tabelle, die stur breit bleibt, und feste Breiten in Pixeln an Formularspalten.

Eine wichtige Feinheit zur Warenkorb-Tabelle: Datentabellen sind von 1.4.10 ausdrücklich ausgenommen, weil sie eine zweidimensionale Anordnung brauchen. Horizontales Scrollen innerhalb der Tabelle ist also zulässig – nur die Seite als Ganzes darf nicht seitwärts scrollen. Wer die Tabelle in einen eigenen Scrollbereich legt, muss diesen allerdings per Tastatur erreichbar machen.

Die zweite Bruchstelle sind fixierte Leisten: eine oben klebende Fortschrittsanzeige plus eine unten klebende Zusammenfassung mit „Weiter“-Schaltfläche. Bei 400 Prozent belegen beide zusammen leicht die halbe Fensterhöhe, und das fokussierte Feld verschwindet darunter. Praktische Lösung: Fixierungen ab einer bestimmten Fensterhöhe per Media-Query aufheben. WCAG 2.2 hat für genau diesen Fall mit 2.4.11 Fokus nicht verdeckt (Minimum) (AA) ein eigenes Kriterium ergänzt.

Kontraste, auch in Sonderzuständen

1.4.3 Kontrast (Minimum) (AA) verlangt 4,5:1 für normalen Text und 3:1 für großen Text ab 24 Pixel beziehungsweise 18,66 Pixel bei Fettung. Im Checkout fallen regelmäßig dieselben Stellen durch: Platzhaltertext, Hinweistexte in Grau unter den Feldern, die Sekundär-Schaltfläche „Zurück“ und Preisangaben in der Markenfarbe auf farbigem Grund. Prüfen können Sie das ohne Zusatzsoftware mit dem Farbwähler in den Entwicklerwerkzeugen des Browsers, der den Kontrastwert direkt anzeigt.

Dazu kommt 1.4.11 Kontrast von Nicht-Text-Inhalten (AA) mit 3:1 für die Grenzen von Bedienelementen und für Zustandsanzeigen: der Rahmen eines Eingabefelds, der Haken in der Checkbox, der Punkt im ausgewählten Optionsfeld, der Fokusring. Ein hellgrauer Rahmen auf weißem Grund ist hier der häufigste Befund.

Und ein Punkt, den wir bewusst ehrlich benennen: Deaktivierte Bedienelemente sind von 1.4.3 ausgenommen – ein ausgegrauter „Weiter“-Button verletzt das Kriterium formal nicht. Praktisch ist er trotzdem ein Abbruchgrund, weil niemand lesen kann, was die Schaltfläche tun würde und warum sie gesperrt ist. Die bessere Lösung ist ohnehin, die Schaltfläche gar nicht zu sperren, sondern beim Klick die offenen Punkte als Fehler zu benennen. Dann weiß man, was fehlt, statt vor einer grauen Fläche zu stehen.

Was ein automatisierter Scan im Checkout findet – und was nicht

Wir verkaufen automatisierte Prüfung. Trotzdem – oder gerade deshalb – gehört dieser Abschnitt in diesen Artikel: Nirgendwo klafft die Lücke zwischen dem, was ein Werkzeug messen kann, und dem, was eine Seite bedienbar macht, so weit auseinander wie im Bestellprozess.

Der Grund ist einfach. Ein Prüfwerkzeug lädt eine Adresse und untersucht das Dokument in genau diesem Moment. Der Checkout dagegen ist eine Folge von Zuständen: leerer Warenkorb, gefüllter Warenkorb, Schritt zwei mit Validierungsfehler, geöffneter Adressdialog, geladenes Zahlungsfeld, Bestätigungsseite. Die meisten dieser Zustände entstehen erst durch Eingaben – Anmeldung, Adresse, Testzahlung. Ein Scan, der von außen anläuft, sieht sie schlicht nicht. Dazu kommt, dass viele Shops Warenkorb- und Checkout-Adressen für automatisierte Zugriffe sperren.

Die rechte Spalte ist keine Randmenge. Sie enthält genau die Befunde, die im Checkout zum Abbruch führen. Deshalb gilt hier der Satz, der in jedem unserer Berichte steht, besonders deutlich: Automatisierte Prüfung deckt die maschinell prüfbaren Kriterien ab; eine vollständige Konformitätsbewertung erfordert zusätzlich manuelle Prüfung.

Praktisch heißt das: Nutzen Sie den Scan für das, was er gut kann – die Masse der Beschriftungs-, Namens- und Kontrastbefunde über alle Vorlagen hinweg zu finden und der verursachenden Vorlage zuzuordnen. Und planen Sie zusätzlich einen manuellen Durchgang ein. Für einen typischen dreistufigen Checkout dauert der eine bis zwei Stunden: einmal komplett mit der Tastatur, einmal bei 400 Prozent Zoom, einmal mit absichtlich falschen Eingaben. Wenn Sie darüber hinaus einen Screenreader-Durchgang machen können, umso besser – aber die drei genannten Durchgänge finden bereits den Großteil.

Für die Aufwandsplanung ist das der Punkt, an dem interaktive Komponenten teurer werden als der Rest der Website; wie sich das auf ein Budget auswirkt, steht im Artikel Was kostet die BFSG-Umsetzung wirklich?. Und weil jedes Theme-Update, jede neue Zahlungsart und jedes Update beim Zahlungsdienstleister den Checkout verändern kann, ist dieser Durchgang keine einmalige Aufgabe, sondern gehört an jedes Release.

Häufige Fragen

Dieser Artikel ist eine technische Einordnung und keine Rechtsberatung. Quellen: Gesetz zur Stärkung der Barrierefreiheit von Produkten und Dienstleistungen (BFSG), insbesondere §§ 3, 14 und 37; Barrierefreiheitsstärkungsgesetz-Verordnung (BFSGV); EN 301 549 in Verbindung mit WCAG 2.1, dort insbesondere die Erfolgskriterien 1.1.1, 1.3.1, 1.3.5, 1.4.1, 1.4.3, 1.4.4, 1.4.10, 1.4.11, 1.4.13, 2.1.1, 2.1.2, 2.2.1, 2.4.3, 2.4.6, 2.4.7, 2.5.3, 3.2.2, 3.3.1, 3.3.2, 3.3.3, 3.3.4 und 4.1.3. Die beschriebenen Befundmuster stammen aus eigenen Prüfläufen und manuellen Durchgängen durch Bestellprozesse.