Barrierefreie Formulare: Labels, Fehlermeldungen und Login ohne Hürden

Ein Formular ist oft der Moment, in dem es ernst wird: Bestellung abschließen, Termin buchen, Konto anlegen, Antrag stellen. Genau hier scheitern viele Menschen. Ein Feld ohne Beschriftung, eine Fehlermeldung, die nur aus einem roten Rahmen besteht, ein Bilderrätsel beim Login oder eine Sitzung, die nach wenigen Minuten kommentarlos abläuft – und der Vorgang ist vorbei.

Barrierefreie Formulare helfen dabei weit mehr Menschen als nur denen, die einen Screenreader nutzen. Menschen mit Konzentrations- oder Gedächtnisproblemen profitieren von klaren Hinweisen, Menschen mit motorischen Einschränkungen von automatisch ausgefüllten Feldern, und alle, die unterwegs am Smartphone tippen, von verständlichen Fehlermeldungen. Für Online-Shops ist das zudem keine Kür: Wer unter das Barrierefreiheitsstärkungsgesetz fällt, muss die Anforderungen der WCAG 2.1 auf Stufe AA erfüllen, und Formulare stehen im Zentrum jedes Kaufprozesses.

Die gute Nachricht: Die meisten Lösungen sind schlichtes, semantisches HTML. In diesem Artikel gehst du Schritt für Schritt durch Labels, Pflichtfelder, Hinweise, Gruppierung, autocomplete, Fehlermeldungen, Zeitlimits und Anmeldung, jeweils mit kurzen Codebeispielen.

Sichtbare Labels statt Platzhalter

Jedes Eingabefeld braucht eine sichtbare Beschriftung, die dauerhaft stehen bleibt. Das verlangt 3.3.2 Beschriftungen oder Anweisungen. Ein Platzhalter im Feld ersetzt kein Label: Er verschwindet, sobald du tippst, ist meist zu kontrastarm und wird von manchen Hilfsmitteln nicht zuverlässig als Name des Felds vorgelesen. Spätestens beim Korrigieren einer Eingabe weißt du nicht mehr, was in das Feld gehörte.

Ebenso wichtig ist die technische Verknüpfung. Das label-Element mit passendem for-Attribut sorgt dafür, dass Screenreader den Namen des Felds vorlesen und dass ein Klick auf die Beschriftung das Feld fokussiert. Gerade bei kleinen Checkboxen vergrößert das die Klickfläche spürbar.

<!-- Vorher: nur Platzhalter, kein Label -->
<input type="email" placeholder="E-Mail-Adresse">

<!-- Nachher: sichtbares, verknüpftes Label -->
<label for="email">E-Mail-Adresse</label>
<input id="email" name="email" type="email" autocomplete="email">

Platziere das Label über dem Feld oder links davon, nicht darin. Achte außerdem darauf, dass der sichtbare Text im technischen Namen vorkommt. Wer per Sprachsteuerung „Klick auf E-Mail-Adresse“ sagt, erwartet, dass genau dieses Feld reagiert.

Auch das Layout trägt zur Verständlichkeit bei. Ein einspaltiges Formular, das von oben nach unten gelesen wird, ist für die meisten Menschen leichter zu erfassen als mehrere Felder nebeneinander. Bei starker Vergrößerung bleibt so außerdem das Label sichtbar, wenn das Feld im Blick ist. Ausnahmen wie Postleitzahl und Ort in einer Zeile sind unproblematisch, solange die Reihenfolge logisch bleibt.

Pflichtfelder klar kennzeichnen

Menschen müssen vor dem Ausfüllen wissen, welche Angaben nötig sind. Bewährt haben sich zwei Wege: Entweder steht „(Pflichtfeld)“ direkt im Label, oder du markierst Pflichtfelder mit einem Sternchen und erklärst das Zeichen zu Beginn des Formulars. Sind fast alle Felder Pflicht, ist es oft klarer, die wenigen optionalen Felder mit „(optional)“ zu kennzeichnen.

Ergänze im Code das Attribut required. Screenreader melden das Feld dann als erforderlich, unabhängig von der visuellen Markierung. Verlasse dich aber nicht allein auf Farbe: Ein rot eingefärbtes Label erfüllt die Anforderungen an Farbe und Kontrast nicht, wenn es das einzige Merkmal ist.

<p>Felder mit * sind Pflichtfelder.</p>

<label for="vorname">Vorname *</label>
<input id="vorname" name="vorname" autocomplete="given-name" required>

Hinweise und Formatvorgaben

Erwartest du ein bestimmtes Format, sag es vorher und nicht erst in der Fehlermeldung. Ein Hinweis wie „Fünf Ziffern, zum Beispiel 10115“ oder „Mindestens 12 Zeichen“ steht sichtbar unter dem Label und wird über aria-describedby mit dem Feld verknüpft. Screenreader lesen ihn dann nach Name und Typ des Felds vor.

Noch besser ist es, Formate gar nicht erst vorzuschreiben. Akzeptiere Telefonnummern mit und ohne Leerzeichen, IBANs mit oder ohne Gruppierung und Datumsangaben in gängigen Schreibweisen. Die Normalisierung erledigt dein Code, nicht die Person vor dem Bildschirm.

Wähle außerdem den passenden Feldtyp. type="email", type="tel" oder inputmode="numeric" blenden auf Mobilgeräten die richtige Tastatur ein. Für Postleitzahlen, Kundennummern oder Kartennummern ist type="number" dagegen ungeeignet, weil führende Nullen verloren gehen können und das Mausrad den Wert verändert.

Zusammengehörige Felder gruppieren

Bei Radiobuttons und Checkbox-Gruppen reicht das Label der einzelnen Option nicht aus. Wer per Screenreader auf „Express (1 Werktag)“ landet, muss auch erfahren, dass es um die Versandart geht. Dafür gibt es fieldset und legend: Die Legende wird beim Betreten der Gruppe mit angesagt.

<fieldset>
  <legend>Versandart</legend>
  <input type="radio" id="standard" name="versand" value="standard">
  <label for="standard">Standard (3–5 Werktage)</label>
  <input type="radio" id="express" name="versand" value="express">
  <label for="express">Express (1 Werktag)</label>
</fieldset>

Auch längere Formulare gewinnen durch Gruppen wie „Rechnungsadresse“ und „Lieferadresse“. Halte die Legenden kurz, denn sie werden je nach Screenreader bei jedem Feld der Gruppe wiederholt.

autocomplete: Eingaben automatisch ausfüllen

Das Kriterium 1.3.5 Bestimmung des Eingabezwecks verlangt, dass Felder für persönliche Daten ihren Zweck maschinenlesbar angeben. In HTML gelingt das mit dem Attribut autocomplete. Browser und Passwortmanager füllen die Felder dann zuverlässig aus, und das erspart Menschen mit motorischen oder kognitiven Einschränkungen viel Tipparbeit und Fehler.

<label for="strasse">Straße und Hausnummer</label>
<input id="strasse" name="strasse" autocomplete="address-line1">

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

<label for="ort">Ort</label>
<input id="ort" name="ort" autocomplete="address-level2">

Häufig gebrauchte Werte sind given-name, family-name, email, tel, address-line1, postal-code, address-level2 für den Ort, country-name und bday. Die vollständige Liste steht in der WCAG unter „Input Purposes“. Setze autocomplete="off" nicht pauschal, nur weil es im Template-Baukasten so voreingestellt ist.

Fehlermeldungen, die weiterhelfen

Fehler passieren, das ist normal. Entscheidend ist, wie schnell sich jemand davon erholt. Nach 3.3.1 Fehlererkennung muss ein erkannter Fehler im Text beschrieben und das betroffene Feld benannt werden. 3.3.3 Fehlerempfehlung geht weiter: Wenn du weißt, wie sich der Fehler beheben lässt, sag es.

Die Meldung am Feld

Vergleiche „Ungültige Eingabe“ mit „Die Postleitzahl hat nur vier Ziffern. Bitte gib fünf Ziffern ein.“ Die zweite Meldung erklärt, was falsch ist und was zu tun ist. Sie steht direkt am Feld, wird über aria-describedby verknüpft, und aria-invalid="true" markiert das Feld technisch als fehlerhaft. Ein Warnsymbol oder das Wort „Fehler“ sorgen dafür, dass die Meldung nicht nur über Farbe erkennbar ist.

<label for="plz">Postleitzahl</label>
<p id="plz-hinweis">Fünf Ziffern, zum Beispiel 10115</p>
<input id="plz" name="plz" inputmode="numeric"
       autocomplete="postal-code" aria-invalid="true"
       aria-describedby="plz-hinweis plz-fehler">
<p id="plz-fehler">Fehler: Die Postleitzahl hat nur vier Ziffern.
  Bitte gib fünf Ziffern ein.</p>

Sobald der Fehler behoben ist, entfernst du aria-invalid und die Meldung wieder. Achte außerdem darauf, dass alle Eingaben nach dem Absenden erhalten bleiben: Niemand sollte nach einem Fehler alles noch einmal eintippen müssen.

Die Fehlerübersicht

Bei längeren Formularen hilft eine Zusammenfassung oberhalb des Formulars. Sie listet alle Fehler auf und verlinkt jeweils auf das betroffene Feld. Nach dem fehlgeschlagenen Absenden setzt du den Fokus per JavaScript auf diese Übersicht, damit Screenreader-Nutzer:innen sofort erfahren, was passiert ist.

<div id="fehleruebersicht" tabindex="-1">
  <h2>Bitte korrigiere 2 Angaben</h2>
  <ul>
    <li><a href="#plz">Postleitzahl: Bitte gib fünf Ziffern ein.</a></li>
    <li><a href="#email">E-Mail-Adresse: Das @-Zeichen fehlt.</a></li>
  </ul>
</div>

<script>
  document.getElementById("fehleruebersicht").focus();
</script>

Lädt das Formular nach dem Absenden die Seite neu, passe zusätzlich den Seitentitel an, etwa zu „Fehler: Kontaktformular“. Den Titel lesen Screenreader beim Laden als Erstes vor, und auch im Browser-Tab ist so sofort klar, dass etwas nicht geklappt hat.

Der richtige Zeitpunkt

Prüfe Eingaben nicht bei jedem Tastendruck. Eine Fehlermeldung, die schon nach dem ersten Buchstaben einer E-Mail-Adresse erscheint, verunsichert und erzeugt bei Screenreadern unnötige Ansagen. Bewährt hat sich die Prüfung beim Verlassen eines Felds und beim Absenden. Deaktiviere den Absende-Button nicht, solange das Formular unvollständig ist: Ein grauer Button erklärt nicht, was fehlt, ein Klick mit anschließender Fehlerübersicht schon.

Auch Erfolgsmeldungen gehören dazu. Erscheint nach dem Absenden ohne Seitenwechsel ein Hinweis wie „Deine Nachricht wurde gesendet“, sollte er in einem Element mit role="status" stehen. So wird er angesagt, ohne den Fokus zu verschieben, wie es das Kriterium 4.1.3 zu Statusmeldungen verlangt. Wichtig: Der Container muss schon beim Laden der Seite existieren, nur der Text wird später eingefügt.

Weniger tippen, sicher absenden

Seit WCAG 2.2 verlangt 3.3.7 Redundante Eingabe, dass Informationen, die jemand im selben Vorgang schon eingegeben hat, nicht erneut abgefragt werden, sondern automatisch übernommen oder zur Auswahl angeboten werden. Das klassische Beispiel ist die Checkbox „Lieferadresse entspricht der Rechnungsadresse“. Ausnahmen gelten etwa, wenn die erneute Eingabe aus Sicherheitsgründen nötig ist, wie bei der Bestätigung eines neuen Passworts.

Bei Vorgängen mit rechtlichen oder finanziellen Folgen, also Bestellungen, Verträgen oder Überweisungen, fordert 3.3.4 Fehlervermeidung (rechtlich, finanziell, Daten) eine Sicherung: Die Eingabe lässt sich rückgängig machen, wird auf Fehler geprüft oder vor dem endgültigen Absenden zur Kontrolle angezeigt. Eine Übersichtsseite „Bitte prüfe deine Bestellung“ mit Bearbeiten-Links erfüllt das und reduziert ganz nebenbei Retouren und Supportanfragen.

Zeitlimits fair gestalten

Sitzungen, die nach kurzer Zeit ablaufen, treffen besonders Menschen, die langsamer lesen, tippen oder eine Vorlesefunktion nutzen. 2.2.1 Zeitliche Steuerung anpassbar verlangt deshalb, dass sich Zeitlimits abschalten, verlängern oder anpassen lassen. In der Praxis heißt das meist: Vor Ablauf erscheint eine Warnung, und mit einer einfachen Aktion wie „Sitzung verlängern“ geht es weiter. Dafür müssen mindestens 20 Sekunden Zeit bleiben, und die Verlängerung muss mindestens zehnmal möglich sein.

Ausgenommen sind Echtzeit-Vorgänge wie Auktionen, Fälle, in denen das Zeitlimit unverzichtbar ist, und Limits von mehr als 20 Stunden. Wo immer möglich, speichere Zwischenstände, damit nach einem Ablauf nicht alles verloren ist.

Anmeldung ohne Rätsel

Ebenfalls neu in WCAG 2.2 ist 3.3.8 Barrierefreie Authentifizierung (Minimum). Ein Login darf keinen kognitiven Funktionstest verlangen, also nicht voraussetzen, dass sich jemand etwas merkt, Zeichen abschreibt oder ein Rätsel löst, solange es keine Alternative oder Hilfe gibt. Passwörter sind erlaubt, wenn Passwortmanager sie ausfüllen dürfen und Einfügen aus der Zwischenablage funktioniert.

<label for="passwort">Passwort</label>
<input id="passwort" name="passwort" type="password"
       autocomplete="current-password">

<label for="code">Bestätigungscode aus der SMS</label>
<input id="code" name="code" inputmode="numeric"
       autocomplete="one-time-code">

Was das konkret bedeutet:

• Blockiere nie das Einfügen in Passwort- oder Code-Felder.
• Nutze current-password und new-password, damit Passwortmanager zuverlässig arbeiten.
• Teile Einmalcodes nicht auf sechs Einzelfelder auf, in die nichts eingefügt werden kann.
• Biete Alternativen wie Passkeys oder einen Anmeldelink per E-Mail an.
• Verzichte auf Text-CAPTCHAs mit verzerrten Zeichen. Bilderrätsel wie „Wähle alle Ampeln“ sind auf Stufe AA zwar zulässig, schließen aber blinde Menschen aus, wenn es keine Alternative gibt.

Eigene Formularelemente mit Bedacht

Native Elemente wie select, input type="checkbox" oder input type="date" sind nicht immer hübsch, bringen aber Tastaturbedienung, Fokus, Rolle und Zustand von Haus aus mit. Ein selbst gebautes Dropdown aus div-Elementen muss all das nachbauen: Pfeiltasten, Escape, Ansage des gewählten Werts, Verhalten auf Mobilgeräten. In der Praxis gelingt das selten vollständig.

Bevor du ein eigenes Element entwickelst, prüfe deshalb, ob sich das native per CSS ausreichend gestalten lässt. Checkboxen und Radiobuttons lassen sich heute gut mit accent-color oder appearance: none anpassen, ohne die Semantik aufzugeben. Brauchst du wirklich eine eigene Komponente, etwa eine Kombination aus Suchfeld und Vorschlagsliste, orientiere dich an den Mustern der WAI-ARIA Authoring Practices und teste sie mit Tastatur und Screenreader.

Checkliste

• Jedes Feld hat ein sichtbares, mit for und id verknüpftes Label.
• Pflichtfelder sind im Text gekennzeichnet und tragen required.
• Formatvorgaben stehen vor der Eingabe und sind mit aria-describedby verknüpft.
• Radiobuttons und Checkbox-Gruppen stecken in fieldset mit legend.
• Persönliche Daten haben passende autocomplete-Werte.
• Fehlermeldungen nennen Feld, Problem und Lösung, nicht nur Farbe.
• Nach dem Absenden landet der Fokus auf einer verlinkten Fehlerübersicht.
• Bereits eingegebene Daten werden nicht erneut abgefragt.
• Zeitlimits lassen sich verlängern.
• Der Login funktioniert mit Passwortmanager, Einfügen und ohne Rätsel.

Fazit

Barrierefreie Formulare sind keine Sonderanfertigung. Sie bestehen zum größten Teil aus HTML-Elementen, die es seit Jahrzehnten gibt: label, fieldset, legend, required und autocomplete. Dazu kommen gut formulierte Hinweise und Fehlermeldungen, die Menschen ernst nehmen, statt sie zu belehren.

Teste dein Formular am Ende einmal komplett ohne Maus, wie im Artikel zu Tastatur und Fokus beschrieben, und einmal mit Screenreader. Wie das in 15 Minuten gelingt, zeigt der Schnelltest mit Screenreader. Jedes Problem, das du dabei findest, ist ein Abbruch weniger.

Dieser Artikel informiert allgemein und ersetzt keine Rechtsberatung. Alle genannten Kriterien findest du ausführlich erklärt im WCAG-Guide.

Quellen

• W3C WAI: Forms Tutorial (öffnet in neuem Tab)
• W3C: Web Content Accessibility Guidelines (WCAG) 2.2 (öffnet in neuem Tab)
• W3C: WCAG 2.2, Input Purposes for User Interface Components (öffnet in neuem Tab)
• W3C: Understanding Success Criterion 3.3.8 Accessible Authentication (Minimum) (öffnet in neuem Tab)
• WebAIM: Creating Accessible Forms (öffnet in neuem Tab)