Barrierefreie Formulare im Shop: Labels, Fehler, Pflichtfelder
Veröffentlicht am 25. Oktober 2026
Barrierefreie Formulare im Shop haben an jedem Feld eine sichtbare Beschriftung, kennzeichnen Pflichtfelder in Text, nennen Fehler in Worten samt Korrekturhinweis und lassen sich vollständig per Tastatur und mit Screenreader ausfüllen und absenden. Für Kontaktformular, Registrierung, Login, Newsletter und Retoure kommen dieselben WCAG-Kriterien zum Tragen, aber an jedem Formular bricht etwas anderes, und genau das prüfen Sie mit den Tabellen unten.
Welche Teile Ihr Shopsystem selbst liefert und wer Theme, Plugin oder App behebt, steht in Barrierefreier Onlineshop: Shopify, WooCommerce, Shopware und Co.. Die Kaufstrecke vom Warenkorb bis zur Bestellbestätigung prüfen Sie mit Barrierefreier Checkout: Warenkorb und Kaufstrecke prüfen, Formulare als PDF-Datei mit Barrierefreie PDF-Formulare. Dieser Artikel behandelt alle anderen Webformulare Ihres Shops.
Warum Login und Kontakt besonders zählen
Ein Onlineshop für Verbraucher ist eine Dienstleistung im elektronischen Geschäftsverkehr nach § 1 Abs. 3 Nr. 5 BFSG. Wie die Marktüberwachungsbehörde eine Website prüft, regelt Anlage 1 BFSG, und dort sind Formulare ausdrücklich genannt:
- Formulare sind Prüfgegenstand. Nach Nr. 1 Buchstabe b wird mindestens „die Interaktion mit Formularen sowie Steuerelementen und Dialogfeldern der Benutzeroberfläche“ bewertet, dazu Bestätigungen, Fehlermeldungen und sonstige Rückmeldungen an die Nutzer.
- Login und Kontakt stehen in jeder Stichprobe. Nach Nr. 2 Buchstabe b Doppelbuchstabe aa gehören, soweit vorhanden, „Startseite (Home), Anmeldung (Login), Site-Übersicht (Sitemap), Kontakt“ in die Stichprobe, außerdem Hilfeseiten und Seiten mit rechtlichen Informationen.
- Ein Verfahren wird ganz geprüft. Enthält eine Seite der Stichprobe einen Schritt eines Verfahrens, werden nach Nr. 2 Buchstabe c alle Schritte geprüft. Nach unserer Lesart gilt das für eine Registrierung mit Bestätigungsmail genauso wie für eine Retoure in drei Schritten.
- Anmeldung ist eigens geregelt. Nach § 19 Nr. 2 BFSGV müssen Identifizierungs-, Authentifizierungs-, Sicherheits- und Zahlungsfunktionen, die im Rahmen einer Dienstleistung bereitgestellt werden, „wahrnehmbar, bedienbar, verständlich und robust“ gestaltet werden. Nach Nr. 3 gilt das auch für bereitgestellte Identifizierungs- und Authentifizierungsmethoden.
Die Grundregeln für jedes Feld
Diese Regeln gelten für jedes Formular im Shop, vom Suchfeld bis zum Retourenantrag. Die Prüffragen sind unsere Empfehlung auf Grundlage der verlinkten Kriterien.
| Regel | So prüfen Sie es | WCAG-Kriterium |
|---|---|---|
| Jedes Feld hat eine sichtbare Beschriftung, die beim Tippen stehen bleibt | Feld anklicken und etwas eintippen: Ist danach noch zu sehen, wofür das Feld ist? | 3.3.2 Beschriftungen oder Anweisungen (A) |
| Die Beschriftung ist im Code mit dem Feld verknüpft | Klick auf die Beschriftung setzt den Cursor ins Feld; der Screenreader liest sie beim Feld vor | 1.3.1 Info und Beziehungen (A) |
| Zusammengehörige Optionen sind gruppiert | Liest der Screenreader bei „Herr, Frau, Divers“ oder bei Newsletter-Themen die gemeinsame Frage mit vor? | 1.3.1 (A) |
| Jedes Bedienelement hat Namen, Rolle und Zustand | Sagt der Screenreader bei der Checkbox „Einwilligung, Kontrollkästchen, nicht aktiviert“? | 4.1.2 Name, Rolle, Wert (A) |
| Angaben über die Kundin oder den Kunden sind maschinenlesbar | Füllt der Browser Name, E-Mail, Adresse und Telefon aus? | 1.3.5 Eingabezweck bestimmen (AA) |
| Eine Auswahl löst nichts von selbst aus | Wählen Sie im Ausklappmenü einen Wert: Wird die Seite neu geladen oder das Formular abgeschickt? | 3.2.2 Bei Eingabe (A) |
| Alles geht per Tastatur, der Fokus ist sichtbar | Formular nur mit Tab, Leertaste und Enter ausfüllen und absenden | 2.1.1 Tastatur (A), 2.4.7 Fokus sichtbar (AA) |
| Fehler werden in Text genannt | Pflichtfeld leer lassen und absenden: Steht beim Feld in Worten, was fehlt? | 3.3.1 Fehlererkennung (A) |
| Der Fehlertext sagt, wie es richtig geht | Falsches Format eingeben: Nennt die Meldung das erwartete Format? | 3.3.3 Fehlerempfehlung (AA) |
| Erfolg wird angesagt, ohne den Fokus zu verschieben | Formular absenden: Liest der Screenreader „Vielen Dank, Ihre Nachricht ist angekommen“ vor? | 4.1.3 Statusmeldungen (AA) |
Drei Punkte aus den W3C-Dokumenten, die Sie beim Prüfen im Blick behalten sollten:
- Platzhaltertext ist keine Beschriftung. Das W3C-Tutorial zu Anweisungen in Formularen sagt, Platzhaltertext sei kein Ersatz für Beschriftungen: Er verschwindet beim Tippen, wird von Hilfsmitteln nicht zuverlässig als Beschriftung behandelt und wird von Browsern oft zu blass dargestellt. Für Platzhalter auf weißem Grund empfiehlt das Tutorial mindestens die Farbe #767676.
- Die Beschriftung muss für alle sichtbar sein. Laut Understanding 3.3.2 wird eine Beschriftung allen Nutzern angezeigt, während ein Name auch versteckt sein kann und nur von Hilfstechnik ausgegeben wird. Ein nur für Screenreader hinterlegter Name reicht also für 3.3.2 nicht. Das Kriterium gilt auch für freiwillige Felder.
- Optionsfelder gehören immer in eine Gruppe. Das W3C-Tutorial zum Gruppieren verlangt, Gruppen von Optionsfeldern immer mit
fieldsetundlegendzu gruppieren, und empfiehlt das auch für Checkboxen mit gemeinsamem Zweck und für Adressblöcke, deren Feldnamen sich wiederholen.
Pflichtfelder kennzeichnen
Ein rotes Sternchen allein reicht nicht, wenn nirgends steht, was es bedeutet, und eine rote Umrandung allein verstößt gegen 1.4.1 Benutzung von Farbe (A). Das W3C-Tutorial nennt zwei Wege: einen Hinweis vor dem Formular, welche Felder Pflicht sind, oder die Angabe direkt im Text der Beschriftung. Das W3C beschreibt dazu die Technik H90, Pflichtfelder über die Beschriftung oder die Gruppenüberschrift anzuzeigen.
So setzen Sie das um:
- Ein Hinweis vor dem ersten Feld. Zum Beispiel: „Felder mit Sternchen (*) müssen ausgefüllt werden.“ Der Hinweis steht vor dem Formular, nicht darunter.
- Das Sternchen gehört zur Beschriftung. Also „E-Mail-Adresse *“, nicht ein Sternchen als Hintergrundgrafik oder rechts außerhalb des Feldes.
- Im Code als Pflichtfeld markiert. Ihre Agentur setzt das Attribut
requiredoderaria-required="true", damit der Screenreader „erforderlich“ ansagt. - Weniger Pflichtfelder. Nach unserer Empfehlung fragen Sie im Kontaktformular nur E-Mail und Nachricht als Pflicht ab. Jedes zusätzliche Pflichtfeld ist eine weitere Stelle, an der eine Fehlermeldung nötig wird.
Sind fast alle Felder Pflicht, ist der umgekehrte Weg übersichtlicher: nur die freiwilligen Felder mit „(optional)“ beschriften. Wichtig ist, dass der Hinweis in Text steht.
Fehlermeldungen, die weiterhelfen
3.3.1 verlangt, dass ein automatisch erkannter Eingabefehler das betroffene Feld benennt und den Fehler in Text beschreibt. Farbe und Symbole dürfen zusätzlich verwendet werden. Laut Understanding-Dokument genügt es nicht, das Formular nach dem Absenden einfach erneut anzuzeigen, ohne darauf hinzuweisen, dass etwas fehlgeschlagen ist. Wo die Meldung steht, schreibt das Kriterium nicht vor: über dem Formular, am Feld oder in einem Dialog ist möglich. 3.3.3 ergänzt: Ist bekannt, wie es richtig geht, steht das in der Meldung, außer das würde die Sicherheit oder den Zweck gefährden.
Das W3C-Tutorial zu Rückmeldungen empfiehlt eine Fehlerliste über dem Formular mit einer gut erkennbaren Überschrift, die die Zahl der Fehler nennt; jeder Eintrag nennt die Feldbeschriftung, verlinkt auf das Feld und erklärt die Korrektur. Zusätzlich kann der Seitentitel die Zahl der Fehler nennen, und es ist praktisch, den Fokus auf das erste fehlerhafte Feld zu setzen.
Mustertexte für typische Shop-Felder (unsere Formulierungsvorschläge):
| Fehler | Unbrauchbar | Besser |
|---|---|---|
| Pflichtfeld leer | „Ungültige Eingabe“ | „Bitte geben Sie Ihre E-Mail-Adresse ein.“ |
| E-Mail ohne @ | rote Umrandung ohne Text | „Die E-Mail-Adresse braucht ein @, zum Beispiel name@beispiel.de.“ |
| Postleitzahl zu kurz | „Fehler im Formular“ | „Die Postleitzahl hat in Deutschland fünf Ziffern.“ |
| Bestellnummer im Retourenformular falsch | „Nicht gefunden“ | „Zu dieser Bestellnummer finden wir keine Bestellung. Sie steht in Ihrer Bestellbestätigung und beginnt mit ‚B‘.“ |
| Passwort zu schwach | „Passwort entspricht nicht den Richtlinien“ | „Das Passwort braucht mindestens 10 Zeichen. Es fehlen noch 3.“ |
| Login fehlgeschlagen | „Fehler 401“ | „E-Mail-Adresse oder Passwort stimmen nicht. Sie können Ihr Passwort zurücksetzen.“ |
| Einwilligung fehlt | Checkbox nur rot | „Bitte bestätigen Sie, dass Sie den Newsletter erhalten möchten.“ |
Die Beispiele zur Bestellnummer und zur Passwortlänge sind ausgedacht; setzen Sie Ihre echten Regeln ein. Beim Login nennt die Meldung bewusst nicht, ob die E-Mail-Adresse oder das Passwort falsch war. Nach unserer Lesart deckt die Sicherheitsausnahme in 3.3.3 das, weil sonst jeder prüfen könnte, welche E-Mail-Adressen bei Ihnen ein Konto haben. Ein Hinweis auf „Passwort vergessen“ ist trotzdem möglich und hilft.
Formular für Formular: was Sie prüfen
Kontaktformular
| Prüffrage | WCAG |
|---|---|
| Haben Name, E-Mail, Betreff und Nachricht eine sichtbare Beschriftung? | 3.3.2 (A) |
Füllt der Browser Name und E-Mail aus (autocomplete="name", "email")? | 1.3.5 (AA) |
| Ist ein Ausklappmenü „Anliegen“ per Tastatur bedienbar, ohne dass die Seite bei der Auswahl neu lädt? | 2.1.1 (A), 3.2.2 (A) |
| Hat ein Dateiupload (zum Beispiel für ein Foto vom beschädigten Artikel) eine Beschriftung, und wird der gewählte Dateiname angesagt? | 3.3.2 (A), 4.1.2 (A) |
| Wird nach dem Absenden eine Erfolgsmeldung angesagt, oder verschwindet das Formular kommentarlos? | 4.1.3 (AA) |
| Bleibt der eingegebene Text stehen, wenn das Absenden an einem Fehler scheitert? | nach unserer Empfehlung |
Das W3C nennt ein Kontaktformular, das den Zweck seiner Felder ausdrücklich angibt, als Beispiel für 1.3.5. Als Beispiel für 4.1.3 nennt es die Meldung nach dem Absenden eines Formulars, die der Screenreader vorliest, ohne dass der Fokus springt (Understanding 4.1.3).
Registrierung und Kundenkonto
| Prüffrage | WCAG |
|---|---|
| Sind die Passwortregeln vor dem Tippen sichtbar, nicht erst in der Fehlermeldung? | 3.3.2 (A) |
Hat das neue Passwort autocomplete="new-password", damit der Passwortmanager ein Passwort vorschlagen kann? | 1.3.5 (AA) |
| Lässt sich das Passwort einfügen? | nach unserer Empfehlung, siehe unten |
| Kann eine Adresse, die bei der Registrierung eingegeben wurde, im selben Ablauf übernommen werden, statt sie erneut zu tippen? | 3.3.7 Keine doppelte Eingabe (A) |
| Ist die Checkbox für Datenschutz oder Einwilligung beschriftet und per Leertaste bedienbar? | 3.3.2 (A), 4.1.2 (A) |
| Fragt das Konto vor dem Löschen noch einmal nach, oder lässt sich das Löschen rückgängig machen? | 3.3.4 Fehlervermeidung (AA) |
Zwei Abgrenzungen zum W3C-Text:
- 3.3.8 gilt nicht für das Anlegen des Kontos. Laut Understanding 3.3.8 zielt das Kriterium auf die Anmeldung bestehender Nutzer und nicht auf das Anlegen eines Benutzernamens oder Kontos. Das W3C schreibt aber, dass Einfügen und Ähnliches auch bei der Kontoerstellung die kognitive Last senkt. Nach unserer Empfehlung blockieren Sie das Einfügen deshalb nirgends.
- Passwort zweimal eingeben ist erlaubt, E-Mail zweimal ist offen. Understanding 3.3.7 erlaubt es als Ausnahme, ein selbst gewähltes, verdeckt angezeigtes Passwort zur Kontrolle erneut eingeben zu lassen. Zur doppelten E-Mail-Adresse sagt das Dokument nichts. Nach unserer Lesart ist ein zweites E-Mail-Feld, das Kunden noch einmal ausfüllen müssen, mit 3.3.7 schwer vereinbar; eine Bestätigungsmail mit Link erfüllt denselben Zweck ohne doppelte Eingabe.
Zu 3.3.4: Das Kriterium erfasst auch Seiten, die vom Nutzer steuerbare Daten ändern oder löschen. Das Understanding-Dokument nennt als Beispiel ein ganzes Reiseprofil, das nach versehentlichem Löschen verloren ist. Nach unserer Lesart gehört das Löschen eines Kundenkontos mit Bestellhistorie und Adressen dazu.
Login und „Passwort vergessen“
Hier liegt die strengste Regel, 3.3.8 Barrierefreie Authentifizierung (Minimum) (AA). Kein Schritt der Anmeldung darf einen kognitiven Funktionstest verlangen, etwa sich ein Passwort merken oder ein Rätsel lösen, außer es gibt eine Alternative ohne solchen Test, eine Hilfe dafür, oder der Test besteht im Erkennen von Objekten oder von eigenen Inhalten, die die Person hochgeladen hat. Name, E-Mail-Adresse und Telefonnummer gelten laut Begriffsbestimmung in WCAG 2.2 nicht als kognitiver Funktionstest.
| Prüffrage | Was das W3C sagt |
|---|---|
| Lässt sich das Passwort einfügen und vom Passwortmanager eintragen? | Einfügen in Anmeldefelder zu blockieren, ist ein Verstoß, wenn es keine andere Methode gibt; Seiten, die das automatische Ausfüllen ohne Alternative aktiv verhindern, fallen durch |
Haben die Felder autocomplete="username" und "current-password"? | Das W3C verknüpft zuverlässiges Ausfüllen mit korrektem Code nach 1.3.5 und 4.1.2 |
| Lässt sich ein Code aus SMS oder E-Mail einfügen, auch in geteilte Kästchen? | Abtippen eines Codes allein ist nicht konform; mindestens Einfügen muss gehen |
| Gibt es ein Captcha mit verzerrten Buchstaben oder einer Rechenaufgabe? | Nur das Erkennen von Objekten ist auf Stufe AA ausgenommen, nicht Rechnen mit gezählten Objekten |
| Ist ein Audio-Captcha die einzige Alternative? | Muss man das Gehörte abtippen, zählt es nicht als Alternative |
| Funktioniert „Passwort vergessen“ ohne Sicherheitsfrage? | Auch die Wiederherstellung eines Kontos braucht einen Weg ohne kognitiven Funktionstest |
Alle Angaben in der rechten Spalte stammen aus Understanding 3.3.8. Als ausreichende Technik nennt das W3C dort auch die Anmeldung per Link in einer E-Mail (G218). Ein Login per E-Mail-Link oder ein Passkey ist nach unserer Lesart deshalb der bequemste Weg, 3.3.8 zu erfüllen.
Läuft die Sitzung im Kundenkonto ab, während jemand eine lange Nachricht oder Retoure ausfüllt, greift 2.2.1 Zeiteinteilung anpassbar (A): Das Zeitlimit lässt sich abschalten, auf mindestens das Zehnfache verlängern, oder die Person wird vor Ablauf gewarnt und hat mindestens 20 Sekunden, um mit einer einfachen Aktion zu verlängern. Ausgenommen sind Zeitlimits über 20 Stunden.
Newsletter-Anmeldung
| Prüffrage | WCAG |
|---|---|
| Hat das E-Mail-Feld im Footer eine sichtbare Beschriftung, nicht nur „Ihre E-Mail“ als Platzhalter? | 3.3.2 (A) |
| Hat der Absenden-Knopf einen Namen, auch wenn er nur ein Pfeil-Symbol zeigt? | 4.1.2 (A), 1.1.1 Nicht-Text-Inhalt (A) |
| Ist die Einwilligungs-Checkbox eine echte Checkbox, die der Screenreader mit Zustand ansagt? | 4.1.2 (A) |
| Sind mehrere Themen („Angebote“, „Neuheiten“) als Gruppe mit gemeinsamer Frage ausgezeichnet? | 1.3.1 (A) |
| Wird „Bitte bestätigen Sie Ihre Anmeldung in der E-Mail“ angesagt? | 4.1.3 (AA), nach unserer Lesart |
| Lässt sich ein Newsletter-Pop-up per Tastatur schließen, und landet der Fokus danach wieder sinnvoll? | 2.1.1 (A), 2.4.3 Fokus-Reihenfolge (A) |
Fehlende Zustände entstehen leicht bei selbst gebauten Checkboxen aus div-Elementen. Das W3C führt das Fehlerbild als F59: ein div oder span per Skript zum Bedienelement machen, ohne ihm eine Rolle zu geben.
Retouren- und Widerrufsformular
Bei Fernabsatzverträgen, die über eine Online-Benutzeroberfläche geschlossen werden, verlangt § 356a BGB eine Widerrufsfunktion, die mit „Vertrag widerrufen“ oder einer gleichbedeutenden eindeutigen Formulierung beschriftet ist. Darüber gibt die Kundin oder der Kunde Namen, Angaben zur Identifizierung des Vertrags und den Kommunikationsweg für die Eingangsbestätigung an und schickt alles über eine Bestätigungsfunktion „Widerruf bestätigen“ ab. Nach unserer Lesart ist das ein Formular wie jedes andere und muss dieselben Prüffragen bestehen. Warum ein PDF diese Funktion nicht ersetzt, steht in Barrierefreie PDF-Formulare.
| Prüffrage | WCAG |
|---|---|
| Sind Bestellnummer, E-Mail und Name aus dem Kundenkonto oder aus dem Link in der Bestellmail schon eingetragen? | nach unserer Empfehlung (3.3.7 gilt nur innerhalb desselben Ablaufs, etwa zwischen den Schritten der Retoure) |
| Ist die Liste der Artikel mit Checkboxen und Mengenfeldern beschriftet, sodass der Screenreader sagt, welcher Artikel gemeint ist? | 3.3.2 (A), 1.3.1 (A) |
| Ist der Rücksendegrund wählbar, ohne dass die Seite bei der Auswahl springt? | 3.2.2 (A) |
| Gibt es vor dem endgültigen Absenden eine Übersicht zum Prüfen und Korrigieren? | 3.3.4 (AA), nach unserer Lesart |
| Kommt nach dem Absenden eine angesagte Bestätigung? | 4.1.3 (AA) |
Zu 3.3.4: Das Kriterium gilt für Seiten, die für den Nutzer eine rechtliche Verpflichtung oder eine finanzielle Transaktion auslösen, und verlangt, dass die Übermittlung umkehrbar ist, Eingaben geprüft und korrigierbar sind oder eine Prüf- und Korrekturmöglichkeit vor dem Absenden besteht (Understanding 3.3.4). Ob ein Widerruf darunter fällt, sagt das W3C nicht. Nach unserer Lesart ist die Übersicht vor dem Absenden der sichere Weg, zumal § 356a BGB ohnehin einen eigenen Bestätigungsschritt vorsieht.
Suche, Bewertungen und Gutscheinfeld
- Suchfeld: Eine Lupe darf als sichtbare Beschriftung dienen, laut Understanding 3.3.2. Der Suchknopf braucht trotzdem einen Namen (4.1.2). Erscheint die Trefferzahl wie „5 Ergebnisse“ ohne Neuladen der Seite, ist sie laut W3C eine Statusmeldung nach 4.1.3.
- Bewertungsformular: Für Sterne zum Anklicken gibt es kein eigenes HTML-Element; Theme oder App bauen sie selbst. Prüfen Sie, ob sich die Sternzahl per Tastatur wählen lässt und ob der Screenreader „4 von 5 Sternen, ausgewählt“ oder Ähnliches sagt (2.1.1, 4.1.2).
- Gutscheinfeld: Wird ein ungültiger Code nur durch Rütteln des Feldes angezeigt, fehlt der Text nach 3.3.1. Eine Meldung wie „Dieser Gutschein ist abgelaufen“ hilft mehr als „Ungültig“.
Captcha und Spamschutz: was Sie einsetzen
Spamschutz kann ein sonst gutes Kontaktformular unbenutzbar machen. Für Captchas verlangt 1.1.1 eine Textalternative, die den Zweck nennt, und alternative Formen für unterschiedliche Sinne. Beim Login kommt 3.3.8 dazu.
| Schutz | Kontakt, Newsletter, Registrierung | Login und Passwort vergessen |
|---|---|---|
| Verzerrte Buchstaben abtippen | Nur mit Alternative für eine andere Sinnesform (1.1.1) | Fällt durch, wenn es keinen anderen Weg gibt (3.3.8) |
| Rechenaufgabe | Nach unserer Einschätzung für Menschen mit Dyskalkulie eine Hürde; vermeiden | Fällt durch, wenn es keinen anderen Weg gibt (Rechnen ist ein kognitiver Funktionstest, 3.3.8) |
| Bilder mit Objekten anklicken | Braucht eine Alternative für blinde Nutzer (1.1.1) | Auf Stufe AA ausgenommen (Objekterkennung) |
| Verstecktes Feld für Bots (Honeypot), Zeitprüfung im Hintergrund | Nach unserer Einschätzung unproblematisch, wenn das versteckte Feld auch für Screenreader und Tastatur versteckt ist | Kein Test für den Menschen, also kein Konflikt mit 3.3.8 |
| Unsichtbare Prüfung beim Dienstleister mit Rückfall auf ein Rätsel | Prüfen Sie das Rätsel im Rückfall wie oben | Prüfen Sie das Rätsel im Rückfall wie oben |
Den Rückfall testen Sie, indem Sie das Formular mit einem Browser ohne gespeicherte Cookies oder über eine VPN-Verbindung absenden; erscheint dann ein Rätsel, gehört es in die Prüfung.
Zehn-Minuten-Test für ein Formular
- Nur Tastatur. Maus weglegen, mit Tab durch das Formular, alle Felder ausfüllen, Checkboxen mit der Leertaste setzen, mit Enter absenden. Den Ablauf im Detail zeigt Tastaturtest: Website auf Tastaturbedienbarkeit prüfen.
- Beschriftung antippen. Klicken Sie auf jede Beschriftung. Springt der Cursor nicht ins Feld, ist das ein Hinweis auf eine fehlende Verknüpfung (1.3.1).
- Tippen und schauen. Steht nach dem Tippen noch da, wofür das Feld ist?
- Leer absenden. Kommt eine Meldung in Text, die jedes fehlende Feld nennt?
- Falsch absenden. E-Mail ohne @, vierstellige Postleitzahl: Sagt die Meldung, wie es richtig geht? Ist Ihr Text noch da?
- Ausfüllhilfe. Löschen Sie das Formular und lassen Sie den Browser ausfüllen. Kommen Name, E-Mail und Adresse in die richtigen Felder (1.3.5)?
- Einfügen. Kopieren Sie beim Login ein Passwort aus einer Notiz und fügen Sie es ein. Geht das nicht, ist 3.3.8 verletzt.
- Vorlesen. Schalten Sie den eingebauten Screenreader ein, unter Windows die Sprachausgabe, auf dem Mac VoiceOver, und hören Sie, ob jede Checkbox ihren Zustand und die Erfolgsmeldung vorgelesen wird.
Notieren Sie je Formular, was nicht klappt, und wer es beheben muss: Theme, Formular-Plugin, Newsletter-Anbieter oder Captcha-Dienst. Formulare von Drittanbietern wie eingebettete Newsletter-Anmeldungen sind Teil Ihres Shops. Nach § 14 Abs. 1 BFSG darf der Dienstleistungserbringer, also Sie, seine Dienstleistung nur anbieten oder erbringen, wenn sie die Barrierefreiheitsanforderungen der Verordnung erfüllt; nach unserer Lesart gilt das auch für eingebundene Bausteine.
Ihr nächster Schritt
Der kostenlose Scan prüft ohne Anmeldung Ihre Startseite, eine Produktseite und den Warenkorb automatisch gegen die WCAG-Regeln und zeigt, was zuerst behoben werden sollte. Fehlende Beschriftungen an Suchfeld und Newsletter-Feld im Seitenkopf oder Footer kann der Scan dabei schon finden. Ein automatischer Scan findet nur einen Teil aller Barrieren: Fehlermeldungen, Erfolgsmeldungen und das Verhalten beim Login zeigen sich erst, wenn Sie das Formular selbst ausfüllen und absenden.
Dieser Ratgeber ist keine Rechtsberatung. Im Zweifel klären Sie Ihren Fall mit der Bundesfachstelle Barrierefreiheit oder einer Anwältin oder einem Anwalt.
Stand: 25.10.2026. Quellen gelesen am 25.10.2026.