Barrierefreie Formulare: die sieben Punkte, an denen es scheitert

Das Wichtigste in Kürze

• Jedes Eingabefeld braucht eine programmatisch verknüpfte Beschriftung. Ein Platzhaltertext ist keine.
• Fehler müssen in Textform benannt werden – rote Rahmen allein genügen nicht (WCAG 1.4.1 und 3.3.1).
• Pflichtfelder werden nicht nur mit einem Sternchen markiert, sondern auch programmatisch (required).
• Nach dem Absenden muss der Fokus dorthin, wo die Meldung steht – sonst erfährt eine Vorlesesoftware nichts davon.
• autocomplete ist seit WCAG 2.1 ein eigenes Kriterium (1.3.5) und spart allen Tipparbeit.

Technische Anleitung, keine Rechtsberatung. Ein automatisierter Test deckt die maschinell prüfbaren Kriterien ab; ob eine Fehlermeldung verständlich ist, kann nur ein Mensch beurteilen.

1. Beschriftung: sichtbar und verknüpft

Der häufigste Fehler überhaupt: ein Feld, das nur durch seinen Platzhaltertext erklärt wird. Der Platzhalter verschwindet beim Tippen, hat oft zu wenig Kontrast und wird von manchen Vorlesesoftwares gar nicht angesagt.

Entscheidend ist die Verknüpfung: Das for des <label> muss auf die id des Feldes zeigen. Dann vergrößert das Label zugleich die anklickbare Fläche – ein Gewinn für alle, die auf dem Telefon mit dem Daumen zielen.

Wenn eine sichtbare Beschriftung aus gestalterischen Gründen nicht in Frage kommt, etwa bei einem Suchfeld mit Lupensymbol, ist aria-label die zweitbeste Lösung. Zweitbeste, weil sie nur der Software hilft, nicht dem Auge.

2. Pflichtfelder: nicht nur ein Sternchen

Ein Sternchen ist eine visuelle Konvention. Damit auch eine Vorlesesoftware weiß, dass ein Feld ausgefüllt werden muss, gehört required ins Markup:

Und erklären Sie das Sternchen einmal am Anfang des Formulars: „Mit * markierte Felder sind Pflichtfelder.“ Wer das Formular von unten nach oben mit der Tastatur durchgeht, hat die Legende sonst nie gesehen.

3. Fehlermeldungen: Text, nicht Farbe

Ein roter Rahmen um ein Feld sagt: Hier stimmt etwas nicht. Er sagt nicht, was. Und für Menschen mit einer Rot-Grün-Sehschwäche sagt er gar nichts. WCAG 3.3.1 verlangt, dass der Fehler in Textform benannt wird; WCAG 3.3.3 verlangt einen Hinweis, wie er zu beheben ist – soweit das möglich ist.

Drei Dinge stecken darin: die Verknüpfung über aria-describedby, die Auszeichnung des Fehlerzustands über aria-invalid und eine Meldung, die ein Beispiel enthält statt einer Regelbeschreibung.

4. Fokus: sichtbar und an der richtigen Stelle

Zwei Anforderungen, die oft zusammen scheitern.

Sichtbar: Der Fokusrahmen darf nicht entfernt werden. outline: none ohne Ersatz ist einer der wenigen Einzeiler, die eine ganze Website unbedienbar machen. Wer den Standardrahmen nicht mag, ersetzt ihn – etwa mit einem kräftigen eigenen:

An der richtigen Stelle: Wird ein Formular abgeschickt und die Seite lädt mit einer Fehlerliste neu, muss der Fokus zu dieser Liste. Sonst steht er wieder ganz oben, und eine Vorlesesoftware liest von vorn – ohne je zu erwähnen, dass etwas schiefging.

5. Zusammengehörendes gruppieren

Radiobuttons und Checkbox-Gruppen brauchen einen gemeinsamen Rahmen, sonst hört eine Vorlesesoftware nur „Option eins“ ohne die Frage dazu:

Dasselbe gilt für die Einwilligungs-Checkbox unter einem Kontaktformular: Sie braucht ein Label, das den Text vollständig enthält, nicht nur das Wort „Datenschutz“.

6. autocomplete: das unterschätzte Kriterium

WCAG 2.1 hat mit Kriterium 1.3.5 ein eigenes Erfolgskriterium für die Feldbestimmung eingeführt. Der Nutzen ist größer, als der technische Aufwand vermuten lässt: Browser und Passwortverwaltungen füllen Felder automatisch, Menschen mit motorischen Einschränkungen sparen jeden einzelnen Tastendruck, und die Fehlerquote sinkt für alle.

Die wichtigsten Werte für eine Bestellstrecke:

7. Zeitbegrenzungen und automatische Änderungen

Ein Warenkorb, der nach zehn Minuten verfällt, ist für viele Menschen eine harte Barriere: Wer mit einer Vorlesesoftware oder einer Kopfsteuerung arbeitet, braucht schlicht länger. WCAG 2.2.1 verlangt, dass sich solche Grenzen abschalten, verlängern oder anpassen lassen – mit engen Ausnahmen.

Verwandt und ebenso häufig: Formulare, die beim Ändern eines Feldes sofort etwas anderes tun – die Seite neu laden, den Fokus verschieben, den Versandpreis austauschen. WCAG 3.2.2 verlangt, dass eine Änderung des Kontexts nicht allein durch das Ausfüllen eines Feldes ausgelöst wird. Ein ausdrücklicher Knopf ist der sichere Weg.

Wie Sie es selbst prüfen – in zehn Minuten

1. Tastatur: Legen Sie die Maus weg. Kommen Sie mit Tabulator, Leertaste und Eingabetaste durch das ganze Formular? Sehen Sie jederzeit, wo Sie stehen?
2. Absenden mit leeren Feldern: Steht die Fehlermeldung in Textform da? Springt der Fokus dorthin?
3. Zoom auf 200 Prozent: Bleibt alles bedienbar, ohne dass etwas überlappt?
4. Beschriftung anklicken: Landet der Fokus im zugehörigen Feld? Wenn nicht, fehlt die Verknüpfung.

Diese vier Handgriffe finden die meisten der oben beschriebenen Fehler – ohne Werkzeug, ohne Vorkenntnisse. Was sie nicht finden, findet ein automatisierter Test: fehlende Verknüpfungen, unzureichende Kontraste, doppelte id-Werte, fehlerhafte ARIA-Auszeichnungen.

Häufige Fragen

Dieser Artikel ist eine technische Einordnung und keine Rechtsberatung. Quellen: WCAG 2.1, insbesondere die Erfolgskriterien 1.3.1, 1.3.5, 2.4.3, 2.4.6, 3.3.1, 3.3.2, 3.3.3, 3.3.4 und 4.1.2; EN 301 549; Barrierefreiheitsstärkungsgesetz (BFSG) § 19 und BFSGV. Eigene Messwerte aus 40 automatisiert geprüften Websites, August 2026.