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-labeloderaria-labelledbysind 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.
