Formulare barrierefrei erstellen: Leitfaden für Onlineshops

Dieser Leitfaden zeigt, welche Anforderungen für barrierefreie Formulare gelten, wie Sie Label, Pflichtfelder und Fehlermeldungen technisch sauber erstellen, warum der Checkout die größte Hürde ist und wie Sie das Ergebnis testen, bevor Kunden scheitern.

Was barrierefreie Formulare ausmacht

Ein Formular ist barrierefrei, wenn alle Menschen es ohne fremde Hilfe ausfüllen und absenden können: per Maus, per Tastatur, mit Screenreader, mit Vergrößerung oder mit Spracheingabe. Maßstab sind die Web Content Accessibility Guidelines, kurz WCAG. Die aktuelle Fassung WCAG 2.2 ist eine W3C-Empfehlung, deren gültige Version auf den 12. Dezember 2024 datiert ist.

Für die Praxis lassen sich die Anforderungen auf vier Fragen verdichten:

• ✓ Wahrnehmbar: Hat jedes Eingabefeld ein sichtbares Label, das technisch damit verknüpft ist, und sind Schrift und Feldränder kontrastreich genug?
• ✓ Bedienbar: Lassen sich alle Formularfelder ohne Maus erreichen, bleibt der Fokus sichtbar, und sind Schaltflächen groß genug?
• ✓ Verständlich: Sind Pflichtfelder und Formate vorab erklärt, und sagen Fehlermeldungen, was falsch ist und wie die Eingabe richtig aussieht?
• ✓ Robust: Erkennen Browser und assistive Technologien Name, Rolle und Zustand jedes Elements, auch bei selbst gebauten Auswahlfeldern?

Laut Statistischem Bundesamt lebten Ende 2025 gut 7,8 Millionen Menschen mit schwerer Behinderung in Deutschland, 9,4 Prozent der Bevölkerung (Pressemitteilung vom 13. Juli 2026). Barrierefreie Eingabefelder helfen aber nicht nur ihnen. Eine klare Beschriftung, verständliche Hinweise und automatisch ausgefüllte Adressen beschleunigen den Kauf für alle Nutzer, auch am Smartphone und für Menschen mit vorübergehenden Einschränkungen, etwa mit einem gebrochenen Arm. Wie sich das auf Abschlüsse auswirken kann, beschreibt unser Beitrag Mehr Conversion durch Inklusion.

Welche Anforderungen für Formulare im Shop gelten

Für die barrierefreie Gestaltung im Shop gilt das BFSG, für Behörden die BITV 2.0, und beide führen technisch zu denselben Kriterien. Das BFSG regelt Dienstleistungen im elektronischen Geschäftsverkehr. Die zugehörige Verordnung BFSGV stellt in § 19 klar, dass Funktionen zur Identifizierung, Authentifizierung, Sicherheit und Zahlung wahrnehmbar, bedienbar, verständlich und robust sein müssen, wenn sie Teil der Dienstleistung sind. Das trifft Login, Kundenkonto und Zahlungsschritt direkt.

Wie die Anforderungen technisch zu erfüllen sind, beschreibt die europäische Norm EN 301 549, die für Inhalte im Web die Erfolgskriterien der WCAG übernimmt. Nach § 4 BFSG wird Konformität vermutet, wenn ein Angebot harmonisierte Normen erfüllt, deren Fundstellen im Amtsblatt der EU veröffentlicht sind. Die neue Fassung V4.1.1 ist laut irischer National Disability Authority seit dem 2. September 2026 veröffentlicht und stellt auf WCAG 2.2 Level AA um. Die Zitierung im Amtsblatt erwartet die Behörde für den 16. Dezember 2026. Bis dahin bleibt die Fassung V3.2.1 auf Basis von WCAG 2.1 die zitierte Referenz. Was das für Shops bedeutet, steht in unserem Beitrag EN 301 549 V4.1.1: Was sich für Online-Shops ändert.

Die BITV 2.0 gilt seit dem 25. Mai 2019 in ihrer Neufassung für öffentliche Stellen des Bundes. Sie nennt Formulare und Authentifizierung ausdrücklich als Bereiche, die das höchstmögliche Maß an Barrierefreiheit anstreben sollen. Für Shopbetreiber ist die BITV nicht verbindlich, zeigt aber, welche Stellen der Gesetzgeber für besonders kritisch hält.

Einordnung für die Praxis: Wer heute neue Formulare erstellen lässt, sollte direkt WCAG 2.2 AA zugrunde legen. Mehrere der sechs neuen Kriterien betreffen gerade Eingabefelder und Checkout, und mit der Amtsblatt-Zitierung der neuen Norm werden sie zum Maßstab für die Konformitätsvermutung. Rechtlich abschließend geklärt ist der Zeitpunkt noch nicht, technisch ist die Richtung eindeutig: Barrierefreie Bedienelemente nach WCAG 2.2 AA sind der fachliche Maßstab.

Die wichtigsten WCAG-Kriterien für Formulare

Ein gutes Dutzend Erfolgskriterien entscheidet, ob ein Formular zugänglich ist. Die folgende Übersicht fasst sie nach dem Wortlaut der Version 2.2 (W3C-Empfehlung, Stand 12. Dezember 2024) zusammen, die Prüfung bleibt aber Aufgabe im einzelnen Formular.

Vier dieser Kriterien sind mit Version 2.2 neu hinzugekommen: 2.4.11, 2.5.8 und die beiden Checkout-Kriterien 3.3.7 und 3.3.8. Einen Überblick über alle Änderungen bietet unsere Wissensseite zu WCAG 2.2.

Barrierefreie Formulare erstellen: Label, Hinweise, Struktur

Die meisten Probleme entstehen schon, wenn Teams ein neues Formular planen und dabei auf Optik statt auf Semantik achten. Barrierefreie Formularfelder beginnen deshalb im Code, nicht im Design. Das Formular-Tutorial der W3C-Initiative WAI, zuletzt aktualisiert am 27. März 2026, nennt dafür eine klare Reihenfolge: jedes Steuerelement mit einer Beschriftung versehen, zusammengehörige Formularfelder gruppieren, Hinweise geben, Eingaben prüfen und Nutzer über Erfolg oder Fehler informieren.

Label und Beschriftung

Jedes Eingabefeld braucht eine Beschriftung, also ein <label>-Element, das über for und id mit ihm verknüpft ist. Das W3C bezeichnet diese explizite Verknüpfung als bevorzugten Weg, weil assistive Technologien sie am zuverlässigsten auslesen. Ein Beispiel für ein Feld zur Postleitzahl:

<label for="plz">Postleitzahl</label>
<input id="plz" name="plz" autocomplete="postal-code">

Bei Checkboxen steht das Label rechts neben dem Kästchen:

<input type="checkbox" id="news">
<label for="news">Newsletter abonnieren</label>

Nach diesem Muster lassen sich auch komplexe Masken erstellen. Ein Screenreader liest dann beim Fokussieren „Postleitzahl, Eingabefeld“ statt nur „Eingabefeld“. Eine barrierefreie Beschriftung ist kurz, eindeutig und steht sichtbar über oder links neben dem Feld, bei Checkboxen rechts davon. Das Attribut name ist für das Absenden der Daten wichtig, ersetzt aber kein Label: Assistive Technologien lesen es nicht als Beschriftung vor. Für Menschen, die nicht sehen können, ist das Label oft die einzige Information über den Zweck eines Eingabefelds, und erst damit ist es für assistive Technologien zugänglich.

Platzhaltertext ersetzt kein Label. Er verschwindet beim Tippen, hat meist zu wenig Kontrast, ist für Menschen mit Sehschwäche schwer lesbar und wird von Screenreadern nicht verlässlich als Beschriftung erkannt. Wichtige Inhalte gehören deshalb nie nur in den Platzhalter. Ein unsichtbares Label per aria-label ist nur dort sinnvoll, wo der Zweck aus dem Umfeld klar ist, etwa beim Suchfeld mit Lupen-Schaltfläche. Auch die Schaltfläche selbst braucht einen Namen: „Jetzt kaufen“ als Text im Button, nicht ein Icon ohne Beschriftung.

Pflichtangaben und Hinweise

Barrierefreie Pflichtfelder sind erkennbar, bevor eine Person mit dem Ausfüllen beginnt. Unklar ist sonst, welche Angaben fehlen. Das W3C empfiehlt, die Kennzeichnung vor dem Formular zu erklären und die Information direkt ins Label zu schreiben, zum Beispiel „E-Mail-Adresse (Pflichtfeld)“. Ein Sternchen allein reicht nur, wenn seine Bedeutung vorher erklärt wird. Das HTML-Attribut required ergänzt die Kennzeichnung technisch. Formathinweise für Angaben wie das Datum („TT.MM.JJJJ“) gehören ebenfalls ins Label oder werden per aria-describedby mit dem Feld verbunden, damit assistive Technologien sie mit vorlesen.

Struktur und automatisches Ausfüllen

Zusammengehörige Eingabefelder wie Rechnungsadresse, Lieferadresse oder Zahlungsart werden mit <fieldset> und <legend> gruppiert. Diese barrierefreie Struktur zeigt einer Person mit Screenreader, ob „Straße“ gerade zur Liefer- oder zur Rechnungsadresse gehört. Für Kriterium 1.3.5 nennt das W3C das Attribut autocomplete als ausreichende Technik, mit Werten wie given-name oder email und den Zusätzen billing und shipping für zwei Adresssätze. Der Browser kann dann gespeicherte Daten vorschlagen. Das hilft Menschen mit motorischen oder kognitiven Einschränkungen und verkürzt den Checkout für alle Nutzer. Wer eine Adressmaske neu erstellen lässt, sollte die autocomplete-Werte gleich mit festlegen.

Fehler verständlich melden

Barrierefreie Fehlermeldungen müssen in Textform sagen, welches Feld betroffen ist, was falsch ist und wie die richtige Eingabe aussieht. Farbe darf das unterstützen, aber nie allein tragen: So formuliert es das W3C im Begleitdokument zu Kriterium 3.3.1. Ein rot umrandetes Feld ohne Text erfüllt die Anforderung nicht, und Menschen mit Farbsehschwäche erkennen die Markierung oft gar nicht. Der Händlerbund nennt in seinem Ratgeber vom 10. September 2024 ein gutes Beispiel: „Bitte geben Sie eine gültige Postleitzahl bestehend aus fünf Ziffern an.“

Für die Prüfung der Eingaben empfiehlt das WAI-Tutorial zur Nutzerbenachrichtigung mehrere Bausteine, die sich kombinieren lassen:

• ✓ Fehlerübersicht oben: Eine Liste über dem Formular mit eigener Überschrift nennt alle Fehler und verlinkt direkt zum jeweiligen Feld, sodass Nutzer sofort korrigieren können.
• ✓ Fehler am Feld: Die Meldung steht direkt daneben und ist per aria-describedby verknüpft, damit assistive Programme sie beim Fokussieren vorlesen.
• ✓ Fokus setzen: Nach einem fehlgeschlagenen Absenden springt der Fokus auf das erste fehlerhafte Feld oder auf die Fehlerübersicht.
• ✓ Seitentitel anpassen: Ein Titel wie „3 Fehler: Rechnungsadresse“ informiert blinde Nutzer sofort beim Neuladen.
• ✓ Dynamische Hinweise ansagen: Prüft das Formular ohne Neuladen, macht role="alert" oder eine Live-Region die Meldung hörbar.

Auch der Zeitpunkt der Prüfung zählt. Das W3C rät, strenge Formate wie Datumsangaben erst beim Verlassen des Feldes zu prüfen, weil Meldungen während des Tippens sonst ständig stören. Bereits gemachte Angaben dürfen nach einem Fehler nicht verloren gehen. Für Bestellungen kommt Kriterium 3.3.4 (Stufe AA) hinzu: Bei rechtlich oder finanziell verbindlichen Vorgängen müssen sich die Angaben rückgängig machen lassen, auf Fehler geprüft werden oder vor dem Absenden überprüfbar und korrigierbar sein. Das W3C verweist dazu auf die Bestellübersicht mit Artikeln, Lieferadresse und Zahlart vor dem Kaufbutton. Sie erfüllt die Anforderung nur, wenn sie selbst zugänglich ist. Fehlertexte sollten Sie gemeinsam mit dem Formular erstellen, nicht nachträglich.

Der Checkout als Härtetest

Im Checkout treffen alle Anforderungen aufeinander, und hier kostet jedes der Probleme direkt Umsatz. Der Händlerbund weist darauf hin, dass auch Zahlungsfunktionen von Drittanbietern wie PayPal für eine barrierefreie Kundenreise zählen. Welche Probleme typisch sind, zeigt ein Szenario:

Eine Person nutzt einen Screenreader und bedient den Shop ohne Maus. Im Warenkorb ist das Mengenfeld ein selbst gebautes Plus-Minus-Element ohne Name, die Sprachausgabe sagt nur „Schaltfläche“. Im Adressschritt muss sie die Lieferadresse noch einmal eintippen, obwohl sie identisch mit der Rechnungsadresse ist. Beim Login verhindert das Passwortfeld das Einfügen aus dem Passwort-Manager. Und beim Tabben verschwindet der Fokus hinter einem festen Cookie-Banner.

Jeder dieser Punkte hat ein eigenes Kriterium. Kriterium 3.3.7 verlangt, dass Angaben aus demselben Vorgang automatisch übernommen oder zur Auswahl angeboten werden. Das W3C nennt dafür ausdrücklich das Beispiel, Rechnungs- und Lieferadresse per Auswahl gleichzusetzen. Kriterium 3.3.8 untersagt kognitive Tests beim Login, wenn es keine Alternative oder Hilfe gibt. Für Menschen mit kognitiven Einschränkungen ist ein Passwort aus dem Gedächtnis eine echte Hürde. Laut W3C verstößt es dagegen, wenn ein Shop das Einfügen in Anmeldefelder blockiert, Passwort-Manager aussperrt oder verlangt, einen Bestätigungscode abzutippen, statt ihn einfügen zu lassen. CAPTCHAs mit Rechenaufgaben oder Logikrätseln sind nicht ausgenommen, Bilderkennung ist auf Stufe AA ausgenommen.

Sind einzelne Eingabefelder zugänglich, der Zahlungsschritt aber nicht, scheitert der Kauf trotzdem. Shopsysteme liefern oft barrierefreie Grundlagen, aber nie die ganze Lösung. Plugins, eigene Templates und eingebundene Inhalte von Zahlungsdiensten verändern das Ergebnis. Wie sich das bei einer konkreten Plattform darstellt, zeigt unser Beitrag Shopify barrierefrei: Theme, Apps und Checkout prüfen.

Barrierefreie Formulare testen

Ob ein Formular zugänglich ist, zeigt erst der Test. Am besten prüfen Sie in drei Stufen: automatisiert, per Tastatur und mit Screenreader. Automatische Prüfungen finden ein fehlendes Label, zu geringen Kontrast und fehlende Attribute schnell, aber sie erkennen nicht alle Probleme, etwa ob eine Meldung verständlich ist oder ob Reihenfolge und Struktur der Formularfelder Sinn ergeben. Wie Sie dabei methodisch vorgehen, beschreibt unsere Wissensseite Richtig auf Barrieren prüfen.

• ✓ Tastaturtest: Gehen Sie das Formular nur mit Tab, Umschalt+Tab, Leertaste und Enter durch. Die Tastaturbedienbarkeit muss jedes Feld erreichen, der Fokus-Indikator muss sichtbar sein, und kein Element darf den Fokus festhalten. So bewegen sich viele Menschen mit motorischen Einschränkungen durch Ihr Formular.
• ✓ Test mit Vorlesesoftware: Lassen Sie wenn möglich eine Person testen, die täglich mit Vorlesesoftware arbeitet. Mit NVDA unter Windows oder VoiceOver auf dem Mac prüfen Sie selbst, ob jedes Feld sein Label, seinen Typ und den Pflichtfeld-Hinweis ansagt und ob Fehlermeldungen vorgelesen werden.
• ✓ Kontrast messen: Text braucht nach Kriterium 1.4.3 mindestens 4,5:1, Feldränder und Fokusrahmen nach 1.4.11 mindestens 3:1. Das Kontrastverhältnis prüfen Sie mit dem SiteCockpit Kontrastchecker.
• ✓ Fehler provozieren: Senden Sie das Formular absichtlich leer und mit falschen Formaten ab. Prüfen Sie, ob Meldungen als Text erscheinen, ob der Fokus folgt und ob Nutzer ihre bereits eingegebenen Daten behalten. Eingebettete Formulare von Drittanbietern, etwa für Zahlung oder Terminbuchung, gehören ebenfalls in den Test. Erst wenn alle vier Tests bestanden sind, ist das Formular wirklich zugänglich.

Testen Sie am besten schon, während Sie Formulare erstellen, und nicht erst nach dem Livegang. Bei der Reihenfolge lohnt eine klare Priorität: zuerst Checkout und Kundenkonto, dann Kontakt- und Retourenformulare, zuletzt Newsletter und Gewinnspiele. Warum diese Gewichtung sinnvoll ist, erläutert unser Beitrag Die teuersten Barrieren und ihre Prioritäten.

SiteCockpit: Formulare dauerhaft im Blick

Barrierefreie Formularfelder sind kein einmaliges Projekt. Jedes neue Plugin, jedes Template-Update und jeder neue Zahlungsanbieter kann ein Label entfernen oder den Fokus verschieben. Prüfen Sie auch Masken, die Plugins automatisch erstellen. Deshalb brauchen barrierefreie Abläufe einen laufenden Prozess statt einer Momentaufnahme.

• ✓ easyMonitoring: überwacht Ihre Seiten laufend und deckt typische Fehler in Formularen auf, zum Beispiel ein fehlendes Label, zu schwache Kontraste oder einen unsichtbaren Tastaturfokus, mit priorisierten Aufgaben.
• ✓ Manuelle Audits: prüfen, was kein Tool sieht, etwa ob ein Checkout mit assistiver Software von Anfang bis Ende funktioniert und ob Meldungen verständlich sind.
• ✓ easyVision: lässt Besucher, etwa Menschen mit Sehschwäche, Kontrast, Schrift und Abstände selbst anpassen. Das Widget ergänzt die Behebung von Barrieren im Code, ersetzt sie aber nicht.

Im Dashboard sehen Sie die Konformitäts-Scores Ihrer Seiten im Zeitverlauf. So erkennen Sie, ob ein Update ein Formular verschlechtert hat, bevor es Kunden merken.

Was jetzt sinnvoll ist

Barrierefreie Formulare zu erstellen ist überwiegend saubere Handarbeit im HTML und kein Großprojekt. Die meisten Barrieren lassen sich mit Label, klarer Struktur, Textmeldungen und autocomplete beheben. Aufwendiger wird es bei selbst gebauten Komponenten und Zahlungsdiensten von Drittanbietern. Kein Anlass zur Hektik, aber realer Handlungsbedarf, vor allem im Checkout.

• ✓ Stand feststellen: Listen Sie alle Formulare auf und prüfen Sie Checkout, Login und Kontaktformular zuerst ohne Maus und mit Screenreader.
• ✓ Häufigste Fehler beheben: Ein fehlendes Label, unklare Pflichtfelder, rein farbige Fehlermeldungen und blockiertes Einfügen im Login haben die größte Wirkung.
• ✓ Dauerhaft im Blick behalten: Prüfen Sie nach jedem Update erneut und erstellen Sie neue Formulare von Anfang an nach WCAG 2.2 AA.

Gehen Sie schrittweise vor und beginnen Sie dort, wo Nutzer kaufen. Mit easyMonitoring behalten Sie Ihre Formulare danach dauerhaft im Blick und sehen neue Fehler, sobald sie entstehen.