Barrierefreie Formulare: wo die meisten scheitern

Von Manuel Hack, ihp media · Aktualisiert am 20. Juni 2026

Wer ein Kontaktformular auf seiner Website betreibt, lässt täglich Anfragen liegen, ohne es zu wissen. Screenreader-Nutzerinnen, Menschen, die nur die Tastatur bedienen, und Besucher mit schlechtem Sehvermögen scheitern oft genau dort, wo eine Kontaktaufnahme stattfinden soll. Das ist kein seltenes Szenario: In Deutschland leben nach Angaben des Statistischen Bundesamts über 7,9 Millionen Menschen mit einer Schwerbehinderung, und seit dem 28. Juni 2025 ist die Barrierefreiheit von Webformularen für viele Unternehmen eine gesetzliche Pflicht nach dem BFSG. Dieser Artikel zeigt konkret, was ein zugängliches Formular technisch ausmacht, welche WCAG-2.2-Kriterien zählen, und wie Sie das Schritt für Schritt umsetzen.

Warum Formulare so oft scheitern

Die häufigsten Barrieren sind unsichtbar, wenn man die Website mit der Maus und gutem Sehvermögen bedient. Platzhaltertexte statt dauerhafter Labels verschwinden beim Tippen, niemand sieht das Problem. Ein Button-Div ohne Tastaturfokus funktioniert mit der Maus einwandfrei. Eine rote Umrandung signalisiert einem sehenden Nutzer sofort, dass das Feld fehlt, dem Screenreader aber gar nichts.

Das WAI-Tutorial zu Formularen (w3.org/WAI/tutorials/forms) nennt den entscheidenden Grund: Barrierefreie Formulare brauchen nicht nur ein funktionierendes visuelles Interface, sondern zusätzlich eine maschinenlesbare Bedeutungsschicht, die für Screenreader, Sprachsteuerungen und andere assistive Technologien zugänglich ist. Fehlt diese Schicht, kann ein Nutzer mit Screenreader das Feld zwar sehen oder hören, aber nicht verstehen, was hineingehört.

Welche WCAG-Kriterien betroffen sind, welche häufigsten Fehler auf Websites allgemein auftreten und wie automatische Tests einzustufen sind, zeigt der Artikel Die 12 häufigsten Barrierefreiheitsfehler. Hier konzentrieren wir uns auf das Kontaktformular.

Labels: die Grundlage zugänglicher Felder

Ein Label erfüllt zwei Aufgaben gleichzeitig: Es beschriftet das Feld sichtbar für alle Besucher, und es teilt dem Screenreader mit, was in das Feld eingegeben werden soll. Die Verknüpfung passiert im Code über das for-Attribut des Labels und die id des Eingabefelds, die übereinstimmen müssen.

Das klingt selbstverständlich, ist aber in der Praxis einer der am häufigsten verletzten Punkte. Das WCAG-2.2-Kriterium 3.3.2 „Beschriftungen oder Anweisungen“ (Stufe AA) verlangt sichtbare Beschriftungen für alle Formularfelder. Dass sie zusätzlich programmatisch verfügbar sein müssen, regelt Kriterium 1.3.1 „Informationen und Beziehungen“ (Stufe A).

Der Platzhaltertext ist die beliebteste Abkürzung und die problematischste: Er verschwindet beim Tippen, wird von manchen Screenreadern gar nicht vorgelesen und ist visuell oft zu blass (Kontrast unter 4,5:1). Laut WAI-Tutorial „Labeling Controls“ ist ein placeholder-Attribut kein Ersatz für ein Label.

Wo ein sichtbares Label den Aufbau stört, zum Beispiel bei einer einzeiligen Suchleiste, gibt es saubere Alternativen: Das Label kann visuell per CSS versteckt werden (nicht mit display:none, sonst ist es auch für Screenreader unsichtbar, sondern mit einer Clip-Technik, die es aus dem Sichtbereich nimmt, aber im Zugänglichkeitsbaum belässt). Oder man setzt aria-label direkt am Eingabefeld. Diese Ausnahme gilt aber nicht für normale Kontaktformulare, dort gehört das Label sichtbar über das Feld.

Die Anordnung spielt ebenfalls eine Rolle. Labels über dem Feld, nicht daneben, verarbeiten Besucher auf schmalen Displays und bei Zoom-Vergrößerung schneller, weil die Leserichtung linear bleibt. Das empfehlen auch die WAI-Tutorials explizit.

Für zusätzliche Hinweise, etwa ein Datumsformat oder eine Zeichenbeschränkung, nutzt man aria-describedby: Ein Hinweistext unterhalb des Feldes erhält eine id, die man im Attribut referenziert. Der Screenreader liest den Hinweis vor, sobald der Nutzer das Feld fokussiert, noch vor dem ersten Buchstaben.

Pflichtfelder korrekt kennzeichnen

Eine rote Umrandung, eine andere Hintergrundfarbe, ein dickerer Rahmen: All das sind rein visuelle Unterschiede, die auf Farbe oder Kontrast als einzigem Unterscheidungsmerkmal beruhen. Das verletzt WCAG 2.2 Kriterium 1.3.1, denn Menschen mit Farbfehlsichtigkeit und Screenreader-Nutzerinnen erhalten keine Information darüber, welches Feld ausgefüllt werden muss.

Die richtige Technik kombiniert drei Elemente: ein sichtbares Symbol (üblicherweise ein Sternchen), eine erklärende Legende am Formularanfang (z. B. „Mit * markierte Felder sind Pflichtfelder“) und das HTML-Attribut required am Eingabefeld, das Browser und Screenreader über die Pflicht informiert. Das required-Attribut löst zusätzlich die native Browser-Validierung aus, die in modernen Browsern ebenfalls barrierefrei ist.

Das Attribut aria-required="true" ist die ARIA-Entsprechung für Fälle, in denen kein natives required eingesetzt wird. Beides zusammen zu setzen ist redundant und unnötig. In Standard-HTML-Formularen genügt required.

Fehlermeldungen, die wirklich helfen

WCAG 2.2 Kriterium 3.3.1 „Fehlererkennung“ (Stufe AA) schreibt vor: Wenn ein Eingabefehler automatisch erkannt wird, muss das fehlerhafte Element identifiziert und der Fehler in Textform beschrieben werden. Das bedeutet: eine rote Umrandung allein ist ein Verstoß, weil sie erstens nur auf Farbe beruht und zweitens keinen beschreibenden Text liefert.

Eine zugängliche Fehlermeldung erfüllt drei Bedingungen gleichzeitig. Sie ist als echter Text im DOM vorhanden, nicht als CSS-Pseudoelement oder Hintergrundgrafik. Sie ist programmatisch mit dem fehlerhaften Feld verknüpft, entweder per aria-describedby oder indem der Fokus beim Absenden auf eine sichtbare Fehlerzusammenfassung am Seitenanfang gesetzt wird. Und sie enthält einen Lösungshinweis: nicht „Ungültige E-Mail-Adresse“, sondern „Bitte geben Sie eine E-Mail-Adresse im Format name@beispiel.de ein.“

Das Attribut aria-invalid="true" teilt dem Screenreader mit, dass ein Feld fehlerhaft ist. Es sollte immer zusammen mit einer Fehlermeldung in Textform eingesetzt werden, niemals allein. Ohne begleitenden Text weiß der Nutzer nur, dass etwas falsch ist, aber nicht was.

Für dynamisch nachgeladene Fehlermeldungen, also solche, die nach dem Absenden ohne Seitenreload erscheinen, empfiehlt das WAI-Tutorial zu Nutzerbenachrichtigungen entweder aria-live="polite" am Fehlercontainer, damit Screenreader die Meldung beim nächsten Pausemoment vorlesen, oder eine Fokusversetzung auf die Fehlerzusammenfassung nach dem Absenden.

In einem Projekt haben wir ein mehrstufiges Kontaktformular geprüft, das beim Absenden rote Markierungen setzte, aber keinen Text anzeigte. Der Screenreader kündigte lediglich an, dass Fehler vorliegen, ohne zu sagen welche. Nach der Korrektur (Fehlertexte per aria-describedby verknüpft, Fokus auf Fehlerliste gesetzt) konnten Nutzerinnen mit NVDA das Formular ohne sehende Unterstützung ausfüllen. Die technische Änderung war klein, der Unterschied im Erlebnis erheblich.

Fokus und Tastaturbedienung

WCAG 2.2 Kriterium 2.4.7 „Fokus sichtbar“ (Stufe AA) verlangt einen erkennbaren Fokusindikator bei allen interaktiven Elementen. In der Praxis entfernen viele Themes den Fokusrahmen mit outline: 0, weil der Browser-Standard optisch unschön wirkt. Das Ergebnis: Wer nur die Tastatur nutzt, sieht nicht mehr, wo er sich gerade befindet.

Die Lösung ist kein Kompromiss, sondern ein Austausch: statt den Fokusrahmen zu entfernen, einen eigenen gestalten, der zum Markenbild passt und gleichzeitig den Anforderungen genügt. WCAG 2.2 hat mit Kriterium 2.4.13 „Fokus-Erscheinungsbild“ (Stufe AAA) zusätzliche Mindestanforderungen eingeführt: Der Fokusrahmen muss eine Mindestfläche abdecken und einen Kontrast von 3:1 zur angrenzenden Farbe aufweisen.

Für Buttons gilt darüber hinaus: Nur echte <button>-Elemente sind von Haus aus per Tab erreichbar, werden bei Enter und Leertaste ausgelöst und melden sich dem Screenreader als Schaltfläche. Ein <div> mit Click-Handler tut visuell dasselbe, ist für Tastaturnutzer aber unsichtbar. Das nachzurüsten erfordert mindestens tabindex="0", role="button" und eigene Tastatur-Event-Handler. Das ist mehr Aufwand als einfach ein <button> zu verwenden, und fehleranfälliger. Natives HTML ist hier die richtige Wahl.

Wer prüfen will, wie das eigene Formular unter Tastaturbedienung funktioniert, findet im Artikel Website-Barrierefreiheit selbst testen eine Schritt-für-Schritt-Anleitung für den manuellen Tastaturtest.

Felder gruppieren mit fieldset und legend

Einzelne Labels reichen nicht, wenn eine Auswahl nur im Zusammenhang Sinn ergibt. Drei Radio-Buttons mit den Optionen „Morgens“, „Mittags“ und „Abends“ ohne Gruppierung lassen einen Screenreader im Unklaren: Wofür steht die Auswahl? Das <fieldset>-Element fasst zusammengehörige Felder zu einer Gruppe zusammen, <legend> gibt der Gruppe einen Namen, den der Screenreader bei jedem Feld in der Gruppe vorliest.

Das WAI-Tutorial zu Fieldset und Grouping empfiehlt <fieldset> besonders für Radio-Buttons und Checkboxen. Für reine Adressblöcke (Straße, PLZ, Ort) genügt ein gemeinsames <fieldset> mit der Legende „Ihre Adresse“. Als Alternative, wenn CSS-Flexibilität wichtiger ist, funktioniert auch role="group" mit aria-labelledby auf einem beliebigen Container-Element.

Ein Hinweis aus der Praxis: Manche Screenreader lesen die Legende bei jedem Feld der Gruppe vor, andere nur beim ersten. Deshalb sollte die Legende kurz und aussagekräftig sein, und jedes Label in der Gruppe sollte auch ohne den Gruppenkontext verständlich bleiben.

Wann ARIA der richtige Ansatz ist und wann natives HTML ausreicht, erklärt der Artikel ARIA richtig einsetzen.

Überblick: Barrieren, WCAG-Kriterien, Lösungen

Profi-Block: barrierefreies Kontaktformular in HTML

Dieser Block zeigt ein vollständiges, konformes Kontaktformular. Einsteiger können ihn überspringen. Wer das HTML selbst baut oder das Theme anpasst, findet hier die Kernstruktur mit allen relevanten Attributen.

<!-- Legende für Pflichtfelder am Formularanfang -->
<p id="pflicht-hinweis">Mit * markierte Felder sind Pflichtfelder.</p>

<form aria-describedby="pflicht-hinweis" novalidate>

  <!-- Einfaches Textfeld mit Label und Pflichtmarkierung -->
  <div class="feld">
    <label for="name">Ihr Name *</label>
    <input type="text"
           id="name"
           name="name"
           required

           autocomplete="name"
           aria-describedby="name-fehler">
    <span id="name-fehler" role="alert" hidden>
      Bitte geben Sie Ihren Namen ein.
    </span>
  </div>

  <!-- E-Mail-Feld mit Formathinweis -->
  <div class="feld">
    <label for="email">E-Mail-Adresse *</label>
    <input type="email"
           id="email"
           name="email"
           required
           autocomplete="email"
           aria-describedby="email-hinweis email-fehler">
    <span id="email-hinweis">Format: name@beispiel.de</span>
    <span id="email-fehler" role="alert" hidden>
      Bitte geben Sie eine gültige E-Mail-Adresse ein.
    </span>
  </div>

  <!-- Gruppierung mit fieldset für thematisch verbundene Felder -->
  <fieldset>
    <legend>Gewünschter Kontaktweg</legend>
    <label>
      <input type="radio" name="kontaktweg" value="email"> Per E-Mail
    </label>
    <label>
      <input type="radio" name="kontaktweg" value="telefon"> Per Telefon
    </label>
  </fieldset>

  <!-- Textarea mit Label und Zeichenhinweis -->
  <div class="feld">
    <label for="nachricht">Ihre Nachricht *</label>
    <textarea id="nachricht"
              name="nachricht"
              rows="5"
              required
              aria-describedby="nachricht-hinweis"></textarea>
    <span id="nachricht-hinweis">Maximal 1.000 Zeichen.</span>
  </div>

  <!-- Absende-Button: immer ein echtes button-Element -->
  <button type="submit">Nachricht absenden</button>

</form>

Zentrale Punkte in diesem Markup: Das hidden-Attribut blendet Fehlermeldungen aus, bis JavaScript sie nach der Validierung sichtbar macht. role="alert" sorgt dafür, dass der Screenreader die Meldung unmittelbar vorliest, wenn sie eingeblendet wird, ohne dass der Fokus explizit gesetzt werden muss. Das autocomplete-Attribut beschleunigt das Ausfüllen und ist eine Anforderung aus WCAG 2.2 Kriterium 1.3.5. novalidate am Formular schaltet die native Browser-Validierung aus, damit eine eigene, barrierefreiheitskonforme Fehlerdarstellung übernimmt.

Für WordPress-Seiten gilt: Wer ein Formular-Plugin wie Gravity Forms oder WPForms einsetzt, kann Labels, Pflichtfelder und Fehlermeldungen meist ohne eigenes HTML konfigurieren. Voraussetzung ist, dass das Plugin selbst barrierefrei ist und das Theme den Fokusrahmen nicht global entfernt. Beide Punkte verdienen einen kurzen Test.

Schritt für Schritt zum zugänglichen Formular

Schritt 1: Bestand aufnehmen

Öffnen Sie Ihr Kontaktformular und fahren Sie mit der Tab-Taste durch alle Felder. Prüfen Sie: Ist bei jedem Feld ein sichtbares Label vorhanden? Ist beim Durchtabben immer ein Fokusrahmen sichtbar? Klicken Sie auf jedes Label und prüfen Sie, ob der Cursor ins zugehörige Feld springt. Ergänzend hilft ein Scan mit Axe DevTools oder WAVE, die fehlende Label-Verknüpfungen und Kontrastprobleme automatisch melden.

Schritt 2: Labels und Pflichtmarkierungen korrigieren

Jedes Feld bekommt ein dauerhaftes <label> mit for-Attribut. Platzhaltertexte dürfen bleiben, aber nicht als einzige Beschriftung. Pflichtfelder erhalten ein Sternchen im Label-Text und das required-Attribut. Eine Legende am Formularanfang erklärt das Sternchen.

Schritt 3: Fehlermeldungen in Text umwandeln

Für jedes validierte Feld einen Fehlertext-Container anlegen, per aria-describedby mit dem Feld verknüpfen und initial verstecken. Nach dem Absenden: den Fehlertext einblenden, aria-invalid="true" am Feld setzen und den Fokus auf den ersten Fehler oder eine Fehlerliste am Seitenanfang setzen.

Schritt 4: Fokusrahmen wiederherstellen

Im CSS nach outline: none oder outline: 0 suchen, das für Formularfelder und Buttons gilt. Durch einen eigenen Fokusstil ersetzen: Mindestkontrast 3:1 zur angrenzenden Fläche, deutlich sichtbar. Eine solide Basis: outline: 2px solid #0E2F50; outline-offset: 2px;.

Schritt 5: Buttons auf natives HTML prüfen

Im Quelltext nach <div oder <span suchen, die per onclick eine Formularaktion auslösen. Sie durch <button type="submit"> ersetzen. Dasselbe gilt für „Weiter“-Buttons in mehrstufigen Formularen.

Schritt 6: Gruppierende Felder mit fieldset ausstatten

Radio-Button-Gruppen und Checkboxen, die eine gemeinsame Frage beantworten, in <fieldset> + <legend> einschließen. Prüfen, ob die Legende kurz und aussagekräftig ist.

Schritt 7: Mit Screenreader abschließend testen

Das Formular unter Windows mit NVDA + Firefox komplett ausfüllen und absenden, dabei bewusst einen Fehler einbauen. Hört man alle Labels? Werden Fehlermeldungen vorgelesen? Lässt sich der Fehler korrigieren und das Formular erneut absenden? Wer auf macOS entwickelt, kann VoiceOver (Cmd+F5) für einen ersten Test nutzen.

Sofort-Checkliste

• Hat jedes Eingabefeld ein sichtbares, dauerhaftes Label, das nicht beim Tippen verschwindet?
• Ist das Label per for/id programmatisch mit dem Feld verknüpft (Klick aufs Label setzt Fokus ins Feld)?
• Sind Pflichtfelder durch Text oder Symbol gekennzeichnet, nicht nur durch Farbe?
• Liegen Fehlermeldungen als echter Text vor und benennen sie das fehlerhafte Feld sowie den Lösungsweg?
• Sind Fehlermeldungen per aria-describedby mit dem Feld verknüpft oder wird der Fokus auf eine Fehlerliste gesetzt?
• Ist beim Tabben durch das Formular jederzeit ein sichtbarer Fokusrahmen vorhanden?
• Sind alle Buttons echte <button>-Elemente, keine <div>– oder <span>-Ersatzkonstrukte?
• Stehen zusammenhängende Felder (Radio-Buttons, Checkboxen, Adressblock) in einem <fieldset> mit <legend>?
• Lässt sich das Formular vollständig mit einem Screenreader (NVDA + Firefox oder VoiceOver) bedienen?

Häufige Fragen

Reicht ein Platzhaltertext als Label aus?

Nein. Platzhaltertexte verschwinden beim Tippen und werden von manchen Screenreadern nicht zuverlässig vorgelesen. Das WCAG-2.2-Kriterium 3.3.2 und das WAI-Tutorial zu Labels sind eindeutig: Ein dauerhaft sichtbares <label>-Element ist der Mindeststandard. Der Platzhaltertext kann ergänzend eingesetzt werden, als Formathinweis zum Beispiel, aber nicht als einzige Beschriftung.

Muss ich ARIA-Attribute einsetzen, oder reicht natives HTML?

Natives HTML reicht in den meisten Fällen. Ein <label for> ist zugänglicher als aria-label, ein <button> ist zugänglicher als ein <div role="button">. ARIA ist der richtige Ansatz, wenn natives HTML keine passende Semantik bietet, zum Beispiel bei Custom-Dropdown-Menüs oder komplexen Tab-Panels. Für Standard-Kontaktformulare kommt man mit HTML-Bordmitteln weit. Was den Unterschied ausmacht, erklärt der Artikel ARIA richtig einsetzen.

Wie kennzeichne ich ein Pflichtfeld barrierefrei?

Mit drei zusammenwirkenden Elementen: einem sichtbaren Symbol im Label (Sternchen), einer erklärenden Legende am Formularanfang und dem HTML-Attribut required am Eingabefeld. Farbe allein ist kein ausreichendes Kennzeichen, weil sie gegen WCAG 1.3.1 verstößt.

Was ist bei mehrstufigen Formularen zu beachten?

WCAG 2.2 Kriterium 3.3.7 „Redundante Eingabe“ schreibt vor, dass bereits eingegebene Informationen in einem mehrstufigen Prozess nicht erneut eingegeben werden müssen. Entweder werden sie automatisch übernommen oder der Nutzer kann sie per Auswahlmöglichkeit übertragen (z. B. „Lieferadresse entspricht Rechnungsadresse“). Das hilft besonders Menschen mit kognitiven Einschränkungen und verhindert vermeidbare Abbrüche.

Welches Formular-Plugin für WordPress ist barrierefrei?

Gravity Forms und WPForms erzeugen bei korrekter Konfiguration weitgehend konforme Ausgaben. Beide unterstützen korrekte Labels, Pflichtfelder mit required und Fehlermeldungen. Entscheidend ist, dass das Theme keinen globalen outline: none-Reset setzt und dass jede Zahlungsart oder jede dritte Komponente einzeln getestet wird. Ein automatischer Scan mit Axe nach jeder Formular-Konfigurationsänderung kostet wenig Zeit und fängt die häufigsten Probleme. Wer das Formular danach auch für mehr Anfragen optimieren will, findet im Artikel Mehr Anfragen über das Kontaktformular konkrete Hinweise zu Aufbau und Feldanzahl.

Gilt das BFSG auch für Kontaktformulare?

Ja. Das BFSG gilt für alle Inhalte und Funktionen eines Webauftritts, der unter das Gesetz fällt, also auch für das Kontaktformular, das Buchungsformular und jeden anderen Dateneingabe-Schritt. Ob Ihr Unternehmen betroffen ist, zeigt der Artikel BFSG und Onlineshop. Wie Sie den Stand Ihrer Website schnell selbst prüfen, erklärt Website-Barrierefreiheit selbst testen.

Wie teste ich ein Formular mit einem Screenreader?

Unter Windows: NVDA (kostenlos, nvaccess.org) mit Firefox starten, das Formular öffnen und mit Tab durch alle Felder navigieren. Dabei hören, ob jedes Feld angesagt wird, ob Labels vorgelesen werden und ob Fehlermeldungen nach dem Absenden erklingen. Unter macOS und iOS ist VoiceOver eingebaut (Cmd+F5 zum Aktivieren). Die gängigste Screenreader-Browser-Kombination unter echten Nutzern ist laut regelmäßigen Surveys NVDA mit Firefox.