Barrierefreie Formularvalidierung und Fehlermeldungen

Checkout- und Registrierungsformulare sind die Stellen, an denen Shops Kunden verlieren, und die Fehlerbehandlung ist der Punkt, an dem Formulare Menschen mit Screenreader, Vergrößerung oder Tastatur am häufigsten im Stich lassen. Die Regel ist einfach: Sagen Sie, was falsch ist, in Text, neben dem Feld, und sorgen Sie dafür, dass assistive Technologien es hören. Diese Seite gehört zur Reihe barrierefreie UI-Muster.

Relevante WCAG-Kriterien

• 3.3.1 Fehlererkennung (A): „das fehlerhafte Element wird gekennzeichnet und der Fehler dem Nutzer in Text beschrieben“. Das W3C ergänzt, Farbe dürfe verwendet werden, aber nur zusätzlich zum Text.
• 3.3.3 Fehlerempfehlung (AA): Wird ein Fehler automatisch erkannt und ist eine Korrektur bekannt, schlagen Sie sie vor, es sei denn, das würde die Sicherheit oder den Zweck des Inhalts gefährden. „Die E-Mail-Adresse ist ungültig“ erfüllt 3.3.1; „Geben Sie eine E-Mail-Adresse im Format [email protected] ein“ erfüllt auch 3.3.3.
• 3.3.2 Beschriftungen oder Anweisungen (A): Sagen Sie vorab, was erforderlich ist und in welchem Format.
• 4.1.3 Statusmeldungen (AA): Das eigene Beispiel des W3C ist der Text „5 Fehler auf der Seite“, der einem Formular hinzugefügt wird, ohne den Fokus zu bewegen – er muss angesagt werden. Eine Meldung, die den Fokus erhält, ist ein Kontextwechsel und keine Statusmeldung.
• 3.3.4 Fehlervermeidung (rechtliche, finanzielle, Daten) (AA): Bestellungen müssen rückgängig zu machen sein oder vor dem endgültigen Abschluss geprüft oder bestätigt werden.
• 1.4.1 Benutzung von Farbe (A), 1.4.3 Kontrast (Minimum) (AA): Roter Text auf Weiß muss weiterhin 4,5:1 erreichen.
• 3.3.7 Redundante Eingabe (A): Verlangen Sie nach einem Fehler nicht, Daten erneut einzugeben, die der Nutzer schon angegeben hat.

Codebeispiel

<form novalidate>
  <div id="error-summary" tabindex="-1" aria-labelledby="error-summary-title" hidden>
    <h2 id="error-summary-title">2 Fehler im Formular</h2>
    <ul>
      <li><a href="#email">E-Mail: Geben Sie eine Adresse im Format [email protected] ein</a></li>
      <li><a href="#postcode">Postleitzahl: Geben Sie sie im Format 10115 ein</a></li>
    </ul>
  </div>

  <label for="email">E-Mail</label>
  <input id="email" type="email" autocomplete="email"
         aria-invalid="true" aria-describedby="email-error">
  <p id="email-error" class="error">
    <span aria-hidden="true">⚠</span> Geben Sie eine Adresse im Format [email protected] ein
  </p>

  <label for="postcode">Postleitzahl <span class="hint" id="postcode-hint">(zum Beispiel 10115)</span></label>
  <input id="postcode" autocomplete="postal-code"
         aria-invalid="true" aria-describedby="postcode-hint postcode-error">
  <p id="postcode-error" class="error">Geben Sie die Postleitzahl im Format 10115 ein</p>

  <button type="submit">Weiter zur Zahlung</button>
</form>

So funktioniert es:

• Text, neben dem Feld. Jede Meldung ist sichtbarer Text, per aria-describedby verbunden, sodass sie mit dem Feld vorgelesen wird. aria-invalid="true" kennzeichnet das Feld als ungültig – W3C-Technik ARIA21 „Using aria-invalid to Indicate An Error Field“.
• Fehlerübersicht beim Absenden. Zeigen Sie oben eine Übersicht mit Links zu den Feldern und setzen Sie den Fokus darauf (sie hat tabindex="-1", damit sie den Fokus erhalten kann), oder setzen Sie den Fokus auf das erste ungültige Feld. Bewegen Sie den Fokus nicht, geben Sie die Fehler stattdessen über eine Live-Region aus – W3C-Technik ARIA19, „Using ARIA role=alert or Live Regions to Identify Errors“. Tun Sie nicht beides, sonst wird die Meldung doppelt vorgelesen.
• Inline-Validierung beim Tippen sollte zurückhaltend sein: Validieren Sie, wenn der Nutzer das Feld verlässt, nicht bei jedem Tastendruck, und entfernen Sie den Fehler, sobald er behoben ist.
• Behalten Sie die Daten. Behalten Sie nach einem fehlgeschlagenen Absenden alles, was der Nutzer eingegeben hat.
• Die native Browser-Validierung (required, type="email") funktioniert ebenfalls, aber ihre Meldungen und ihr Aussehen unterscheiden sich je nach Browser und Sprache; viele Shops nutzen novalidate und eigene Meldungen in der Sprache der Seite.

Tastatur- und Fokusverhalten

Typische Fehler in Online-Shops

• Nur ein roter Rahmen um das ungültige Feld oder ein rotes Sternchen ohne Text.
• Fehler als Toast am oberen Bildschirmrand, der nach drei Sekunden verschwindet und nie angesagt wird.
• Allgemeine Meldungen – „Ungültige Eingabe“, „Fehler“ – ohne Hinweis, welches Format erwartet wird.
• Platzhalter als einzige Beschriftung und Formathinweis, der verschwindet, sobald der Nutzer tippt.
• Meldungen, die nicht mit Feldern verknüpft sind, sodass Screenreader-Nutzer die Beschriftung hören und sonst nichts.
• Absende-Button deaktiviert, bis das Formular gültig ist, was das Problem verbirgt, statt es zu erklären; siehe deaktivierte Buttons.
• iFrames von Zahlungsanbietern mit eigenen unbeschrifteten Feldern und nur englischen Fehlern in einem lokalisierten Shop.
• Das Formular wird nach einem serverseitigen Fehler geleert, einschließlich der Lieferadresse.

Was automatische Prüfungen finden und was manuell zu testen ist

Alle sind Karten in unserer Regelbibliothek. Die automatische Prüfung sieht das Formular in seinem Ausgangszustand; sie sendet es nicht ab. Testen Sie manuell: Senden Sie leer und mit falschen Werten ab und prüfen Sie, dass jeder Fehler in Text beschrieben, mit seinem Feld verknüpft, von einem Screenreader angesagt und bei 200 % Zoom lesbar ist. Mit der Browser-Erweiterung können Sie die automatischen Regeln erneut ausführen, während die Fehler auf dem Bildschirm stehen. Die Schritte stehen unter WCAG testen.

Starten Sie die kostenlose Prüfung einer Seite auf Ihrem Checkout oder Ihrer Kontaktseite. Sie ist eine automatische Prüfung, kein vollständiges Audit.

Häufige Fragen

Was verlangen die WCAG bei Formularfehlern?

3.3.1 Fehlererkennung (A): Das fehlerhafte Feld wird gekennzeichnet und der Fehler in Text beschrieben. 3.3.3 Fehlerempfehlung (AA): Ist eine Korrektur bekannt, wird sie vorgeschlagen. 4.1.3 Statusmeldungen (AA): Meldungen, die ohne Fokuswechsel erscheinen, werden von assistiven Technologien angesagt.

Reicht ein roter Rahmen, um einen Fehler zu zeigen?

Nein. Das W3C sagt, Farbe darf zusätzlich verwendet werden, aber der Fehler muss auch in Text gekennzeichnet sein. Ein roter Rahmen allein schließt Menschen aus, die Farbe nicht sehen, und Screenreader-Nutzer.

Wie verbinde ich eine Fehlermeldung mit einem Feld?

Geben Sie der Meldung eine id, verweisen Sie vom Eingabefeld per aria-describedby darauf und setzen Sie aria-invalid="true" am Feld (W3C-Technik ARIA21). Der Screenreader liest dann die Beschriftung, den ungültigen Zustand und die Meldung vor.

Sollte der Fokus zum ersten Fehler springen?

Beim Absenden ist es ein gängiger und robuster Ansatz, den Fokus auf eine Fehlerübersicht oder das erste ungültige Feld zu setzen. Springt der Fokus nicht, muss eine Meldung wie „3 Fehler im Formular“ eine Statusmeldung sein, damit sie angesagt wird.

Kann eine automatische Prüfung Formularfehler testen?

Sie prüft das Formular im Ausgangszustand: Labels, autocomplete-Werte, gültige ARIA-Verweise und Kontrast. Sie sendet keine Formulare ab; ob Fehler erscheinen, in Text beschrieben und angesagt werden, muss daher manuell getestet werden.

Quellen

• W3C, Understanding 3.3.1 Error Identification: https://www.w3.org/WAI/WCAG22/Understanding/error-identification.html
• W3C, Understanding 3.3.3 Error Suggestion: https://www.w3.org/WAI/WCAG22/Understanding/error-suggestion.html
• W3C, Understanding 4.1.3 Status Messages: https://www.w3.org/WAI/WCAG22/Understanding/status-messages.html