Accessible Forms: Validation (Part 2)

Client-side Validation

Clientseitige Validierung ist kein Ersatz für serverseitige Validierung. Sie ist nur eine Ergänzung.

Inline validation versus validation on form submission

Inline Validation passiert live, während der User das Formular ausfüllt (während der Eingabe oder sobald das Eingabefeld verlassen wird). Validation on form submission passiert, wenn der User auf den Submit-Button klickt. Das Formular wird dann nochmal sozusagen abgefangen und mit JavaScript überprüft. Der Submit-Button sollte aber nicht deaktiviert werden! Das verursacht mehr Accessibility-Probleme als es löst!

Always aim for usability, not just conformance!

Statt den Submit-Button zu deaktivieren, sollte man ihn dazu nutzen, dem User mitzuteilen: Hey, da ist noch was zu tun!

  1. Lass den User das Formular absenden. Um zu verhindern, dass nicht korrekte Daten zum Server gesendet werden, verwende JavaScript, um das Absenden zu unterbrechen und mache eine clientseitige Validierung, bevor die Daten gesendet werden. Wenn kein JavaScript verfügbar ist, erlaube, dass die Daten zum Server gesendet werden.
  2. Wenn entweder client oder serverseitige Validierung Fehler im Formular gefunden haben:
    1. Benachrichtige auf eine klar ersichtliche Art und Weise den User, dass es Fehler im Formular gibt
    2. Stelle einen Weg zur Verfügung, wie er auf einfache Weise zu den Feldern springen kann, die eine Korrektur benötigen
    3. Zeichne die ungültigen Felder klar aus und stelle hilfreiche Error-Messages im Kontext des jeweiligen Feldes zur Verfügung.
  3. Lass den User das Formular wieder abschicken und validiere es erneut.

Den Benutzer über einen Fehler im Formular beim Abschicken benachrichtigen

Wenn das Formular abgeschickt wird:

  1. Stelle eine zusammenfassende Liste aller Elemente, die korrigiert werden müssen, zur Verfügung. Die Liste sollte eine deutliche Überschrift haben. Jeder Fehler sollte einen Link zum korrespondierenden, ungültigen Feld enthalten (siehe auch Technique für SC 3.3.1 und 3.3.3). Die Fehlermeldungen sollten wortgleich mit den inline Fehlermeldungen beim Eingabefeld sein.
  2. Stelle sicher, dass die Liste von Screenreadern vorgelesen wird, entweder
    1. indem der Fokus auf die Zusammenfassung gelegt wird (nicht jeder bekommt mit, dass eine Fehlerliste oberhalb des Formulars angezeigt wird weil entweder das Formular zu lang ist oder ein Page Zoom verwendet wird), oder
    2. die Zusammenfassung zu einer ARIA Live Region gemacht wird.
  3. Identifiziere die fehlerhaften Eingabefelder sowohl visuell (mit einer Farbe und einem visuellen Indikator wie einem Icon) als auch programmatisch(mit aria-invalid).
  4. Assoziiere jedes ungültige Feld mit einer inline Fehlermeldung, die den Fehler beschreibt und dem User erklärt, wie er sie fixen soll.

Live region oder Fokus setzen? Wenn das dynamisch hinzugefügte Element ein oder mehrere interaktive Felder enthält, sollte es keine Live Region sein. Fokus mit tabindex="-1" auf die gesamte Zusammenfassung oder auf die Überschrift setzen.
Mit tabindex="-1" wird ein Element programmatisch fokussierbar, aber nicht in die natürliche Tabreihenfolge der Seite eingefügt. Dann kann der Fokus mit der JavaScript .focus()-Methode auf dieses Element gelegt werden.
Alle interaktiven Elemente müssen einen accName haben (5. ARIA-Regel). Um dem <div<-Element einen accName zu geben, braucht es eine aussagekräftige ARIA-Role, die den Zweck beschreibt. Die group role ist eine passende Rolle für die Fehlerzusammenfassung. Die Überschrift der Zusammenfassung kann dafür mit aria-labelledby verwendet werden. Aufpassen, wohin der Fokus gelenkt wird: manche Screenreader lesen alle Punkte vor, das kann, je nach Menge, zuviel sein.

Fehlerzusammenfassung mit inline Fehlermeldungen ergänzen
Wenn es zu viele Fehlermeldungen gibt, dann kann man sich die nicht merken. Deswegen sollten inline Fehlermeldungen bei jedem ungültigen Feld ergänzt werden, in denen man die Fehlermeldung nochmal nachvollziehen kann. Das Input-Feld wird mit aria-describedby mit der zugehörigen inline Fehlermeldung verbunden. Wenn ein Feld zusätzliche Anweisungen hat (wie z.B. ein Passwortfeld), sollte die input-error-message den input-instructions vorangestellt werden.

Benutze den Seitentitel, wenn die Seite beim Abschicken des Formulars neu lädt
... und stelle 2 Fehler - Seitentitel an den Anfang, damit sichergestellt ist, dass der Screenreader-User die Fehler nicht überhört. Umgekehrt sollte auch eine Erfolgsmeldung an den Anfang des Seitentitels gestellt werden, wenn das Formular erfolgreich abgeschickt wurde.

Inline Validierung und Fehlermeldungen
Inline Validierung passiert, während der User die Input-Felder ausfüllt. Technisch gesehen passiert die Validierung entweder sobald der User anfängt zu schreiben (keypress) oder das Feld verlässt (blur). Inline Validierung gibt sofort oder fast sofort Rückmeldung bei oder in der Nähe der Formularfelder. Wenn Inputvalidierung richtig gemacht wird, kann sie die Usability verbessern. Wenn sie schlecht oder am falschen Ort implementiert wird, kann es in einer frustrierenden UX enden. Siehe auch Artikel von Luke Wroblevsky auf A List Apart.

In practice, even the most sophisticated inline validateion will be faulty at times. And when it fails, it fails big time.– Vitaly Friedman

Überlegungen zur Accessibility von Inline-Validierung
Wenn ein Feld validiert wird und eine Fehlermeldung anzeigt, während der User durch das Formular geht, muss der Screenreader benachrichtigt werden, sobald eine Fehlermeldung gezeigt wird, damit er die Nachricht dem Benutzer mitteilen kann. Jede Inline Fehlermeldung sollte daher eine ARIA Live Region werden.

Für jede Inline Fehlermeldung gilt:

  1. Erstelle einen leeren Container für die Nachricht und platziere sie im Markup.
    Theoretisch kann dieser Container auch mit JavaScript ins DOM eingefügt werden, aber es ist best practice, den Container vorher zu platzieren und die Fehlermeldung dann einzufügen, wenn ein Fehler erkannt wird.
  2. Zeichne den Container mit ARIA als Live Region aus
    Wenn der Fehler erkannt wird, befülle den Container mittels JavaScript mit der Fehlermeldung.
<label for="email">Your email address</label>
<input type="email" autocomplete="email" id="email"
  aria-required="true" aria-invalid="true"
  aria-describedby="email-error-message">
<p id="email-error-message"></p>

Auszeichnen einer Inline Fehlermeldung als ARIA Live Region
Der primäre Weg, ein Element als ARIA Live Region auszuzeichnen ist die Verwendung der aria-live-Eigenschaft.

<label for="email">Your email address</label>
<input type="email" autocomplete="email" id="email"
  aria-required="true" aria-invalid="true"
  aria-describedby="email-error-message">
<!-- this message is now an assertive live region -->
<p id="email-error-message" aria-live="assertive">
  <!-- Insert the contents of the error message here using JavaScript when an error is detectet. -->
</p>

Alternative:
role="alert" zeichnet eine Live Region mit wichtiger und üblicherweise zeitsensibler Information aus. Bei Elementen mit dieser Rolle wird implizit aria-live="assertive" gesetzt, was bedeutet, dass hier auch unmittelbar eine Meldung ausgegeben wird.
Der Unterschied zwischen einer ARIA Live Region und dem aria-live-Attribut alleine ist, dass die Live Regions semantische Bedeutung haben.

Die Benutzung einer Live Region garantiert nicht immer, dass die Nachricht wie beabsichtigt vorgelesen wird.

Ob die Fehlermeldungen vom Screenreader vorgelesen werden oder nicht, hängt ab vom Timing der Validierung, von den ARIA-Attributen und von der Browser- und Screenreader-Kombination, als auch von deren Konfiguration und Art der Navigation. Es ist besser, nicht direkt während der Eingabe zu validieren, sondern erst, nachdem der User das Feld verlassen hat und zum nächsten übergewechselt ist. Selbst dann kann es vorkommen, dass Benutzer eine Fehlermeldung verpassen. Mache immer eigene Tests!

Eine Fehlerzusammenfassung ist meistens mehr bulletproof als eine Inline Validierung.

Relevante Success Criteria

SC 2.1.1 Keyboard (Level A) – Regel 3
xxx

Links