Barrierefreie Formulare: 7 Wege zu mehr Conversions und besserer User Experience

Barrierefreie Formulare reduzieren Abbrüche für alle Nutzer, nicht nur für Menschen mit Einschränkungen. Wer Labels dauerhaft sichtbar hält, Fehlermeldungen klar formuliert und Tastaturnavigation vollständig umsetzt, senkt die kognitive Last beim Ausfüllen spürbar. Das Ergebnis: mehr Einsendungen, weniger Supportnachfragen – und eine Umsetzung, die gleichzeitig die rechtlichen Anforderungen des BFSG erfüllt.

Das Wichtigste in Kürze

• Placeholder-Text als einzige Feldbeschriftung ist weder WCAG-konform noch konversionsfreundlich – sichtbare Labels bleiben auch während der Eingabe bestehen.
• Fehlermeldungen helfen nur, wenn sie das Problem benennen und den Lösungsweg zeigen, nicht nur das betroffene Feld farblich markieren.
• WCAG 2.1 AA verlangt mindestens 4,5:1 Kontrastverhältnis für normalen Text – eine Anforderung, die gleichzeitig die Lesbarkeit auf mobilen Geräten bei schlechtem Licht verbessert.
• Das Barrierefreiheitsstärkungsgesetz (BFSG) gilt seit Juni 2025 für viele private Unternehmen; Formulare gehören zu den ersten Prüfpunkten der Marktüberwachungsbehörden.
• Tastaturnavigation und korrekte HTML-Eingabetypen senken die Abbruchrate für Power-User und Smartphone-Nutzer gleichermaßen.

Warum Barrierefreiheit und Conversion-Optimierung dasselbe Ziel verfolgen

Beide Disziplinen wollen dasselbe: einen Nutzer mit möglichst wenig Reibung durch ein Formular führen. Was Menschen mit einer Sehbehinderung hilft, ein Label zu lesen, hilft dem Vertriebsmitarbeiter, der das Formular im Zug auf dem Smartphone ausfüllt. Was Screenreader-Nutzern eine verständliche Fehlermeldung liefert, spart dem Marketingteam Supportanfragen. Barrierefreiheit ist deshalb keine Parallelaufgabe neben der Conversion-Optimierung – sie ist ein Teil davon.

Das zeigt sich besonders bei drei häufigen Formular-Schwächen: schwindende Placeholder, vage Fehlermeldungen und mangelnder Kontrast. Alle drei verursachen Abbrüche quer durch alle Nutzergruppen, nicht nur bei Menschen mit diagnostizierten Einschränkungen. Wer diese Punkte behebt, verbessert gleichzeitig die Barrierefreiheit und die Conversion-Rate – ohne Kompromisse eingehen zu müssen.

In der Praxis zeigt sich: Formulare, die mit Screenreadern und per Tastatur vollständig bedienbar sind, schneiden auch in mobilen Usability-Tests besser ab. Der Grund liegt in der Überschneidung der Anforderungen. Touch-Targets, die für Tastaturbedienung groß genug sind, sind auch für Daumen auf kleinen Displays gut erreichbar. Labels, die für Screenreader programmatisch verknüpft sind, helfen dem Browser beim Autofill. Beide Verbesserungen kommen aus derselben Quelle.

Was das BFSG seit Juni 2025 von Unternehmen verlangt

Das Barrierefreiheitsstärkungsgesetz (BFSG) ist am 28. Juni 2025 in Kraft getreten und erstreckt sich auf weite Teile des privaten Wirtschaftssektors – darunter Online-Shops, Software-as-a-Service-Angebote und digitale Dienstleistungen. Für Formulare bedeutet das konkret: Jedes Eingabefeld braucht ein programmatisch verknüpftes Label, Fehlermeldungen müssen für Assistenztechnologien erkennbar sein, Tastaturnavigation muss vollständig funktionieren, und der Fokusstatus muss sichtbar bleiben. Der Bezugsstandard ist die harmonisierte europäische Norm EN 301 549, die auf WCAG 2.1 Level AA aufbaut.

Wer jetzt umsetzt, erfüllt nicht nur eine Pflicht – er schafft Formulare, die auch bei schärferen Kontrollen standhalten.

Wer genau betroffen ist

Das BFSG gilt für Unternehmen, die Produkte oder Dienstleistungen in der EU anbieten. Kleinstunternehmen mit weniger als zehn Beschäftigten und unter zwei Millionen Euro Jahresumsatz sind in weiten Teilen ausgenommen. Für alle anderen gilt: Formulare, über die Anfragen gestellt, Verträge geschlossen oder Newsletter abonniert werden, fallen in den Anwendungsbereich. Kontaktformulare, Webinar-Anmeldeseiten und Checkout-Formulare sind damit explizit betroffen.

Was über WCAG 2.1 hinausgeht

WCAG 2.2, inzwischen als W3C-Standard verabschiedet, ergänzt WCAG 2.1 um neun neue Erfolgskriterien. Für Formulare relevant sind vor allem die Mindestanforderungen an die Sichtbarkeit des Fokus-Rings (Kriterium 2.4.11) und die Anforderung, dass alle Drag-Gesten auch per Einfachklick ausführbar sein müssen (Kriterium 2.5.7). Das BFSG verweist noch auf WCAG 2.1; WCAG 2.2 setzt dennoch den faktischen Qualitätsstandard für neue Formulare, die nach 2025 gebaut werden. Wer heute neu entwickelt, sollte direkt auf WCAG 2.2 abzielen.

Die fünf Stellschrauben mit dem größten Effekt

Labels, die beim Tippen sichtbar bleiben

Placeholder-Text, der als einzige Feldbeschriftung dient, verstößt gegen WCAG 1.3.1 – und kostet Conversions. Sobald jemand mit der Eingabe beginnt, verschwindet der Hinweis. Wer den Kontext vergisst oder kurz unterbrochen wird, muss das Feld erst leeren, um zu sehen, was es verlangt. Das passiert öfter als gedacht, besonders bei längeren Formularen mit vielen Feldern oder bei Nutzern, die zwischen mehreren Tabs wechseln.

Die korrekte Umsetzung: ein sichtbares Label über oder neben dem Feld, programmatisch mit dem Input verknüpft über das for-Attribut im HTML. Hilfstexte für komplexe Felder – etwa ein Hinweis zum Format einer Telefonnummer – gehören als eigenständiger Text direkt unter den Input, nicht als Placeholder. Im ActiveCampaign Form-Builder kannst du für jedes Feld ein persistentes Label und einen Hilfstext definieren, ohne dass du Code schreiben musst. Eine häufige Ausnahme: Suchfelder mit einem eindeutigen Symbol können auf ein explizites Label verzichten, wenn der Kontext unmissverständlich ist. Für Lead-Formulare gilt das nicht.

Fehlermeldungen, die den Weg aus dem Problem zeigen

Schlechte Fehlermeldungen kosten mehr Conversions als schlechtes Design. "Pflichtfeld" sagt dem Nutzer, dass ein Fehler vorliegt – aber nicht, was genau fehlt oder wie er es beheben kann. Gute Fehlermeldungen sind spezifisch ("Bitte gib eine gültige E-Mail-Adresse ein, zum Beispiel name@domain.de"), stehen direkt neben dem betroffenen Feld statt nur gesammelt oben im Formular, und sind in freundlichem Ton gehalten.

Technisch müssen Fehlermeldungen mit dem zugehörigen Feld über aria-describedby verknüpft sein, damit Screenreader sie vorlesen. Wenn du Inline-Validierung einsetzt – also Fehler direkt beim Verlassen eines Felds anzeigst – achte darauf, nicht zu früh zu validieren. Wer eine Fehlermeldung sieht, bevor er das Feld überhaupt verlassen hat, bricht häufiger ab. Die korrekte Reihenfolge: Validierung beim Verlassen des Felds (on blur), Erfolgsmeldungen hingegen können direkt erscheinen, sobald das Feld valide ist.

Ein weiterer Punkt, den viele vergessen: Fehlerindikatoren dürfen nicht ausschließlich durch Farbe kommuniziert werden (WCAG 1.4.1). Ein rotes Feld allein reicht nicht. Verwende zusätzlich ein Icon oder einen sichtbaren Texthinweis direkt am Feld.

Farbkontrast nach WCAG 2.1 AA

WCAG 2.1 verlangt ein Kontrastverhältnis von mindestens 4,5:1 zwischen Vordergrund- und Hintergrundfarbe für normalen Text und 3:1 für große Texte ab 18 Punkt (oder 14 Punkt fett). Das klingt abstrakt, hat aber einen direkten Praxisbezug: Grautöne, die auf weißem Hintergrund elegant wirken, liegen oft darunter und sind bei schlechten Lichtverhältnissen für viele Nutzer kaum lesbar – nicht nur für Personen mit Sehbeeinträchtigungen.

Besonders häufig problematisch: Placeholder-Text in hellem Grau, Submit-Buttons mit geringem Kontrast und Fehlermeldungen in Pastellrot. Teste deine Farbkombinationen mit dem kostenlosen WebAIM Contrast Checker oder dem Colour Contrast Analyser. Beide akzeptieren Hex-Werte und zeigen sofort, ob du WCAG AA oder AAA (7:1) erreichst. Für Formularbereiche gilt außerdem: Eingabefelder brauchen einen sichtbaren Rahmen oder eine ausreichende Kontraständerung zum Hintergrund (WCAG 1.4.11 Non-text Contrast, Mindest-Kontrastverhältnis 3:1). Ein weißes Feld auf weißem Hintergrund ohne Rahmen ist für viele Nutzer nicht als Eingabefeld erkennbar.

Tastatur- und Fokus-Management

Vollständige Tastaturbedienbarkeit ist für Screenreader-Nutzer eine Grundvoraussetzung – und für Tastatur-Power-User eine echte Produktivitätshilfe. Die Anforderungen sind klar: Tab-Reihenfolge von oben nach unten und links nach rechts, Submit-Button am Ende, alle interaktiven Elemente erreichbar, Fokusstatus immer sichtbar. Der Standard-Browser-Fokusring reicht oft nicht aus; ein eigener Fokus-Style mit mindestens 3:1 Kontrast zum Hintergrund ist die bessere Wahl.

Radio-Button-Gruppen sollten mit den Pfeiltasten navigierbar sein, Dropdowns mit Enter öffnen und Escape schließen. Teste das in drei Minuten selbst: Öffne das Formular, lege die Maus beiseite und navigiere ausschließlich mit der Tab-Taste. Jedes Feld, das du nicht erreichst, ist ein potenzieller Conversion-Verlust. WCAG 2.2 ergänzt diese Anforderungen um eine Mindestgröße und Mindestkontrast des Fokus-Rings (Kriterium 2.4.11), die über den bisherigen Standard hinausgehen.

Mobile Eingabetypen und Touch-Targets

HTML bietet spezifische Eingabetypen, die auf mobilen Geräten das passende Keyboard anzeigen: type="email" gibt auf iOS und Android ein Keyboard mit @-Zeichen, type="tel" das Nummernpad, inputmode="numeric" ein reines Ziffern-Keyboard für Textfelder mit numerischem Inhalt. Diese Attribute kosten nichts und machen das Ausfüllen auf dem Smartphone direkt einfacher.

Touch-Targets müssen mindestens 44×44 CSS-Pixel groß sein (WCAG 2.5.5). Checkboxen und Radio-Buttons mit kleinem Klickbereich sind auf dem Smartphone eine häufige Fehlerquelle. Vergib kleineren Steuerelementen ein größeres transparentes Wrapper-Element oder nutze padding, um die Klickfläche zu vergrößern, ohne das visuelle Design zu verändern. Zwischen anklickbaren Elementen sollte genug Abstand vorhanden sein, damit ein versehentlicher Klick auf das falsche Element die Ausnahme bleibt.

So prüfst du dein ActiveCampaign-Formular in 20 Minuten

Diese Prüfroutine deckt die häufigsten Schwachstellen ab. Du brauchst nur einen Browser, eine Tastatur und ein Smartphone.

1. Labels sichten: Fange an, jedes Feld auszufüllen. Prüfe, ob das Label während der Eingabe sichtbar bleibt. Wenn es verschwindet, wird Placeholder-Text als Label-Ersatz verwendet. Das lässt sich im ActiveCampaign Form-Builder unter den Feldeinstellungen korrigieren.
2. Tastaturtour: Setze den Cursor oben links ins Formular und navigiere ausschließlich mit der Tab-Taste. Jedes Eingabefeld, jede Checkbox und der Submit-Button müssen erreichbar sein. Markiere alles, was du nicht erreichst.
3. Fokusstatus prüfen: Achte beim Tabben darauf, ob du jederzeit siehst, welches Element aktuell fokussiert ist. Wenn der Cursor optisch verschwindet, fehlt ein sichtbarer Fokus-Stil.
4. Fehlermeldungen testen: Sende das Formular mit leerem Pflichtfeld ab. Lies die Fehlermeldung laut vor: Beschreibt sie das Problem und den Lösungsweg? Steht sie direkt beim betroffenen Feld?
5. Kontrast messen: Kopiere die Farbe deines Label-Texts und die Hintergrundfarbe in den WebAIM Contrast Checker (webaim.org/resources/contrastchecker). Das Ergebnis muss mindestens 4,5:1 zeigen. Prüfe auch den Placeholder-Text und den Button-Text.
6. Mobil-Test: Öffne das Formular auf einem echten Smartphone, nicht im Browser-Simulator. Tippe ins E-Mail-Feld und prüfe, ob das @-Zeichen direkt auf der Tastatur sichtbar ist. Prüfe, ob du alle Checkboxen ohne Zoom treffsicher antippen kannst.
7. Farbsignal-Check: Stelle die Bildschirmanzeige auf Graustufen (iOS: Einstellungen – Bedienungshilfen – Anzeige und Textgröße – Farbfilter – Graustufen). Prüfe, ob Pflichtfelder und Fehlermeldungen noch erkennbar sind oder ob die Information ausschließlich durch Farbe transportiert wird.

Labels, Hilfstext und Fehlermeldungen lässt sich direkt im ActiveCampaign Form-Builder konfigurieren. Fokus-Styles und Kontraststärke erfordern in der Regel ein kleines CSS-Snippet, das du im Form-Builder unter Custom CSS einfügst. Was der Form-Builder nicht abdeckt – etwa spezifische Eingabetypen wie type="email" – lässt sich über den Embed-Code nachträglich ergänzen.

Typische Fehler und was dahintersteckt

Validierung, die zu früh greift

Inline-Validierung, die bereits während der Eingabe Fehler anzeigt, ist eine der häufigsten Ursachen für erhöhte Abbruchraten. Wer "Ungültige E-Mail" sieht, während er noch tippt, erlebt eine unnötige Unterbrechung. Das korrekte Muster: Fehler beim Verlassen des Felds anzeigen (on blur), nicht bei jedem Tastendruck. Erfolgsmeldungen – ein grünes Häkchen – können hingegen direkt erscheinen, sobald das Feld valide ist. Diese Asymmetrie fühlt sich für Nutzer deutlich angenehmer an.

Fehlermeldungen nur oben sammeln

Ein Fehler-Summary am Formularkopf, der alle Fehler auflistet, ist sinnvoll als Ergänzung – aber nicht als einziger Ort für Fehlermeldungen. Viele Nutzer scrollen nach dem Klick auf den Submit-Button automatisch nach unten, um weiterzumachen. Wenn Fehlermeldungen nur oben erscheinen, werden sie häufig nicht gesehen. Das Ergebnis: Der Nutzer klickt erneut auf den Submit-Button, es passiert scheinbar nichts, er verlässt die Seite. Korrekte Strategie: Fehler direkt beim Feld anzeigen und zusätzlich einen Summary mit Links zu den betroffenen Feldern am Formularkopf einblenden.

Autocomplete deaktivieren

Viele Formulare deaktivieren autocomplete, weil Designer ein sauberes Erscheinungsbild bevorzugen oder weil datenschutzrechtliche Unsicherheiten bestehen. Das ist aus mehreren Gründen problematisch: Autocomplete ist explizit ein Barrierefreiheitsfeature (WCAG 1.3.5), das Menschen mit motorischen Einschränkungen das Tippen erspart – und gleichzeitig die Ausfüllgeschwindigkeit für alle Nutzer erhöht. DSGVO-Konformität und Autocomplete schließen sich nicht aus; Autocomplete nutzt lokal im Browser gespeicherte Daten und überträgt nichts an den Server.

Formulare in Custom-ARIA-Konstrukten bauen

Wer benutzerdefinierte Dropdowns, Custom-Checkboxen oder Toggle-Switches mit div-Elementen und JavaScript baut, ohne die entsprechenden ARIA-Rollen und -Zustände zu setzen, erzeugt für Screenreader unsichtbare Elemente. Die bessere Ausgangslage: native HTML-Steuerelemente verwenden, wo es geht. Benutzerdefinierte Elemente nur mit vollständigem ARIA-Pattern aufbauen, das von gängigen Screenreadern getestet wurde. Die ARIA Authoring Practices Guide des W3C listet alle Muster mit Beispielcode.

Formulare ohne Fortschrittsanzeige bei mehreren Schritten

Mehrstufige Formulare reduzieren die anfängliche Einstiegshürde, bringen aber eine eigene Anforderung mit: Jeder Schritt braucht eine klare Fortschrittsanzeige ("Schritt 2 von 3"), der Fokus muss beim Seitenwechsel korrekt auf den Anfang des neuen Schritts gesetzt werden, und Nutzer sollten einen abgebrochenen Prozess ohne Datenverlust wieder aufnehmen können. Fehlt die Fortschrittsanzeige, ist die Abbruchrate in der Mitte des Formulars oft deutlich höher als auf der letzten Seite – weil Nutzer nicht wissen, wie viel noch kommt.

Wann Barrierefreiheit allein nicht ausreicht

Ein barrierefreies Formular mit zwanzig Pflichtfeldern wird trotzdem schlecht konvertieren. Barrierefreiheit beseitigt Reibung bei der Bedienung des Formulars – sie kann nicht kompensieren, wenn das Formular selbst zu viel verlangt. Die Faustregel, nur die wirklich notwendigen Felder abzufragen, gilt unabhängig von der Barrierefreiheit. Telefonnummer, Unternehmensname und "Wie sind Sie auf uns aufmerksam geworden" sind in einem ersten Lead-Formular in den meisten Fällen überflüssig.

Wenn du die Wahl hast zwischen einem barrierefreien Formular mit zehn Feldern und einem nicht vollständig konformen Formular mit vier Feldern, wird das kürzere Formular in der Regel mehr Einsendungen bringen. Beides zusammen – wenige Felder und barrierefreie Umsetzung – ist das Ziel. Progressive Disclosure, also das Nachladen weiterer Felder nach der initialen Einsendung, ist eine Möglichkeit, beides zu verbinden: niedrige Einstiegshürde beim Erstkontakt, vollständige Daten im Folgeprozess über nachgelagerte Formulare oder Automation-Sequenzen in ActiveCampaign.

Barrierefreiheit schützt auch nicht gegen grundlegende UX-Fehler: ein Submit-Button mit unklarer Beschriftung, fehlendes Vertrauen durch ausbleibende Datenschutzhinweise, oder ein Design, das ein Formular nicht als Formular erkennbar macht. Diese Punkte müssen separat bewertet werden. Die Barrierefreiheitsprüfung ist kein Ersatz für einen allgemeinen UX-Review.

Häufige Fragen

Gilt das BFSG auch für kleinere Unternehmen?

Kleinstunternehmen mit weniger als zehn Beschäftigten und unter zwei Millionen Euro Jahresumsatz sind von wesentlichen Teilen des BFSG ausgenommen. Für alle anderen Unternehmen, die Produkte oder digitale Dienstleistungen in der EU anbieten, gelten die Anforderungen. Wer unsicher ist, ob sein Angebot in den Geltungsbereich fällt, sollte die Anwendungsfälle in den Artikeln 3 und 4 des BFSG prüfen oder rechtlichen Rat einholen.

Reicht es, das ActiveCampaign-Standardformular zu verwenden?

ActiveCampaign-Formulare bringen eine gute technische Basis mit: Labels sind standardmäßig vorhanden, die Tab-Reihenfolge ist korrekt, und die Felder sind per Tastatur erreichbar. Schwachstellen zeigen sich häufig beim Kontrast – der Standard-Grauton für Hilfstext liegt oft unter dem WCAG-Mindestkontrastverhältnis – und bei Custom-Styles, die über eigenes CSS eingebracht werden. Ein Test mit dem WebAIM Contrast Checker und ein Tastaturdurchlauf zeigen schnell, wo Anpassungsbedarf besteht.

Was ist der Unterschied zwischen WCAG 2.1 und WCAG 2.2 für Formulare?

WCAG 2.2, als erweiterter W3C-Standard, ergänzt WCAG 2.1 um neun neue Erfolgskriterien. Für Formulare relevant sind vor allem: Kriterium 2.4.11 (Focus Appearance) mit Mindestanforderungen an Größe und Kontrast des Fokus-Rings und Kriterium 2.5.7 (Dragging Movements), das verlangt, dass alle Gesten, die ein Ziehen erfordern, auch per Einfachklick ausführbar sind. Das BFSG verweist auf WCAG 2.1; WCAG 2.2 setzt dennoch den faktischen Standard für neue Entwicklungen ab 2025.

Wie lange dauert es, ein bestehendes Formular barrierefrei zu machen?

Bei einem Standard-ActiveCampaign-Formular sind die häufigsten Probleme – Kontrast, Hilfstext-Formulierung, feldnahe Fehlermeldungen – in zwei bis drei Stunden behoben. Custom-HTML-Formulare mit eigenen Steuerelementen können mehr Aufwand erfordern, abhängig davon, wie weit sie von nativen HTML-Elementen abweichen. Die Prüfroutine aus diesem Beitrag zeigt die größten Lücken in unter 20 Minuten.

Was passiert bei einem Verstoß gegen das BFSG?

Marktüberwachungsbehörden können Verstöße mit Verwarnungen, Bußgeldern oder Untersagungsverfügungen ahnden. Verbraucherschutzverbände haben zudem das Recht, Verstöße abzumahnen. Das Risiko steigt mit der Reichweite des Angebots: Je mehr Nutzer ein Formular täglich verwenden, desto wahrscheinlicher ist eine Prüfung.

Wer das Thema von der Grundlage her angehen will – von der Formularstruktur über Double Opt-In bis zur Automation nach dem Absenden – findet in unserem Beitrag zu Anmeldeformularen und Conversion-Optimierung den nächsten logischen Schritt. Barrierefreiheit ist dabei eine Ebene, die sich von Anfang an einbauen lässt, nicht eine Korrektur im Nachgang.