Formulare sind die Stelle, an der Ihre Website aufhört zu reden und anfängt zuzuhören: Kontaktanfragen, Bestellungen, Registrierungen, Suchen. Sie sind auch die Stelle, an der Barrierefreiheit am häufigsten scheitert. Die WebAIM-Million-Studie, die jedes Jahr die Startseiten der eine Million meistbesuchten Websites untersucht, findet regelmäßig auf fast der Hälfte davon fehlende Labels an Formularfeldern. Damit ist das einer der häufigsten Barrierefreiheitsfehler im Web. Das Frustrierende daran: Barrierefreie Formulare sind nicht schwer. Eine Handvoll korrekt eingesetzter HTML-Attribute entscheidet darüber, ob ein blinder Nutzer Ihnen eine Nachricht schicken kann oder stillschweigend aufgibt, und ob Ihr Formular die WCAG erfüllt, die der European Accessibility Act für viele Unternehmen zur Rechtspflicht gemacht hat. Diese Anleitung geht die fünf Punkte durch, auf die es ankommt, mit Markup zum Kopieren, und endet mit einem ehrlichen Blick auf WordPress-Formular-Plugins.
Warum sind Formulare das größte Problem der Barrierefreiheit?
Ein sehender Nutzer mit Maus liest ein Formular als visuelles Ganzes: Der Text neben einem Kasten gehört offensichtlich dazu, der rote Rahmen bedeutet offensichtlich einen Fehler. Assistive Technologie hat nichts von diesem Kontext. Ein Screenreader-Nutzer springt von Bedienelement zu Bedienelement und hört nur das, was das Markup ausdrücklich mit dem jeweiligen Feld verbindet. Fehlt diese Verbindung, hört der Nutzer Eingabefeld, leer, und muss raten, was das Feld will. Nutzer von Sprachsteuerung stehen vor demselben Problem: Klick E-Mail funktioniert nur, wenn das Feld programmatisch E-Mail heißt.
Das ist das Kernprinzip hinter jeder Regel in dieser Anleitung: Jede visuelle Beziehung in einem Formular muss auch im Markup existieren. Label zu Feld, Hinweis zu Feld, Fehler zu Feld, Gruppe zu Optionen. Die einschlägigen WCAG-Erfolgskriterien (1.3.1 Info and Relationships, 3.3.1 Error Identification, 3.3.2 Labels or Instructions) laufen alle auf diesen einen Gedanken hinaus.
Wie beschrifte ich Formularfelder korrekt?
Die Grundlage jedes barrierefreien Formulars ist das label-Element, das über das Attribut for mit der id seines Feldes verbunden ist:
<label for="email">E-Mail-Adresse</label>
<input type="email" id="email" name="email" autocomplete="email">
<!-- Zusätzlicher Hinweis, verbunden über aria-describedby -->
<label for="password">Passwort</label>
<input type="password" id="password" name="password" aria-describedby="password-hint">
<p id="password-hint">Mindestens zwölf Zeichen.</p>Das bringt Ihnen drei Dinge auf einmal: Screenreader sagen das Label an, sobald das Feld den Fokus bekommt, ein Klick auf das Label fokussiert das Feld (auf dem Smartphone eine größere Trefferfläche für alle), und Sprachsteuerung kann das Feld über seinen Namen ansprechen. Hinweise und Formatangaben gehören in ein eigenes Element, auf das aria-describedby verweist, damit sie nach dem Label angesagt werden, ohne es zu überladen. Das Attribut autocomplete ist ein stiller Bonus: Bei Feldern, die persönliche Daten erfassen, verlangt WCAG 1.3.5 es, und es erlaubt Browsern, das Feld korrekt auszufüllen, was vor allem Nutzern mit motorischen und kognitiven Einschränkungen hilft. Das Formular-Tutorial des W3C beschreibt jede Variante dieser Muster.
Warum ein Placeholder kein Label ist
Das Formularfeld, das nur einen Placeholder hat, ist der häufigste barrierefrei aussehende Fehler im Web. Es sieht aufgeräumt aus und scheitert gleich vierfach:
- Der Text verschwindet bei der Eingabe. Die Beschreibung ist genau dann weg, wenn der Nutzer mit dem Feld arbeitet. Wer schon einmal vergessen hat, was ein halb ausgefülltes Feld eigentlich wollte, kennt das Gefühl.
- Das übliche Grau erfüllt den Kontrast nicht. Typisches Placeholder-Styling erreicht das Kontrastverhältnis von 4,5:1 nicht, das die WCAG für Text verlangt.
- Die Unterstützung durch assistive Technologie ist uneinheitlich. Manche Kombinationen aus Screenreader und Browser sagen Placeholder an, andere nicht. Ein Label sagen sie alle an.
- Ausgefüllte Felder wirken leer, leere Felder wirken ausgefüllt. Wer überfliegt, was noch zu tun ist, versteht es genau falsch herum.
Als Ergänzung sind Placeholder in Ordnung, etwa als Formatbeispiel wie name@example.com in einem ordentlich beschrifteten Feld. Als einzige Beschreibung eines Feldes sind sie ein WCAG-3.3.2-Verstoß mit guter Typografie.
Wie kennzeichne ich Pflichtfelder barrierefrei?
Zwei Kanäle, immer gemeinsam. Der maschinelle Kanal ist das HTML-Attribut required, das Browser und Screenreader das Feld als Pflichtfeld ansagen lässt und die native Validierung aktiviert. Der menschliche Kanal ist sichtbarer Text: das Wort Pflichtfeld (oder sein Gegenteil, optional) im Label. Das beliebte rote Sternchen allein scheitert an beidem: Farbe darf nicht der einzige Informationsträger sein (WCAG 1.4.1), und wenn Sie die Sternchen-Konvention trotzdem nutzen, muss sie mindestens über dem Formular erklärt und ins Label aufgenommen werden, damit sie angesagt wird.
<label for="name">Name (Pflichtfeld)</label>
<input type="text" id="name" name="name" required>Eine pragmatische Umkehrung ergibt oft die saubersten Formulare: Wenn ohnehin fast jedes Feld Pflicht ist, kennzeichnen Sie nur die optionalen und schreiben Sie das über das Formular. Und das beste Pflichtfeld ist das, was Sie löschen; jedes Feld, das ein Formular nicht abfragt, kann auch nicht falsch ausgefüllt werden.
Wie mache ich Fehlermeldungen barrierefrei?
Bei der Fehlerbehandlung verlieren Formulare die Nutzer, die sie bis dahin noch nicht verloren haben. WCAG 3.3.1 verlangt, dass Fehler im Text erkannt und dem Nutzer beschrieben werden. Das robuste Muster pro Feld:
<label for="email">E-Mail-Adresse (Pflichtfeld)</label>
<input type="email" id="email" name="email" required
aria-invalid="true" aria-describedby="email-error">
<p id="email-error" class="error">
Bitte geben Sie eine E-Mail-Adresse ein, zum Beispiel name@example.com.
</p>Die Bestandteile: aria-invalid="true" markiert das Feld als fehlerhaft, sodass Screenreader beim Fokussieren eine ungültige Eingabe ansagen, die Meldung ist echter Text (kein bloßer roter Rahmen, kein bloßes Symbol) und ist über aria-describedby mit dem Feld verbunden, und die Formulierung sagt, wie das Problem zu beheben ist, nicht nur, dass es eines gibt. Fehler, bitte korrigieren hilft niemandem; Bitte geben Sie ein Datum im Format TT.MM.JJJJ ein dagegen schon.
Bei Validierung, die erst beim Absenden läuft, kommt ein weiterer Schritt dazu: Setzen Sie nach einem fehlgeschlagenen Absenden den Tastaturfokus auf das erste fehlerhafte Feld, oder rendern Sie oben eine Fehlerübersicht mit role="alert" und Links zu den betroffenen Feldern. Ein Screenreader-Nutzer, der absendet und nichts hört, geht davon aus, dass das Formular funktioniert hat. Stille nach einem gescheiterten Absenden ist der grausamste Formularfehler, den es gibt.
fieldset und legend: Radiobuttons und Checkboxen gruppieren
Radiobutton- und Checkbox-Gruppen haben eine zweistufige Struktur: Die Gruppe hat eine Frage, jede Option hat ein Label. Beide Ebenen müssen im Markup stehen, und die nativen Elemente für die Gruppenebene sind fieldset und legend:
<fieldset>
<legend>Bevorzugter Kontaktweg (Pflichtfeld)</legend>
<input type="radio" id="contact-email" name="contact" value="email">
<label for="contact-email">E-Mail</label>
<input type="radio" id="contact-phone" name="contact" value="phone">
<label for="contact-phone">Telefon</label>
</fieldset>Ohne das fieldset hört ein Screenreader-Nutzer, der in die Gruppe tabbt, nur E-Mail, Radiobutton, eins von zwei, und hat keine Ahnung, welche Frage die Optionen beantworten. Mit ihm wird die legend zuerst angesagt. Dieselbe Struktur trägt Checkbox-Gruppen und lohnt sich auch dann, wenn ein Designsystem die Elemente bis zur Unkenntlichkeit umgestaltet; die Semantik kostet nichts und trägt alles.
Sind WordPress-Formular-Plugins barrierefrei?
Meistens können sie es sein, und keines garantiert es. Das ehrliche Bild pro Plugin: Contact Form 7 rendert genau das, was Sie in seine Formularvorlage schreiben, Labels, fieldsets und Fehlerverdrahtung liegen also vollständig in Ihrer Hand; die Flexibilität, die es beliebt macht, macht es auch leicht, Formulare ohne Labels auszuliefern. Gravity Forms hat sein Markup vor einigen Jahren mit Barrierefreiheit als ausdrücklichem Ziel überarbeitet und liefert in aktuellen Versionen solide Ausgabe. WPForms hat ebenfalls in barrierefreie Voreinstellungen investiert. In jedem Fall können drei Dinge ein barrierefreies Plugin weiterhin kaputt machen: das Styling Ihres Themes (entfernte Fokusrahmen, zerstörte Kontraste), CAPTCHAs (eine komplett unzugängliche Hürde; Honeypot-Ansätze umgehen das Problem) und obendrauf gesetzte eigene Feldtypen.
Testen Sie also das gerenderte Ergebnis, nicht die Marketingseite. Die Zwei-Minuten-Variante: Ziehen Sie die Maus ab und füllen Sie das Formular allein mit der Tastatur aus, wobei Sie in jedem Schritt den Fokus sehen können müssen, und senden Sie es dann leer ab, um zu prüfen, ob die Fehlermeldungen angesagt und erreichbar sind. Automatisierte Testwerkzeuge wie WAVE erwischen die strukturelle Hälfte, darunter fehlende Labels, in Sekunden.
Wie InspectWP Ihnen hilft, Formularprobleme zu finden
Der Bericht von InspectWP untersucht Ihre gerenderte WordPress-Website so, wie ein Browser sie sieht, und mehrere Prüfungen betreffen unmittelbar Formulare. Er markiert Formulare, deren action an eine unsichere HTTP-Adresse sendet, ein Problem, das Browser mit Warnungen genau in dem Moment bestrafen, in dem ein Besucher Ihnen gleich Daten anvertrauen will. Darüber hinaus deckt der Bericht die Grundlagen der Barrierefreiheit rund um Ihre Formulare ab: Bilder ohne alt-Attribut, die Überschriften-Hierarchie, an der sich Screenreader-Nutzer entlanghangeln, und Konsolenfehler, die oft kaputte Validierungsskripte verraten. Ein kostenloser Bericht ist ein schneller erster Blick auf die Seite, auf der Ihr Formular sitzt.