Kontaktformular barrierefrei nach BFSG: Checkliste für mehr Anfragen

Viele Webseiten verlieren wertvolle Leads nicht beim Traffic, sondern im Formular. Wenn Pflichtfelder, Fehlermeldungen oder CAPTCHA nicht barrierefrei funktionieren, brechen Nutzer den Kontaktversuch ab. Genau das wird unter dem BFSG schnell teuer: verlorene Anfragen, schlechte Nutzererfahrung und unnötiges Abmahnrisiko.

Warum Kontaktformulare Umsatz-relevant sind

Kontaktformulare liegen nah am Abschluss: Angebotsanfrage, Terminwunsch, Supportfall oder Rückrufbitte. Wenn an dieser Stelle ein Formularfeld nicht beschriftet ist oder eine Fehlermeldung nur rot aufleuchtet, ist der Lead schnell verloren. Für Agenturen, Praxen, Handwerker und Shops ist das kein Designproblem, sondern ein Conversion-Problem.

BFSG und WCAG 2.1 AA verlangen dabei keine Magie, sondern saubere Grundlagen: semantische Formularfelder, programmatisch verknüpfte Labels, verständliche Hinweise und robuste Fehlerrückmeldungen.

Die häufigsten Fehler in Lead-Formularen

• Placeholder statt Label: Sobald der Nutzer tippt, verschwindet der Hinweis.
• Pflichtfelder nur mit Farbe markiert: Farbfehlsichtige Nutzer sehen die Information nicht zuverlässig.
• Fehlertexte ohne Feldbezug: Nutzer wissen nicht, was genau korrigiert werden muss.
• CAPTCHA ohne Alternative: Bilderrätsel oder Rechenaufgaben blockieren reale Anfragen.
• Mobil zu kleine Klickziele: Checkboxen und Buttons sind zu eng oder zu klein.

Praxis-Checkliste für BFSG-konforme Kontaktformulare

1. Jedes Feld braucht ein sichtbares Label

Beispiele: Name, E-Mail, Telefon, Ihre Nachricht. Das Label muss mit dem Feld verbunden sein, nicht nur darüber stehen.

2. Pflichtfelder klar kennzeichnen

Nutzen Sie sichtbare Hinweise wie * Pflichtfeld und verknüpfen Sie diese Information technisch mit dem Feld. Nur ein roter Rahmen reicht nicht aus.

3. Fehler direkt am Feld beschreiben

Statt „Es ist ein Fehler aufgetreten“ besser: „Bitte geben Sie eine gültige E-Mail-Adresse ein.“ Verbinden Sie den Fehlertext mit dem betroffenen Feld, damit Screenreader ihn vorlesen.

4. Fokus nach Absenden sinnvoll steuern

Wenn das Formular Fehler enthält, muss der Nutzer direkt zum ersten Problem gelangen. Sonst sucht er im Blindflug durch die ganze Seite.

5. CAPTCHA nur mit barrierefreier Alternative

Versteckte Spam-Schutzmethoden wie Honeypots oder serverseitige Heuristiken sind oft besser als visuelle Rätsel. Falls ein CAPTCHA unvermeidbar ist, braucht es eine zugängliche Alternative.

Ein solides HTML-Grundmuster

<label for="email">E-Mail-Adresse</label>
<input id="email" name="email" type="email" required aria-describedby="email-hint email-error">
<p id="email-hint">Wir melden uns innerhalb von 24 Stunden.</p>
<p id="email-error">Bitte geben Sie eine gültige E-Mail-Adresse ein.</p>

WCAG-Kriterien, die besonders oft reißen

• 1.3.1 Info and Relationships: Labels und Zusammenhänge fehlen.
• 3.3.1 Error Identification: Fehler werden nicht eindeutig benannt.
• 3.3.2 Labels or Instructions: Eingabe-Hinweise sind unklar oder unsichtbar.
• 2.1.1 Keyboard: Checkboxen, Uploads oder Datepicker sind nicht sauber per Tastatur nutzbar.

Was Sie heute prüfen sollten

1. Formular nur mit Tastatur ausfüllen.
2. Fehler absichtlich provozieren: leere Pflichtfelder, falsche E-Mail, zu kurze Nachricht.
3. Bei 200 Prozent Zoom testen, ob alles lesbar und bedienbar bleibt.
4. Den Kontaktpfad mit dem Scanner und anschließendem manuellen Formular-Test prüfen.

Mehrstufige Formulare und Fortschrittsanzeigen barrierefrei gestalten

Viele Kontakt- und Angebotsformulare bestehen heute aus mehreren Schritten: erst das Anliegen auswählen, dann Kontaktdaten, dann eine Zusammenfassung. Jeder Schrittwechsel ist eine eigene Hürde, wenn er nicht sauber umgesetzt ist.

Nach jedem Schrittwechsel muss der Fokus gezielt auf den Anfang des neuen Abschnitts gesetzt werden, damit Screenreader-Nutzer nicht selbst suchen müssen, wo der neue Inhalt beginnt. Eine Fortschrittsanzeige wie „Schritt 2 von 3“ sollte nicht nur visuell, sondern auch als Text vorhanden sein, damit sie vorgelesen werden kann.

Wird ein Schritt per JavaScript ohne vollständigen Seitenneuladen ausgetauscht, braucht es eine aria-live-Region, die den Wechsel ankündigt. Ohne diesen Hinweis bemerken Screenreader-Nutzer oft gar nicht, dass sich der Inhalt geändert hat, und füllen weiterhin Felder aus, die gar nicht mehr sichtbar sind.

Bewährt hat sich außerdem, den Zurück-Button klar zu beschriften und sicherzustellen, dass bereits eingegebene Daten beim Zurückgehen erhalten bleiben. Ein Formular, das bei jedem Rückschritt alles löscht, frustriert nicht nur Nutzer mit Screenreadern, sondern jeden.

Datei-Uploads im Kontaktformular barrierefrei anbieten

Sobald ein Formular Datei-Anhänge erlaubt — etwa Fotos für eine Handwerker-Anfrage oder Dokumente für eine Bewerbung —, kommen zusätzliche Anforderungen hinzu, die im reinen Text-Formular keine Rolle spielen.

• Der Upload-Button braucht ein eindeutiges Label, das erklärt, was hochgeladen werden soll, nicht nur ein generisches „Datei wählen“.
• Erlaubte Dateiformate und die maximale Dateigröße müssen als Text angegeben sein, nicht nur in einer Tooltip-Grafik.
• Fehlermeldungen bei zu großen Dateien oder falschem Format müssen konkret benennen, was falsch war — „Fehler beim Upload“ allein reicht nicht.
• Wird eine Drag-and-Drop-Fläche angeboten, braucht es zusätzlich einen klassischen Datei-Auswahl-Button, weil Drag-and-Drop per Tastatur kaum bedienbar ist.

Nach erfolgreichem Upload sollte die Bestätigung nicht nur visuell als Häkchen erscheinen, sondern auch als Text — etwa der Dateiname mit dem Hinweis „hochgeladen“. So lässt sich der Status auch ohne visuelle Wahrnehmung nachvollziehen, und Nutzer können vor dem Absenden kontrollieren, ob die richtige Datei angehängt wurde.

Eingabehilfen und Autovervollständigung richtig einsetzen

Browser und Passwortmanager bieten von Haus aus eine Autovervollständigung an, die Namen, Adressen oder E-Mail-Adressen automatisch in Formularfelder einträgt. Damit das zuverlässig funktioniert, brauchen Eingabefelder ein korrektes autocomplete-Attribut, das den Feldzweck technisch benennt — etwa für Vorname, Nachname, Telefonnummer oder Postleitzahl.

Für Menschen mit motorischen Einschränkungen oder kognitiven Beeinträchtigungen ist diese Automatik keine Bequemlichkeit, sondern oft der Unterschied zwischen einem ausfüllbaren und einem unüberwindbaren Formular. Wer lange Texte nur mühsam eintippen kann, profitiert erheblich davon, wenn wiederkehrende Angaben automatisch übernommen werden, statt bei jedem Formular neu eingegeben werden zu müssen.

Ein häufiger Fehler ist, das Autovervollständigen technisch zu blockieren, etwa aus einem falsch verstandenen Sicherheitsgedanken heraus. Das mag bei sensiblen Feldern wie Zahlungsdaten in bestimmten Fällen nachvollziehbar sein, ist bei einem einfachen Kontaktformular aber unnötig und erschwert die Nutzung ohne echten Sicherheitsgewinn.

Ebenso hilfreich sind klar formulierte, dauerhaft sichtbare Eingabehinweise statt reiner Platzhaltertexte, die beim Fokussieren des Feldes verschwinden. Ein Beispiel wie „Format: TT.MM.JJJJ“ direkt unter dem Feld hilft allen Nutzern, unabhängig davon, ob sie eine assistive Technologie verwenden oder nicht.

Bestätigung nach dem Absenden barrierefrei gestalten

Nach dem Absenden entscheidet sich, ob ein Nutzer sicher sein kann, dass die Anfrage wirklich angekommen ist. Eine reine optische Änderung, die nur als grüner Haken erscheint, bleibt für Screenreader unbemerkt. Die Erfolgsmeldung braucht entweder eine aria-live-Region, die den neuen Text automatisch ankündigt, oder der Fokus wird gezielt auf eine Überschrift mit der Bestätigung gesetzt.

Wird das Formular per JavaScript ohne Seitenneuladen abgeschickt, sollte die Meldung so formuliert sein, dass sie auch ohne visuellen Kontext verständlich ist, etwa "Ihre Nachricht wurde gesendet, wir melden uns in Kürze" statt nur "Fertig". Tritt beim Absenden ein Fehler auf, etwa durch eine unterbrochene Verbindung, muss diese Meldung ebenso zuverlässig angekündigt werden wie eine normale Validierung, und bereits eingegebene Daten dürfen dabei nicht verloren gehen.

Einwilligungen und Pflichtfelder-Checkboxen zugänglich gruppieren

Datenschutz-Checkboxen und andere Einwilligungen werden oft nachträglich in ein bestehendes Formular eingefügt und dabei technisch schlecht angebunden. Jede Checkbox braucht ein eigenes, mit dem Feld verknüpftes Label, auch wenn der sichtbare Text einen Link zur Datenschutzerklärung enthält. Der zugängliche Name der Checkbox muss den gesamten Satz umfassen, nicht nur das Wort hier oder Datenschutzerklärung.

Gehören mehrere Checkboxen inhaltlich zusammen, etwa für unterschiedliche Kontaktkanäle oder Newsletter-Themen, sollten sie gruppiert und mit einer gemeinsamen Beschreibung des Zwecks versehen werden, damit ein Screenreader den Zusammenhang erkennt. Individuell gestylte Checkboxen verlieren dabei häufig den sichtbaren Fokusrahmen, weil das native Element per CSS ausgeblendet wird. Wird ein eigenes visuelles Element nachgebaut, muss dessen Fokuszustand genauso deutlich sichtbar bleiben wie beim Original.

Erfolgsmeldung und Datenschutz-Hinweis nach dem Absenden barrierefrei gestalten

Nach dem Absenden eines Kontaktformulars entscheidet sich oft, ob ein Nutzer sicher ist, dass seine Anfrage angekommen ist. Wird die Bestätigung nur optisch eingeblendet – etwa ein grüner Rahmen oder ein kurz aufblitzender Haken –, bekommen Screenreader-Nutzer davon nichts mit. Sie füllen das Formular unter Umständen ein zweites Mal aus oder brechen verunsichert ab, weil kein hörbares Signal für den erfolgreichen Versand vorliegt.

Technisch löst das eine aria-live-Region, die den Erfolgstext ankündigt, sobald er erscheint. Ersetzt das Formular seinen Inhalt per JavaScript durch die Bestätigung, muss der Fokus gezielt auf die neue Meldung oder eine Überschrift darüber gesetzt werden. Leitet die Seite stattdessen auf eine eigene Danke-Seite weiter, entsteht dieses Problem gar nicht erst, weil der komplette Seitenwechsel ohnehin vom Screenreader erfasst wird.

Ein zweiter häufig übersehener Punkt ist die Datenschutz-Checkbox. Oft steht der Hinweistext lose neben einer kleinen Box, ohne dass beide programmatisch verbunden sind. Ein Screenreader liest dann nur "Checkbox, nicht markiert" vor, ohne zu sagen, wofür. Die Checkbox braucht ein echtes, verknüpftes Label, und der Link zur Datenschutzerklärung darin muss per Tastatur erreichbar und optisch als Link erkennbar sein, nicht nur farblich abgesetzt.

Bei längeren, mehrseitigen Anfrageformularen kommt gelegentlich eine serverseitige Session-Zeitbegrenzung hinzu: Wer zu lange für die Eingabe braucht, verliert plötzlich alle Daten. Wo eine solche Begrenzung technisch notwendig ist, sollte der Nutzer rechtzeitig vorher gewarnt werden und die Möglichkeit bekommen, die Zeit zu verlängern, statt ohne Vorwarnung vor einem leeren Formular zu stehen.

Häufig gestellte Fragen