Barrierefreie Shopify-Checkout-Formulare: die Reihenfolge, die auch konvertiert

Irgendwo auf Ihrer Roadmap steht eine Zeile mit EAA-Compliance. Sie liegt bei der Rechtsabteilung oder der Entwicklung und ist als Kostenpunkt eingeplant. An anderer Stelle steht ein CRO-Backlog, verantwortet vom Growth-Team und als Umsatzhebel eingeplant. Beide betreffen dasselbe Checkout-Formular. Trotzdem treffen sich die beiden Listen selten, weil sie in unterschiedlichen Begriffen formuliert sind und in unterschiedlichen Sprints landen.

Die Maßnahmen dahinter überschneiden sich fast vollständig. Labels, die stehen bleiben, Fehlermeldungen, die genau sagen, was falsch ist, ein Checkout, den man allein mit der Tastatur abschließen kann: Ein Barrierefreiheits-Auditor und ein Conversion-Spezialist würden dieselben Punkte notieren. Über das Ergebnis entscheidet die Reihenfolge, in der Sie sie umsetzen. Und diese Reihenfolge hängt von etwas ab, das die meisten Checklisten auslassen: auf welchem Shopify-Checkout Sie tatsächlich arbeiten.

Der Anfang: Auf welchem Checkout bauen Sie eigentlich?

In welcher Reihenfolge Sie barrierefreie Checkout-Formulare umsetzen, hängt vom Shopify-Checkout ab, den Sie nutzen. Er entscheidet, wie viel vom Formular Sie überhaupt ändern können. Der Standard-Checkout von Shopify ist bereits weitgehend barrierefrei und muss vor allem geschützt werden. Checkout Extensibility auf Plus und Headless-Builds geben Ihnen mehr vom Formular in die Hand und damit auch mehr Verantwortung für Barrierefreiheit und Conversion.

Dieser Unterschied wiegt schwerer als jede einzelne Maßnahme. Eine flache „Barrierefreiheits-Checkliste mit 40 Punkten“ gibt einem Shop auf dem Standard-Checkout dieselbe Liste wie einem Team mit eigenem Plus-Build, obwohl deren Prioritäten fast umgekehrt liegen. Die Liste ist dieselbe. Die Reihenfolge nicht.

Shopify stellt in seinen eigenen Barrierefreiheits-Richtlinien für Entwicklungen auf der Plattform klar, dass Standardkomponenten bereits mit Labels, Fokussteuerung und Tastaturunterstützung ausgeliefert werden. Praktisch heißt das: Auf dem Standard-Checkout liegt Ihr Risiko nicht im Formular, das Shopify Ihnen gibt. Es liegt in dem, was eine Theme-Anpassung oder eine Drittanbieter-App unbemerkt darüberlegt. Auf Plus Checkout Extensibility übernimmt jede Extension und jedes eigene Feld dieselbe Verantwortung für Barrierefreiheit, die die Standardfelder bereits trugen. Und wenn Sie eine Headless-Storefront betreiben, liegen die selbst gebauten Teile des Ablaufs (Warenkorb, Adresserfassung, jeder Schritt vor der von Shopify gehosteten Zahlungsseite) vollständig bei Ihnen, auch wenn die Zahlungsseite selbst das nicht tut.

Bevor Sie also ein einziges Label anfassen, verorten Sie sich in dieser Tabelle. Sie zeigt, ob vor Ihnen eine Schutzaufgabe, ein Audit Ihrer Extensions oder ein kompletter Build liegt. Alles Weitere folgt aus dieser Antwort. (Was anpassbar wurde, als Shopify alle Shops auf das neue Framework umgestellt hat, beschreibt unser Beitrag zu Shopify Checkout Extensibility. Dort steht, wofür Sie jetzt verantwortlich sind.)

Zuerst: Labels für Screenreader und Autofill

Beginnen Sie mit den Feldlabels, denn eine Maßnahme bedient hier zwei Systeme zugleich. Ein Checkout-Feld braucht ein programmatisches Label (ein echtes <label>, das mit dem Eingabefeld verknüpft ist, oder ein gleichwertiges aria-label) und zusätzlich ein sichtbares. Dasselbe Label, das ein Screenreader vorliest, nutzen Browser, Passwortmanager und Autofill auf dem Smartphone, um das Feld automatisch auszufüllen.

Deshalb stehen Labels in der Reihenfolge ganz vorn. Jede andere Maßnahme hilft einer Gruppe von Kunden oder einem Moment im Ablauf. Labels helfen allen, auf jedem Checkout, vom ersten Durchgang an. Ein Feld, das assistive Technologie lesen kann, kann Autofill auch ausfüllen. Und die meisten Checkouts finden auf dem Smartphone statt, wo Autofill die Hauptarbeit leistet.

Der Fehler ist tückisch, weil das Formular trotzdem fertig aussieht. Ein Platzhalter mit „Adresszeile 2“ wirkt wie ein Label, bis der Kunde zu tippen beginnt und der Hinweis verschwindet. Dann bleibt einem Screenreader-Nutzer ein namenloses Feld, und ein sehender Kunde fragt sich, in welchem Feld er gerade ist. Dasselbe Feld ohne Label ist für Autofill unsichtbar. Das Smartphone, das es mit einem Tippen ausgefüllt hätte, verlangt jetzt Handarbeit. Platzhaltertext ist ein Hinweis, kein Label. Behandeln Sie ihn als Dekoration, verlieren beide Systeme das Feld.

Zwei Ergänzungen machen es komplett und kosten fast nichts. Geben Sie jedem Eingabefeld das passende autocomplete-Attribut (email, given-name, postal-code und so weiter), damit der Browser weiß, was hineingehört. Und muss ein Label aus Layoutgründen unsichtbar sein, verstecken Sie es mit einer Screenreader-tauglichen Utility-Klasse, statt es zu löschen. So bleibt der programmatische Name erhalten, auch wenn der sichtbare wegfallen muss. Für einen Screenreader und für eine mobile Tastatur ist das Ergebnis dasselbe: ein Formular, das seine Felder selbst benennt.

Danach: Fehlermeldungen, die das Problem benennen

Eine barrierefreie Fehlermeldung leistet drei Dinge zugleich. Sie sagt, welches Feld fehlerhaft ist, sie sagt in klaren Worten, warum, und sie meldet sich beim Screenreader, statt nur als roter Rahmen zu erscheinen. Im Markup heißt das: Die Meldung ist über aria-describedby mit ihrem Eingabefeld verknüpft und wird über eine aria-live-Region an assistive Technologie übergeben, damit man sie hört und nicht nur sieht.

Für die Conversion gilt genau dieselbe Logik, nur aus Sicht des Kunden. Eine Fehlermeldung, die das Feld nennt, macht aus einem Abbruch einen zweiten Versuch. „Bitte geben Sie eine gültige Postleitzahl ein“ führt direkt zur Lösung. Ein allgemeines Banner mit „Etwas ist schiefgelaufen“ oder ein Feld, das ohne Text einfach rot wird, zwingt den Kunden, das Problem selbst zu suchen. Und genau beim Suchen im Zahlungsschritt werden Warenkörbe abgebrochen. Ein Screenreader-Nutzer erlebt denselben Fehler in schlimmerer Form: Die Validierung greift, der Rahmen ändert sich, und nichts wird vorgelesen. Er erfährt, dass die Bestellung fehlgeschlagen ist, aber nicht, wo. Beide stoßen an dieselbe Wand. Einer von ihnen kann sie nicht einmal sehen.

Pflichtfelder bergen eine leisere Variante derselben Falle. Ein rotes Sternchen allein sagt einem Kunden, der Farben nicht unterscheiden kann, gar nichts, und etwa jeder zwölfte Mann hat eine Form von Farbsehschwäche. Kennzeichnen Sie Pflichtfelder mit dem Wort „Pflichtfeld“ im Label oder mit dem passenden ARIA-Attribut, nicht nur mit Farbe. Dann kommt der Hinweis bei allen an: bei farbenblinden Kunden, bei Screenreader-Nutzern und bei dem sehenden Kunden, der zu schnell überfliegt, um eine Legende zu entschlüsseln.

Die Reihenfolge hat einen Grund. Labels sagen, was ein Feld ist; die Fehlerbehandlung sagt, was zu tun ist, wenn ein Feld nicht stimmt. Korrigieren Sie zuerst die Labels, dann treten viele Validierungsfehler gar nicht erst auf, denn ein korrekt beschriftetes und automatisch ausgefülltes Feld ist beim ersten Mal richtig ausgefüllt. Bauen Sie die Fehlermeldungen als Zweites, fangen Sie auf, was noch durchrutscht, statt ein Formular zu flicken, das niemand lesen konnte.

Dann: ein Checkout, der allein per Tastatur funktioniert

Ein Kunde sollte den gesamten Kauf, vom Warenkorb bis zur abgeschickten Bestellung, allein mit der Tastatur durchlaufen können. Ein sichtbarer Fokusrahmen zeigt, wo er sich befindet, und die Fokusreihenfolge folgt der Leserichtung der Seite. Verschwindet der Rahmen beim Tabben durch den Checkout, springt der Fokus quer über die Seite oder bleibt er in einer Komponente hängen, dann ist der Ablauf für Tastatur- und Screenreader-Nutzer kaputt. Und für alle anderen unbemerkt schlechter.

Das steht an dritter und nicht an erster Stelle, weil es auf dem Standard-Checkout von Shopify größtenteils schon gelöst ist. Die Barrierefreiheitsanforderungen für Themes von Shopify beschreiben das Verhalten, auf das der Standard ausgelegt ist: ein sichtbarer Fokusrahmen auf jedem interaktiven Element, eine Fokusreihenfolge von oben nach unten und von links nach rechts, und Modals und Warenkorb-Drawer, die den Fokus zu sich holen und bei Esc zurückgeben. Ihre Aufgabe ist nicht, das nachzubauen. Sie müssen sicherstellen, dass nichts, was Sie hinzugefügt haben, es beschädigt hat.

Die Tastaturbedienung bricht an derselben Stelle, an der Labels und Fehlermeldungen brachen. Deshalb lohnt es sich, das Muster einmal zu benennen und dann wiederzuverwenden. Eigene Komponenten sind die Schwachstelle. Ein Warenkorb-Drawer, der herausfährt, aber den Fokus nie zu sich holt, lässt einen Tastatur-Nutzer dahinter weitertabben, durch die Seite, die er verlassen zu haben glaubte. Eine eigene Datums- oder Variantenauswahl ohne Tastatursteuerung wird mitten im Checkout zur Sackgasse. Ein CSS-Override, der den Fokusrahmen entfernt, weil es aufgeräumter aussieht, nimmt einem Tastatur-Nutzer das einzige Signal, das ihm zeigt, wo er ist. Betrachten Sie die Tastaturbedienbarkeit als Frühwarnsystem für Ihre Anpassungen: Kommt eine Tastatur nicht durch eine Komponente, die Sie hinzugefügt haben, kommt auch die Conversion nicht durch, die daran hing.

Eine Anforderung wird leicht übersehen, weil sie eher nach Mobile-Design klingt als nach Barrierefreiheit. Interaktive Elemente, auch der Bestellbutton, müssen groß genug sein, um sie zuverlässig zu treffen: etwa 44 mal 44 Pixel. Diese Größe schützt Kunden mit motorischen Einschränkungen. Und auf dem Smartphone, wo die meisten Ihrer Checkouts stattfinden, schützt sie jeden Daumen, der nach „Bestellung aufgeben“ greift. Eine Schaltfläche, die zu klein zum Antippen ist, ist ein Barrierefreiheitsfehler und ein Abbruchgrund, im selben Pixel.

Wo diese Reihenfolge bricht: eigene Felder, Apps und Extensions

Eine feste Reihenfolge schlägt eine Checkliste, weil der Standard selten versagt. Was versagt, ist alles, was darauf aufgesetzt wird, und Ergänzungen haben eine zeitliche Abfolge, die eine flache Liste nicht abbilden kann. Der Standard-Checkout von Shopify bringt Labels, Fehlerbehandlung und Tastaturunterstützung bereits mit. Das Feld für die Geschenkquittung, das eine App im letzten Quartal eingefügt hat, die Lieferdatumsauswahl, die ein Entwickler angeschraubt hat, das Upsell-Widget zwischen Adressschritt und Zahlung: All das kam nach dem Audit, mit dem der Checkout abgenommen wurde. Jedes davon hat die Verantwortung der Standardfelder geerbt, aber nicht die Sorgfalt, mit der diese gebaut wurden.

Damit ändert sich, was „den Checkout prüfen“ überhaupt heißt. Ein Audit liest das Formular von links nach rechts und von oben nach unten, so wie die Seite gerendert wird. Eine Reihenfolge liest es nach Herkunft: Was haben wir hinzugefügt, in welcher Abfolge, und welche Ergänzung hat am wahrscheinlichsten den Screenreader, die Fehleransagen oder den Tastaturpfad beschädigt? Das neueste und am stärksten angepasste Feld ist der erste Verdächtige, nicht der letzte. Es hatte die meisten Gelegenheiten, einen Standard zu überschreiben, und wurde beim Einbau am wenigsten geprüft.

Das Risiko wächst mit dem Anteil am Formular, der bei Ihnen liegt, und hier zahlt sich die Tabelle vom Anfang aus. Auf dem Standard-Checkout ist das Audit kurz: Gehen Sie die Apps und Theme-Anpassungen durch, die den Checkout berühren, und prüfen Sie, dass keine davon ein Label oder einen Fokusrahmen entfernt hat. Auf Plus Checkout Extensibility ist jede UI-Extension ein kleines Formular für sich, mit eigenen Labels, Fehlermeldungen und eigenem Fokusverhalten. Das prüfen Sie vor dem Livegang, nicht erst, wenn ein Kunde es meldet. Bei einem Headless-Build gibt es für die selbst gebauten Schritte keinen Standard, auf den Sie zurückfallen können. Der gesamte eigene Ablauf trägt also das volle Gewicht der drei Maßnahmen oben. Jedes Mal dieselben drei Maßnahmen. Nur die Fläche, auf der sie greifen müssen, ändert sich.

Darin steckt eine Governance-Frage, und genau die übergehen die meisten Teams. Wenn Ergänzungen einen barrierefreien Checkout beschädigen, dann ist Barrierefreiheit kein Projekt mit Enddatum. Sie ist eine Schranke, die jedes neue Feld, jede App und jede Extension passieren muss, bevor sie den Checkout erreicht. Die Teams, deren Checkout barrierefrei bleibt, haben nicht einmal besonders gründlich geprüft. Sie haben aufgehört, Komponenten ohne Labels und ohne Tastaturbedienung überhaupt in den Ablauf zu bringen.

Den Build prüfen, nicht nur ausliefern

Die Prüfung eines barrierefreien Checkouts besteht aus drei Durchgängen durch den einen Ablauf, auf den es ankommt. Schließen Sie einen echten Kauf nur mit der Tastatur ab, dann noch einmal mit laufendem Screenreader, und starten Sie einen automatischen Scan für das, was beide Durchgänge übersehen. Alle drei laufen komplett durch, vom Warenkorb bis zur Bestätigung, denn genau am Checkout hört das Testen auf Template-Ebene auf.

Der Tastatur-Durchgang liefert das schnellste Signal und kommt deshalb zuerst. Legen Sie die Maus weg, tabben Sie vom Warenkorb bis zur abgeschickten Bestellung und achten Sie auf drei Dinge: einen Fokusrahmen, den Sie immer sehen, eine Fokusreihenfolge, die nie unerwartet springt, und keine Komponente, in der Sie festhängen oder die Sie nicht bedienen können. Bleiben Sie hängen, bleibt ein Kunde, der nur die Tastatur nutzt, an derselben Stelle hängen. Ebenso ein großer Teil der Screenreader-Nutzer, die auf dieselbe Weise navigieren. Der Screenreader-Durchgang ist die zweite Lesung, mit NVDA, VoiceOver oder TalkBack. Hören Sie hin, ob jedes Feld sein Label ansagt, ob Fehler vorgelesen werden, wenn die Validierung fehlschlägt, und ob die Reihenfolge des Gehörten der Reihenfolge des Formulars entspricht.

Automatische Scanner kommen zuletzt und in Maßen. Sie helfen, Regressionen regelmäßig aufzuspüren und offensichtliche Kontrast- und Label-Fehler zu markieren. Sie finden aber nur einen Bruchteil der echten Barrieren; häufig wird etwa ein Drittel genannt. Ein grüner Score auf einem Checkout, den man per Tastatur nicht abschließen kann, ist eine trügerische Sicherheit. Nutzen Sie den Scan, um Veränderungen über die Zeit zu beobachten, nicht um den Ablauf abzunehmen. Das leisten die manuellen Durchgänge.

Eine Gewohnheit verhindert, dass die ganze Reihenfolge verfällt. Machen Sie den Durchgang mit Tastatur und Screenreader nicht einmal am Ende, sondern jedes Mal, wenn ein neues Feld, eine neue App oder eine neue Extension in den Checkout kommt. Genau diese Ergänzungen machen die Arbeit unbemerkt zunichte. Die Prüfung ist nicht der letzte Schritt des Projekts. Sie ist die Schranke aus dem vorigen Abschnitt, nur in anderer Form.

Häufige Fragen

Steigert ein barrierefreier Checkout wirklich die Conversion, oder geht es nur um Compliance? 

Beides, mit denselben Maßnahmen. Beschriftete Felder werden schneller automatisch ausgefüllt, konkrete Fehlermeldungen machen aus Abbrüchen neue Versuche, und ein per Tastatur bedienbarer Ablauf beseitigt Reibung, die jeder Kunde spürt. Barrierefreiheit und Conversion-Optimierung sind dieselbe Aufgabenliste, nur in zwei Fachsprachen formuliert. Warum sich beides so stark überschneidet, lesen Sie im unten verlinkten Beitrag.

Ist der Standard-Checkout von Shopify bereits barrierefrei? 

Weitgehend ja. Der Standard-Checkout von Shopify bringt programmatische Labels, vorgelesene Fehlermeldungen, Tastaturunterstützung und Fokussteuerung bereits mit. Die Barrieren entstehen meist durch das, was darauf aufsetzt: CSS-Overrides im Theme, Drittanbieter-Apps und eigene Felder oder Extensions, die ein Label oder einen Fokusrahmen entfernen, den der Standard nie verloren hat. Testen Sie Ihren eigenen Checkout, statt anzunehmen, dass der Standard erhalten geblieben ist.

Kann ich die Barrierefreiheit im Checkout ohne Entwickler verbessern? 

Zum Teil. Farbkontraste korrigieren, konkrete Fehlertexte schreiben und Pflichtfelder mit Worten statt nur mit Farbe kennzeichnen: Das sind oft Änderungen im Theme-Editor oder am Text. Programmatische Labels, aria-live-Ansagen, Fokussteuerung in eigenen Komponenten und alles, was eine Plus-Extension oder einen Headless-Ablauf berührt, braucht in der Regel einen Entwickler.

Was beeinträchtigt die Barrierefreiheit bei Plus- oder individuellen Checkouts am häufigsten? 

Ergänzungen. Eigene Felder, Upsell-Widgets, Lieferdatumsauswahlen und App-Integrationen sind die üblichen Verursacher. Jede davon erbt die Verantwortung der Standardfelder, wird aber selten genauso gründlich geprüft. Fehlende Formularlabels und ein Tastaturfokus, der in eigenen Komponenten gefangen ist, werden am häufigsten genannt, und beide verhindern direkt Käufe.

Das Wichtigste in Kürze

• Ihr Checkout-Typ bestimmt die Reihenfolge für barrierefreie Checkout-Formulare. Beim Standard-Checkout geht es um Schutz, bei Plus Extensibility um ein Audit der Extensions, und Headless ist ein kompletter Build.

• Labels kommen zuerst, weil eine Maßnahme zwei Systeme bedient: Das Label, das ein Screenreader vorliest, ist das Label, mit dem Autofill das Feld ausfüllt.

• Fehlermeldungen kommen als Zweites. Konkrete, dem Feld zugeordnete und vorgelesene Fehler machen aus einem Abbruch einen zweiten Versuch, ob der Kunde sehen kann oder nicht.

• Tastaturbedienbarkeit ist das Frühwarnsystem für Ihre Anpassungen. Kommt eine Tastatur nicht durch eine Komponente, die Sie hinzugefügt haben, kommt auch die Conversion nicht durch, die daran hing.

• Der Standard versagt selten, Ergänzungen schon. Prüfen Sie nach Herkunft (das Neueste und am stärksten Angepasste zuerst), nicht von links nach rechts.

• Prüfen Sie mit einem Tastatur- und einem Screenreader-Durchgang von Anfang bis Ende. Automatische Scanner finden nur einen Bruchteil, nutzen Sie sie also gegen schleichende Veränderungen, nicht zur Abnahme.

Ein Checkout, eine Reihenfolge

Barrierefreie Checkout-Formulare und Checkout-Formulare mit hoher Conversion sind keine zwei Projekte, die um denselben Sprint konkurrieren. Es ist ein Build, und die Reihenfolge oben verhindert, dass Sie eine Compliance-Frist und ein Conversion-Backlog zweimal abarbeiten. Speichern Sie diese Abfolge und teilen Sie sie mit der Person, die die nächste Änderung an Ihrem Checkout verantwortet. Die Arbeit hält nur, wenn auch derjenige sie durchläuft, der das nächste Feld hinzufügt.

Eine erfahrene Shopify-Plus-Agentur behandelt eine solche Reihenfolge bei jedem Checkout-Projekt als Standard, nicht als Sonderwunsch.

Wenn Sie das Warum dahinter für Ihr Team noch deutlicher machen möchten: Der Beitrag darüber, wie barrierefreie Checkout-Verbesserungen die Shopify-Conversion steigern, beschreibt die Überschneidung ausführlich: dieselben Labels, Fehlermeldungen und Tastaturpfade, betrachtet von der Umsatzseite.