Barrierefreie Formulare – Labels, Fehler & Bestätigung

Barrierefreie Formulare sind Web-Formulare, bei denen alle Eingabefelder programmatisch beschriftete Labels besitzen, Fehler in verständlichem Text (nicht nur farblich) angezeigt werden und Erfolgsmeldungen für assistive Technologien ankündigt werden – damit Screen Reader – Barrierefreiheit für blinde und sehbehinderte Nutzer-Nutzer und Tastaturnutzer jede Formularinteraktion fehlerfrei abschließen können.

Rubrik: Mediendesign & Digitale Medien · Unterrubrik: Accessibility · Niveau: Fortgeschritten

Warum sind barrierefreie Formulare wichtig?

Formulare sind die kritischste Interaktionsstelle im Web: Kontakt, Registrierung, Kaufabschluss, Buchung, Bewerbung – alle diese Aktionen erfordern die korrekte Eingabe in Formularfelder. Gleichzeitig sind Formulare eine der häufigsten Fehlerquellen in Accessibility-Audits: WebAIM's Million-Crawl (2024) stellte bei 56 % aller getesteten Webseiten fehlende oder fehlerhafte Formular-Labels fest.

Menschen, die von barrierefreien Formularen besonders abhängig sind: Blinde und sehbehinderte Nutzer (Screen Reader – Barrierefreiheit für blinde und sehbehinderte Nutzer), Nutzer mit motorischen Einschränkungen (Tastaturnavigation & Fokus-Management), Nutzer mit kognitiven Einschränkungen (klare Fehlermeldungen).

Erklärung

1. Labels: Jedes Feld braucht ein Label

Die grundlegendste Anforderung: Jedes Eingabefeld muss ein programmatisch verknüpftes Label haben. WCAG Kriterium 1.3.1 (Info and Relationships, Stufe A) und 3.3.2 (Labels or Instructions, Stufe A) fordern dies.

Empfohlene Methode: Explizites `<label>`-Element mit `for`-Attribut:

``html <label for="name">Ihr Name *</label> <input type="text" id="name" name="name" required aria-required="true"> ``

Auch korrekt: Label mit eingeschachteltem Input:

``html <label> Ihr Name * <input type="text" name="name"> </label> ``

Nicht ausreichend:

• Nur Placeholder-Text ohne Label: <input placeholder="Ihr Name"> – Placeholder verschwindet bei Eingabe, erfüllt kein Label.
• Rein visuelles Label ohne programmatische Verknüpfung (z. B. benachbarter <p>-Text).
• aria-label oder aria-labelledby sind technisch korrekte Alternativen (vgl. ARIA-Labels – Zugängliche Rich Internet Applications), aber sichtbare Labels sind für kognitive Accessibility vorzuziehen.

2. Pflichtfelder kennzeichnen

Pflichtfelder müssen sowohl visuell als auch programmatisch gekennzeichnet sein:

``html <label for="email">E-Mail-Adresse <span aria-hidden="true">*</span></label> <input type="email" id="email" required aria-required="true"> <p id="required-note">* Pflichtfeld</p> ``

Das *-Symbol wird via aria-hidden="true" ausgeblendet, damit Screen Reader nicht „Sternchen" vorlesen. Das aria-required="true" kommuniziert die Pflichtfeld-Eigenschaft an Screen Reader. Eine Legende erklärt die Bedeutung des Sternchens.

Pflichtfelder dürfen nicht ausschließlich durch Farbe (z. B. roten Rahmen) gekennzeichnet sein – vgl. Design für Farbenblinde – Typen, Auswirkungen & Tools und Farbkontrast & Accessibility – AA vs. AAA-Standards.

3. Eingabehinweise und Feldformat

Bei Feldern mit spezifischen Eingabeformaten (Datum, Telefonnummer, Passwortregeln) müssen Hinweise vor oder während der Eingabe sichtbar und für Screen Reader zugänglich sein:

``html <label for="phone">Telefonnummer</label> <input type="tel" id="phone" aria-describedby="phone-hint"> <p id="phone-hint" class="field-hint">Format: 030 12345678 (inkl. Vorwahl)</p> ``

Der aria-describedby-Link verbindet Feld und Hinweis für Screen Reader (vgl. ARIA-Labels – Zugängliche Rich Internet Applications).

4. Fehlermeldungen: Klar, textuell, kontextnah

WCAG Kriterium 3.3.1 (Error Identification, Stufe A) und 3.3.3 (Error Suggestion, Stufe AA) fordern:

• Fehler müssen im Text beschrieben sein (nicht nur farblich).
• Fehlermeldungen müssen das spezifische Problem benennen und möglichst einen Korrekturvorschlag geben.

Schlechtes Beispiel:

``html <input type="email" class="error"> <!-- nur roter Rand --> <p class="error-msg">Ungültige Eingabe</p> ``

Gut:

``html <input type="email" id="email" aria-describedby="email-error" aria-invalid="true"> <p id="email-error" role="alert"> Bitte geben Sie eine gültige E-Mail-Adresse ein (z. B. name@beispiel.de). </p> ``

aria-invalid="true" signalisiert Screen Readern den Fehlerzustand. role="alert" (oder aria-live="assertive") stellt sicher, dass die Fehlermeldung sofort vorgelesen wird.

Fehlermeldungen sollen:

• Das betroffene Feld benennen
• Das Problem beschreiben
• Einen Korrekturweg zeigen (wenn möglich)
• In der Nähe des Feldes platziert sein

Bei mehreren Fehlern nach Absenden: Eine Fehler-Zusammenfassung am Formularanfang mit Links zu den betroffenen Feldern ist Best Practice (WCAG 3.3.3).

5. Bestätigung und Erfolgsmeldungen

Nach erfolgreichem Absenden muss eine Erfolgsmeldung programmatisch angekündigt werden:

``html <div role="status" aria-live="polite" id="success-message"> Ihre Anfrage wurde erfolgreich gesendet. Wir melden uns innerhalb von 2 Werktagen. </div> ``

role="status" mit aria-live="polite" stellt sicher, dass Screen Reader die Meldung vorlesen, sobald der aktuelle Sprachfluss abbricht.

Alternativ: Fokus nach dem Absenden auf die Erfolgsmeldung setzen (successMessage.focus()).

6. Barrierefreie Select-Elemente und Checkboxen

Select-Dropdowns: Native <select>-Elemente sind am zugänglichsten. Benutzerdefinierte Dropdowns erfordern vollständige ARIA-Labels – Zugängliche Rich Internet Applications-Implementierung (role="combobox" / role="listbox").

Checkboxen und Radiobuttons: Native HTML-Inputs sind vorzuziehen. Müssen in <fieldset> + <legend> gruppiert werden, wenn sie thematisch zusammengehören:

``html <fieldset> <legend>Newsletter abonnieren</legend> <label><input type="checkbox" name="nl-design"> Design</label> <label><input type="checkbox" name="nl-tech"> Technologie</label> </fieldset> ``

7. Barrierefreie Authentifizierung (WCAG 2.2 neu)

WCAG 2.2 fügte das Kriterium 3.3.8 (Accessible Authentication, Stufe AA) hinzu: Authentifizierungsprozesse dürfen keine Gedächtnis- oder Schreibtests erfordern, die nicht durch alternative Methoden ersetzt werden können. CAPTCHA-Puzzles, die ausschließlich auf visuellem Erkennen basieren, verstoßen dagegen. Lösungen: Text-CAPTCHAs, Audio-CAPTCHA-Alternativen, Honeypot-Verfahren oder reCAPTCHA v3 (unsichtbar).

Beispiele

Vollständiges barrierefreies Formularfeld:

``html <div class="field"> <label for="username"> Benutzername <span aria-hidden="true">*</span> </label> <input type="text" id="username" name="username" required aria-required="true" aria-describedby="username-hint username-error" autocomplete="username" > <p id="username-hint" class="hint">Mindestens 4 Zeichen.</p> <p id="username-error" class="error" role="alert" hidden> Bitte geben Sie einen Benutzernamen mit mindestens 4 Zeichen ein. </p> </div> ``

In der Praxis

Im Design-System sollten Formularkomponenten als fertige, barrierefreie Bausteine definiert werden: Text-Input, E-Mail-Input, Password-Input, Select, Checkbox, Radiobutton, Textarea. Jede Komponente mit Label, Hint, Error-State und Success-State.

Vergleich & Abgrenzung

Accessible Forms vs. gutes UX-Design für Formulare: Barrierefreiheit und gutes Formular-UX sind in den meisten Punkten identisch: Klare Labels, hilfrei Fehlermeldungen und Bestätigungen verbessern die Nutzungserfahrung aller.

HTML-Formulare vs. [Barrierefreie PDFs – Tagging, Struktur & Standards](/wiki/mediendesign-digitale-medien/accessibility/barrierefreiheit-pdf/)-Formulare: PDF-Formulare haben grundlegende Accessibility-Einschränkungen. HTML-Formulare sind für digitale Transaktionen grundsätzlich vorzuziehen.

Häufige Fragen (FAQ)

Ist ein Placeholder ein ausreichendes Label? Nein. Placeholder-Text ist kein Ersatz für Labels. Er verschwindet beim Tippen, hat oft unzureichenden Farbkontrast & Accessibility – AA vs. AAA-Standards und wird nicht von allen Screen Readern konsistent behandelt.

Müssen Fehlermeldungen sofort oder erst nach dem Absenden angezeigt werden? Beides ist möglich. Inline-Validierung nach dem Verlassen eines Feldes (blur) ist für Accessibility geeignet, wenn sie nicht zu früh ausgelöst wird. Wichtig: Fehler dürfen kein Feld erst beim Fokussieren für ungültig erklären.

Verwandte Einträge

• WCAG – Web Content Accessibility Guidelines im Überblick
• ARIA-Labels – Zugängliche Rich Internet Applications
• Tastaturnavigation & Fokus-Management
• Screen Reader – Barrierefreiheit für blinde und sehbehinderte Nutzer
• Farbkontrast & Accessibility – AA vs. AAA-Standards
• Design für Farbenblinde – Typen, Auswirkungen & Tools
• Accessibility Testing – Tools & Methoden (axe, WAVE, Lighthouse)

Weiterführend

• W3C WAI: Forms Tutorial. 2019.
• W3C WAI: Understanding WCAG 3.3.1: Error Identification. 2023.
• WebAIM: Creating Accessible Forms. 2023.
• WebAIM: The WebAIM Million 2024 – Annual Accessibility Analysis of the Top 1,000,000 Home Pages. WebAIM, 2024.
• Krug, Steve: Don't Make Me Think, Revisited: A Common Sense Approach to Web Usability. 3. Aufl., New Riders, 2014.