Ein barrierefreies Formular erstellst du mit sichtbaren Beschriftungen, die im Code mit ihrem Feld verknüpft sind, den richtigen Autocomplete-Attributen, Fehlermeldungen als Text beim Feld und einer Reihenfolge, die nur mit der Tastatur funktioniert. Für einen Onlineshop gilt das besonders streng für den Checkout. Dort springt ein Besucher, der nicht weiterkommt, sofort ab, und genau dort schaut der European Accessibility Act gezielt hin.
Dieser Artikel gehört zu unserem vollständigen Leitfaden zur Barrierefreiheit von Websites. Wir gehen die Erfolgskriterien aus WCAG 2.2 durch, die in Formularen am häufigsten schiefgehen, mit Codebeispielen, die du direkt übernehmen kannst. Jede Kriteriumsnummer und Stufe stammt aus der offiziellen WCAG-2.2-Spezifikation.
Willst du zuerst das große Ganze von WCAG 2.2 und den neuen Kriterien, lies WCAG 2.2 erklärt.
Warum der European Accessibility Act den E-Commerce betrifft
Der European Accessibility Act nennt E-Commerce-Dienste ausdrücklich als Dienstleistung, die barrierefrei sein muss. In der Richtlinie (EU) 2019/882 stehen „Dienstleistungen im elektronischen Geschäftsverkehr“ in Artikel 2 Absatz 2 Buchstabe f. Artikel 3 beschreibt sie als Dienstleistungen, die im Fernabsatz über Websites und mobile Dienste auf Anfrage eines Verbrauchers im Hinblick auf einen Verbrauchervertrag erbracht werden. Die Mitgliedstaaten wenden die Vorschriften ab dem 28. Juni 2025 an.
Anhang I Abschnitt IV Buchstabe g macht es für Onlineshops konkret. Du stellst die verfügbaren Barrierefreiheitsinformationen zu den Produkten bereit, die du verkaufst. Und die Funktionen für Identifizierung, Sicherheit und Zahlung müssen wahrnehmbar, bedienbar, verständlich und robust sein. Das sind genau deine Login-, Konto- und Bestellformulare.
Ein Kleinstunternehmen, das Dienstleistungen erbringt, ist laut Artikel 4 Absatz 5 von diesen Anforderungen befreit. Ob der EAA für dein Unternehmen gilt, liest du unter European Accessibility Act. Dieser Artikel ist eine Erklärung, keine Rechtsberatung; frag im Zweifel einen Juristen.
Beschriftungen: jedes Feld mit einem sichtbaren, verknüpften Namen
Jedes Eingabefeld braucht eine sichtbare Beschriftung, die im Code mit dem Feld verknüpft ist. Kriterium 3.3.2 Labels or Instructions (Stufe A) verlangt Beschriftungen oder Anweisungen, wo eine Eingabe nötig ist. Kriterium 1.3.1 Info and Relationships (Stufe A) verlangt, dass die Beziehung zwischen Beschriftung und Feld auch programmatisch ermittelbar ist, damit ein Screenreader die Beschriftung vorliest, wenn das Feld den Fokus bekommt.
Am einfachsten geht das mit einem label-Element mit einem for-Attribut, das auf die id des Feldes verweist. Ein Klick auf die Beschriftung setzt dann auch den Cursor ins Feld, was auf kleinen Bildschirmen hilft.
<label for="email">E-Mail-Adresse</label>
<input type="email" id="email" name="email" autocomplete="email" required>
<!-- Nicht so: nur ein Platzhalter -->
<input type="email" placeholder="E-Mail-Adresse">
Ein Platzhalter ist keine Beschriftung. Er verschwindet beim Tippen, hat oft wenig Kontrast und lässt sich nach dem Ausfüllen nicht mehr prüfen. Nutze einen Platzhalter höchstens für ein Beispiel, etwa "10115".
Autocomplete: Lass den Browser die Arbeit machen
Mit Autocomplete-Attributen sagst du dem Browser, welche Art von Daten ein Feld abfragt, damit er es automatisch ausfüllen kann. Kriterium 1.3.5 Identify Input Purpose (Stufe AA) verlangt, dass der Zweck von Feldern für Daten über den Nutzer selbst programmatisch ermittelbar ist. WCAG listet die gültigen Zwecke in einer festen Liste auf, darunter Name, E-Mail, Telefon, Adresse, Postleitzahl und Zahlungsdaten.
Für Menschen mit motorischen oder kognitiven Einschränkungen erspart das viel Tipparbeit und Fehler. Für alle macht es den Checkout schneller.
<label for="name">Vollständiger Name</label>
<input id="name" name="name" autocomplete="name">
<label for="strasse">Straße und Hausnummer</label>
<input id="strasse" name="strasse" autocomplete="street-address">
<label for="plz">Postleitzahl</label>
<input id="plz" name="plz" autocomplete="postal-code">
<label for="ort">Ort</label>
<input id="ort" name="ort" autocomplete="address-level2">
<label for="tel">Telefonnummer (optional)</label>
<input type="tel" id="tel" name="tel" autocomplete="tel">
Pflichtfelder und Gruppieren mit fieldset
Pflichtfelder markierst du sowohl sichtbar als auch im Code, und zusammengehörige Felder gruppierst du mit fieldset und legend. Das required-Attribut sorgt dafür, dass ein Screenreader "erforderlich" vorliest. Verwendest du ein Sternchen, erklär oben, was es bedeutet. Sind fast alle Felder Pflicht, markiere lieber die wenigen optionalen Felder.
Ein fieldset mit legend fällt unter Kriterium 1.3.1. Es ist vor allem bei Optionsfeldern und Kontrollkästchen nötig, wo die Beschriftung einer Option ohne die Frage keine Bedeutung hat. "Abholung" sagt wenig; "Versandart: Abholung" schon.
<fieldset>
<legend>Versandart</legend>
<input type="radio" id="versand-haus" name="versand" value="haustuer" required>
<label for="versand-haus">Lieferung nach Hause</label>
<input type="radio" id="versand-abhol" name="versand" value="abholstelle">
<label for="versand-abhol">Abholstelle</label>
</fieldset>
Nutze fieldset auch, um Rechnungsadresse und Lieferadresse voneinander zu trennen. Ohne Gruppe hört ein Screenreader-Nutzer zweimal "Postleitzahl", ohne zu wissen, zu welcher Adresse.
Fehlermeldungen und Korrekturvorschläge
Eine Fehlermeldung muss als Text sagen, welches Feld falsch ist und was nicht stimmt. Kriterium 3.3.1 Error Identification (Stufe A) verlangt, dass ein automatisch erkannter Eingabefehler gekennzeichnet und als Text beschrieben wird. Ein roter Rahmen allein reicht also nicht. Kriterium 3.3.3 Error Suggestion (Stufe AA) geht weiter: Wenn du weißt, wie sich der Fehler beheben lässt, gibst du diesen Vorschlag, es sei denn, das gefährdet die Sicherheit oder den Zweck.
"Ungültige Eingabe" erfüllt 3.3.3 nicht. "Gib eine Postleitzahl wie 10115 ein" schon. Verknüpfe die Meldung mit aria-describedby mit dem Feld und markiere das Feld mit aria-invalid, damit ein Screenreader den Fehler vorliest, wenn das Feld den Fokus bekommt.
<label for="plz">Postleitzahl</label>
<input id="plz" name="plz" autocomplete="postal-code"
aria-invalid="true" aria-describedby="plz-fehler">
<p id="plz-fehler">Gib eine deutsche Postleitzahl mit fünf Ziffern ein, zum Beispiel 10115.</p>
Bei einem langen Formular hilft eine Zusammenfassung aller Fehler oben, mit Links zu den Feldern. Setz nach dem Absenden den Fokus auf diese Zusammenfassung. Verwende ARIA wie aria-invalid nur dort, wo es etwas hinzufügt; WAI-ARIA ergänzt HTML, ersetzt aber keine gute Basis.
Für den letzten Schritt einer Bestellung gilt zusätzlich Kriterium 3.3.4 Error Prevention (Stufe AA). Bei Übermittlungen mit finanziellen oder rechtlichen Folgen muss der Nutzer die Eingaben prüfen und korrigieren, rückgängig machen oder ausdrücklich bestätigen können. Eine Übersichtsseite vor "Bestellung absenden" erfüllt das meistens.
Fokusreihenfolge, Tastatur und Zielgröße
Ein Formular muss vollständig mit der Tastatur bedienbar sein, in einer logischen Reihenfolge und mit sichtbarem Fokus. Kriterium 2.1.1 Keyboard (Stufe A) verlangt, dass alle Funktionen mit der Tastatur funktionieren. Kriterium 2.4.3 Focus Order (Stufe A) verlangt eine Reihenfolge, die Bedeutung und Bedienbarkeit erhält. Kriterium 2.4.7 Focus Visible (Stufe AA) verlangt einen sichtbaren Fokusindikator.
Häufige Fehler in einem Checkout:
- Eine eigene Auswahlliste oder Datumsauswahl, die nur auf einen Mausklick reagiert.
- Ein
tabindexmit positivem Wert, wodurch der Fokus durch das Formular springt. - Ein Fokusrahmen, der per CSS entfernt wurde (
outline: none), ohne Ersatz. - Eine feste Leiste unten, die das fokussierte Feld verdeckt. WCAG 2.2 hat dafür Kriterium 2.4.11 Focus Not Obscured (Minimum, Stufe AA) hinzugefügt.
Für Touchscreens und Menschen mit zitternden Händen zählt die Größe von Buttons und Kästchen. Kriterium 2.5.8 Target Size (Minimum, Stufe AA) verlangt eine Zielfläche von mindestens 24 mal 24 CSS-Pixeln. Es gibt Ausnahmen, unter anderem wenn genug Abstand drumherum ist, wenn es ein gleichwertiges größeres Element gibt oder bei Links im Fließtext. Winzige Kontrollkästchen für die AGB und kleine Plus- und Minus-Buttons im Warenkorb sind die bekannten Problemfälle.
Redundante Eingaben und Zeitbegrenzungen
Frag im selben Prozess nie zweimal nach denselben Daten. Kriterium 3.3.7 Redundant Entry (Stufe A), neu in WCAG 2.2, verlangt, dass bereits eingegebene Informationen automatisch ausgefüllt oder auswählbar sind. Ausnahmen gelten, wenn die Wiederholung wesentlich ist, für die Sicherheit nötig ist oder die früheren Daten nicht mehr gültig sind.
Das bekannteste Beispiel in einem Onlineshop ist die Rechnungsadresse. Ein Kontrollkästchen "Rechnungsadresse entspricht Lieferadresse" erfüllt das. Ein zweites, leeres Adressformular nicht. Ein Passwort zweimal eintippen zu lassen, fällt unter die Sicherheitsausnahme.
Zeitbegrenzungen fallen unter Kriterium 2.2.1 Timing Adjustable (Stufe A). Hat dein Checkout oder Warenkorb ein Zeitlimit, muss der Nutzer es abschalten, auf mindestens das Zehnfache der Standarddauer anpassen oder vorher gewarnt werden und mindestens 20 Sekunden bekommen, um es mit einer einfachen Handlung zu verlängern. Ausnahmen sind Echtzeitereignisse wie eine Auktion, Limits, die wesentlich sind, und Limits von mehr als 20 Stunden. Eine Sitzung, die nach zehn Minuten still abläuft und den Warenkorb leert, ist also ein Problem.
Anmelden ohne Rätsel
Das Anmelden oder Bestätigen deiner Identität darf keinen kognitiven Test erfordern, etwa ein Passwort merken oder einen Code abtippen, es sei denn, es gibt eine Alternative oder eine Hilfe. Das verlangt Kriterium 3.3.8 Accessible Authentication (Minimum, Stufe AA), neu in WCAG 2.2. Ausnahmen auf Stufe AA sind das Erkennen von Objekten und das Erkennen eigener Inhalte, etwa eines Fotos, das du selbst hochgeladen hast.
Die Understanding-Seite zu 3.3.8 macht einige Punkte konkret:
- Einfügen muss funktionieren. Blockierst du das Einfügen im Passwortfeld oder hinderst du einen Passwortmanager daran, das Feld auszufüllen, scheiterst du an diesem Kriterium, es sei denn, es gibt eine andere Methode.
- Bestätigungscodes abtippen reicht nicht. Ein Dienst, der nur das manuelle Abtippen eines Codes erlaubt, erfüllt die Anforderung nicht. Der Nutzer muss den Code mindestens einfügen können.
- CAPTCHAs brauchen eine nicht-kognitive Alternative, es sei denn, es geht um Objekterkennung. Ein Audio-CAPTCHA, das du abschreiben musst, zählt nicht als Alternative.
Praktische Alternativen zu einem CAPTCHA sind eine unsichtbare Prüfung im Hintergrund, ein verstecktes Honeypot-Feld, Anmeldung per Link per E-Mail oder ein Passkey. Setz bei Passwortfeldern autocomplete="current-password" oder autocomplete="new-password", damit Passwortmanager sie erkennen. Auf Stufe AAA (Kriterium 3.3.9) entfällt auch die Ausnahme für Objekterkennung.
Der Bezahlschritt und iframes von Zahlungsanbietern
Der Bezahlschritt ist oft der schwierigste Teil, um ihn barrierefrei zu bekommen, weil ein Teil davon nicht in deinem eigenen Code steckt. Viele Onlineshops zeigen die Kartenfelder in einem iframe des Zahlungsanbieters oder leiten den Kunden auf eine Bezahlseite dieses Anbieters weiter. Was dort passiert, kannst du meist nicht selbst ändern.
Trotzdem bleibt es Teil deines Bestellprozesses, und der EAA nennt die Zahlungsfunktion eines E-Commerce-Dienstes ausdrücklich. Wie die Verantwortung genau zwischen dir und deinem Anbieter verteilt ist, unterscheidet sich je nach Situation und erfordert im Zweifel rechtliche Beratung. Was du auf jeden Fall tun kannst:
- Frag deinen Zahlungsanbieter nach seinen Barrierefreiheitsinformationen oder seiner Barrierefreiheitserklärung und nach der WCAG-Version und Stufe, gegen die die Bezahlkomponenten getestet wurden.
- Teste den Bezahlschritt selbst nur mit Tastatur und mit einem Screenreader, inklusive einer fehlerhaften Eingabe und einer 3-D-Secure-Prüfung.
- Gib einem iframe einen Titel, der sagt, was darin steckt, zum Beispiel
title="Zahlungsdaten", wenn du ihn selbst festlegst. - Biete mehrere Zahlungsarten an, damit ein Kunde, der bei einer Methode hängen bleibt, eine andere wählen kann.
- Nenne bekannte Probleme in deiner Barrierefreiheitserklärung, mit einem alternativen Weg zu bestellen.
So prüfst du das auf deiner eigenen Website
- Geh deinen gesamten Bestellprozess nur mit der Tastatur durch, von der Produktseite bis zur Bestätigung. Notiere jede Stelle, an der der Fokus verschwindet oder hängen bleibt.
- Prüfe jedes Feld auf eine sichtbare, verknüpfte Beschriftung und den richtigen Autocomplete-Wert. In den DevTools siehst du im Barrierefreiheitsbereich, welchen Namen ein Feld bekommt.
- Schick das Formular absichtlich falsch ab. Bekommst du pro Feld eine Fehlermeldung als Text mit einem Vorschlag, und liest ein Screenreader sie vor?
- Teste die Anmeldung mit einem Passwortmanager und prüfe, ob Einfügen in Passwort- und Codefeldern funktioniert.
- Miss die Zielgröße von Kontrollkästchen, Optionsfeldern und Buttons im Warenkorb auf einem Smartphone.
- Lass einen automatischen Scan laufen auf jedem Schritt des Checkouts. Er findet fehlende Beschriftungen und fehlerhaftes ARIA; der Rest dieser Liste bleibt Handarbeit. Mehr zu dieser Kombination liest du in Barrierefreiheit von Websites testen.
Die Barrierefreiheitsprüfung von Flowproof ist in den kostenpflichtigen Tarifen Pro und Business enthalten und prüft deine Seiten mit axe-core gegen WCAG 2.2 A und AA. Du kannst kostenlos starten und die Tarife auf der Preisseite vergleichen.