Barrierefreie Formulare - Teil3: Validierung

Formulare sind oft das wichtigste Element einer Website. Ob Checkout, Newsletter-Registrierung oder Kontaktformular – ohne Formulare geht nichts. Deswegen ist Barrierefreiheit bei Formularen enorm wichtig. Wenn das Checkout-Formular nicht ausgefüllt werden kann, wird auch nichts verkauft. In diesem Artikel zeige ich euch, was ihr tun könnt, um so viele Nutzer*innen wie möglich abzuholen.

Der Artikel ist in drei Teile aufgeteilt. In Teil Eins geht es um den grundlegenden Aufbau von Barrierefreiheit in Formularen. In Teil Zwei beschäftigen wir uns damit, wie wir unsere Nutzer*innen beim Ausfüllen unterstützen können. Im diesem Teil, dem letzten Teil, lernen wir, wie Eingaben barrierefrei validiert werden können.

Validierung: Im Client oder auf dem Server?

Für Nutzer*innen ist es ideal, wenn ihre Eingaben direkt validiert werden. So können sie Fehler sofort korrigieren, solange sie noch im Kontext eines Formularfeldes unterwegs sind. In einer modernen Web-Anwendung ist das auch normalerweise kein Problem. Manche Dinge können allerdings erst nachgelagert nach dem Abschicken des Formulars validiert werden. Diesen Fall betrachten wir weiter unten im Artikel; zuerst schauen wir uns Client-seitige Validierung an.

Die WCAG legt sich nicht eindeutig dazu fest, wo validiert werden soll. In den relevanten Kriterien zur Fehlerbehandlung, WCAG 3.3.1 und WCAG 3.3.3 sind allerdings einige Techniken aufgelistet, die nahelegen, das Client-seitige Validierung präferiert wird.

Browser-Validierung

Browser bieten eine eingebaute Validierung an. Den folgenden Code-Schnipsel hatten wir im vorherigen Teil schon mal in ähnlicher Form:

1<span>Mit Stern (*) markierte Felder müssen ausgefüllt werden.</span>
2<form>
3     <label for="email">E-Mail*</label>
4     <input type="email" id="email" name="email" required aria-required="true"/>
5     <button type="submit">Abschicken</button>
6</form>

Durch die Verwendung des required-Attributs erhalten wir automatisch eine Validierung durch den Browser. Sie wird ausgelöst beim Absenden des Formulars und gibt uns eine Fehlermeldung in der eingestellten Browsersprache:

Darüber hinaus kann der Browser aber noch mehr: wir haben angegeben, dass das Feld vom Typ E-Mail ist. Das führt dazu, dass die Eingabe automatisch auf eine valide E-Mail-Adresse überprüft wird, wie im nächsten Screenshot zu sehen:

Entsprechende Validierungen existieren auch für andere Feldtypen. Für komplexere Anforderungen existiert das Attribut "pattern". Damit könnt ihr reguläre Ausdrücke hinterlegen, gegen die das Feld validiert wird. Der Nachteil an der Browser-Validierung ist, dass sie erst beim Klick auf den submit-Button ausgelöst wird. Außerdem gibt es keine Möglichkeit, die Fehlermeldung zu stylen: Sie sieht in jedem Browser unterschiedlich aus. In der Praxis geht man also häufig trotzdem hin und benutzt eine Javascript-Bibliothek für die Validierung.

Validierung mit Javascript

Mit Javascript kann die Validierung schon bei der Eingabe stattfinden. Üblicherweise wird ein invalides Feld in rot gestylt, auch mit einer Fehlermeldung in rot. Hierbei solltet ihr auf den Kontrast achten: in Teil 1 haben wir gelernt, dass der Kontrast von Text zum Hintergrund 4,5:1 betragen sollte (WCAG 1.4.3) – das gilt auch für Fehlermeldungen.

Um die Fehlermeldung auch semantisch kenntlich zu machen, sind noch einige ARIA-Attribute notwendig. Hier ein Code-Schnipsel, wie der invalide Zustand aussehen könnte (Styling ausgeklammert):

1<label for="email">E-Mail</label>
2<input type="email" id="email" name="email" autocomplete="email" aria-invalid="true" aria-describedby="email-error" aria-errormessage="email-error"/>
3<span id="email-error">Bitte geben Sie eine gültige E-Mail-Adresse an</span>

Mit dem Attribut aria-invalid kommunizieren wir, dass das Feld nicht valide ist. Die Attribute aria-describedby und aria-errormessage verweisen auf die Fehlermeldung. Es wird aktuell empfohlen, beide Attribute zu benutzen, um ein Maximum an Kompatibilität zu erreichen. Diese beiden Attribute sollten auch nur gesetzt werden, wenn das Feld invalide ist.

Serverseitige Validierung

Auch wenn nach dem Abschicken des Formulars Fehler auftreten, gibt es ein paar Best Practices um Nutzern zu helfen. Zunächst das Wichtigste: nur eine generelle Meldung „Fehler aufgetreten“ ist wenig hilfreich. Fehlermeldungen solltet ihr wie gehabt direkt am entsprechenden Feld anzeigen. Zusätzliche visuelle Hilfe kann eine Liste von Fehlern oberhalb des Formulars bieten, die alle Fehler auflistet.

Mittlerweile hat es sich auch eingebürgert, den Keyboardfokus in das erste Feld zu setzen, in dem ein Fehler aufgetreten ist. Das hilft den Nutzer*innen, schnell die richtige Stelle zu finden. Manche Nutzer*innen können auch nicht das komplette Formular auf einmal betrachten, weil sie eine starke Vergrößerung brauchen. Wenn ihr den Fokus nicht in ein invalides Feld setzt, müssen sie erstmal herumscrollen, um das fehlerhafte Feld zu finden. Solltet ihr trotzdem den Fokus nicht setzen wollen, ist für diese Nutzer*innen ein Hinweis auf den Fehler an oder neben dem Button zum Abschicken hilfreich.

Besonderheiten für Screenreader-Nutzer*innen

Wenn Fehlermeldungen dynamisch, ohne ein Reload der Seite, erscheinen, bekommen Screenreader-Nutzer*innen das nicht notwendigerweise mit. Denn der Screenreader lauscht nicht automatisch auf Veränderungen im Dokument. WCAG 4.1.3 besagt, dass auch solche, als „Statusmeldungen“ bezeichnete Änderungen, programmatisch deklariert werden müssen.

Praktisch umsetzen können wir das mit einer Live-Region. Mit Live-Regionen kann man Teile des Dokuments festlegen, die der Screenreader auf Änderungen beobachten soll. Der nächste Code-Schnipsel zeigt wie das bei einer Fehlermeldung aussehen kann:

1<label for="email">E-Mail</label>
2<input type="email" id="email" name="email" autocomplete="email" aria-invalid="true" aria-describedby="email-error" aria-errormessage="email-error"/>
3<div aria-live="assertive" aria-atomic="true">
4    <span id="email-error">Bitte geben Sie eine gültige E-Mail-Adresse an</span>
5</div>

Wir haben jetzt einen zusätzlichen Container um die Fehlermeldung. Das ist unsere Live-Region. Die bleibt immer stehen, auch im validen Fall, während die Fehlermeldung nur auftaucht, wenn die Eingabe invalide ist. Die beiden Attribute aria-live und aria-atomic sorgen dafür, dass jegliche Änderung im Container an Screenreader gemeldet wird. Der Wert für aria-live, assertive, bedeutet, dass die Nutzer sofort informiert werden, sobald sich etwas ändert. Es gibt auch noch den Wert polite: damit werden Änderungen erst kommuniziert, wenn der Screenreader gerade nichts anderes spricht. Mit aria-atomic=true stellen wir sicher, dass wir jegliche Änderung mitbekommen.

Um das Beispiel kurz zu halten, habe ich den Container mit der Live-Region direkt um die Fehlermeldung gemacht. In der Praxis würde ich eher das komplette Formular als Live-Region deklarieren. So bekommt der Nutzer jegliche Veränderung mit, auch wenn das Formular abgeschickt wurde.

Das Wichtige bei Live-Regionen: die Live-Region selber kann nicht dynamisch nachgeladen werden, und sollte beim initialen Laden der Seite schon vorhanden sein. Sonst funktioniert die Live-Region nicht. Es kann sein, dass der Screenreader, mit dem ihr testet, trotzdem Updates liefert, aber das ist längst nicht bei jedem Screenreader der Fall.

Fazit

Bei der barrierefreien Validierung kommt es vor allem darauf an, Nutzer*innen gut abzuholen. Fehlermeldungen solltet ihr gut sichtbar in die Nähe des Fehlers anzeigen. Bei Fehlern nach dem Abschicken des Formulars solltet ihr eure Nutzer*innen zur Fehlerquelle leiten. Für Screenreader-Nutzer*innen sind Live-Regionen wichtig um Fehlermeldungen und andere dynamische Änderungen mitzubekommen.

Wir sind jetzt am Ende unserer Artikelserie und ihr habt hoffentlich eine gute Übersicht gewonnen, was barrierefreie Formulare ausmacht. Viel mehr als eine Übersicht ist es auch nicht; das Thema ist so komplex, dass ich noch viel mehr darüber schreiben könnte. Falls ihr weiter einsteigen wollt, findet ihr hier noch eine kurze Liste von weiterführenden Links. Viel Spaß beim Entdecken!

• Forms Tutorial vom W3C
• Disabled buttons suck
• A definitive guide to sensible form validation
• What happened to text inputs? (video)
• Why are my live regions not working?