Barrierefreie Fehlermeldungen im Formular: erkennen, beschreiben, korrigieren

Was barrierefreie Fehlermeldungen im Formular leisten müssen (WCAG 3.3.1)

Das Erfolgskriterium 3.3.1 „Fehlererkennung“ (Error Identification) greift, wenn ein Eingabefehler automatisch erkannt wird: Das fehlerhafte Element muss benannt und der Fehler dem Nutzer als Text beschrieben werden. Das Ziel laut W3C: Nutzer wissen, dass ein Fehler vorliegt und was falsch ist.

Das W3C nennt unter anderem zwei Fälle von Eingabefehlern: Angaben, die die Seite verlangt, die der Nutzer aber weggelassen hat, und Angaben, die außerhalb des geforderten Datenformats oder der zulässigen Werte liegen. Die Beispiele sind konkret: eine falsche Abkürzung für einen Bundesstaat, eine Provinz oder Region, eine nicht existierende Postleitzahl, ein Geburtsdatum zwei Jahre in der Zukunft, Buchstaben oder Klammern in einem Telefonfeld, das nur Ziffern akzeptiert, oder ein Gebot unter dem vorherigen Gebot.

Ein oft übersehener Fall: Ändert die Seite einen zu hohen oder zu niedrigen Wert automatisch so, dass er im zulässigen Bereich liegt, muss der Fehler dem Nutzer trotzdem beschrieben werden. Eine Meldung, die über den geänderten Wert informiert, erfüllt sowohl 3.3.1 als auch 3.3.3.

Farbe, ein Symbol oder ein Bild sind erlaubt, aber nur zusätzlich zum Text. Auch den Ort schreibt das Kriterium nicht vor: eine Fehlerliste am Anfang des Formulars, Meldungen direkt neben jedem Feld, ein Alert oder ein Dialog. Einzige Anforderung ist, dass Fehler als Text oder Textalternative dargestellt werden.

• Das fehlerhafte Feld in der Meldung nennen (zum Beispiel „E-Mail-Adresse“).
• Die Art des Fehlers beschreiben: leeres Pflichtfeld, falsches Format, Wert nicht in der Liste.
• Sich nie allein auf rote Farbe oder ein Symbol verlassen.
• Auch automatische Korrekturen der Seite melden.

Korrektur vorschlagen: Erfolgskriterium 3.3.3

Das Erfolgskriterium 3.3.3 „Korrekturvorschläge“ (Error Suggestion, Stufe AA) geht weiter: Wird ein Eingabefehler automatisch erkannt und sind Korrekturvorschläge bekannt, müssen sie dem Nutzer angeboten werden, es sei denn, dies würde die Sicherheit oder den Zweck des Inhalts gefährden. Das W3C weist darauf hin, dass das Wissen um einen Fehler nicht immer genügt: Menschen mit kognitiven Einschränkungen fällt es unter Umständen schwer zu verstehen, wie sie ihn beheben, und wer unsicher ist, bricht das Formular womöglich ab.

Das Formulierungsbeispiel des W3C taugt als Vorlage. „Email is not valid“ (die E-Mail ist ungültig) erfüllt 3.3.1. „Please provide a valid email address in the format [email protected]“ (bitte geben Sie eine gültige E-Mail-Adresse im Format [email protected] an) sagt zusätzlich, wie man den Fehler behebt, und erfüllt beide Kriterien.

Ein weiteres Beispiel aus der Dokumentation: Ein Feld erwartet einen Monatsnamen, der Nutzer tippt „12“. Die Korrektur kann eine Liste der zulässigen Werte sein („Wählen Sie: Januar, Februar … Dezember“) oder eine Deutung der Eingabe („Meinten Sie Dezember?“). Außerdem beschreibt das W3C ein nicht erfolgreich abgeschicktes Formular, das den Fehler an Ort und Stelle anzeigt, zusammen mit der korrekten Eingabe und zusätzlicher Hilfe zum Feld.

• Erwartetes Format: ein konkretes Beispiel geben ([email protected], TT/MM/JJJJ).
• Geschlossene Liste: die zulässigen Werte nennen oder den wahrscheinlichsten vorschlagen.
• Ausnahme: nichts vorschlagen, was die Sicherheit oder den Zweck des Inhalts gefährden würde.

Fehler vermeiden mit Beschriftungen und Anleitungen (3.3.2)

Die beste Fehlermeldung ist die, die nie erscheint. Das Erfolgskriterium 3.3.2 „Beschriftungen oder Anweisungen“ (Labels or Instructions, Stufe A) verlangt Beschriftungen oder Anleitungen, wenn der Inhalt eine Nutzereingabe erfordert. „Erfordert“ meint nicht nur Pflichtfelder: Das Kriterium gilt für alle Felder, ob Pflicht oder optional. Es gilt nicht für Links oder andere Bedienelemente ohne Bezug zur Dateneingabe, etwa ein Auf-/Zuklapp-Widget.

Bei Optionsfeldern, Kontrollkästchen und Comboboxen braucht jede Auswahlmöglichkeit eine eigene Beschriftung. Reichen die Beschriftungen der Optionen aus, um den Zweck der Gruppe zu vermitteln, ist eine sichtbare Beschriftung für die Gruppe unter Umständen nicht nötig; andernfalls braucht die Gruppe eine Beschriftung, eine Legende oder Anleitungen. Anleitungen können das erwartete Format angeben, besonders wenn es unüblich ist oder besonderen Regeln für eine korrekte Eingabe folgt. Das W3C warnt auch vor zu viel des Guten: Zu viele Informationen können genauso schaden wie zu wenige. Anleitungen dürfen erst erscheinen, wenn das Feld den Fokus hat, oder, besonders bei längeren Texten, über einen Link erreichbar sein.

Achten Sie auf den Geltungsbereich: 3.3.2 verlangt nicht, dass die Beschriftung korrekt ausgezeichnet und mit dem Feld verknüpft ist; das regelt 1.3.1. Umgekehrt kann ein Feld über aria-label einen zugänglichen Namen haben und 4.1.2 erfüllen, aber an 3.3.2 scheitern, wenn die Beschriftung nur Nutzern assistiver Technologien präsentiert wird. Ob eine Beschriftung klar ist, regelt 2.4.6.

• Ein Datumsfeld mit dem erwarteten Format als Text (TT/MM/JJJJ oder MM/TT/JJJJ).
• Ein Feld für den Benutzernamen mit den Regeln zu zulässigen Zeichen.
• Zwei Felder „Vorname“ und „Nachname“ statt einer einzigen Beschriftung „Name“ für beide.
• Ein Suchfeld, dessen Lupensymbol als sichtbare Beschriftung dient.

<!-- Verknüpfte Beschriftung (H44), Pflichtfeld in der Beschriftung angegeben (H90)
     und erwartetes Format mit Beispiel (G89) -->
<label for="geburtsdatum">Geburtsdatum (Pflichtfeld)</label>
<p id="geburtsdatum-hint">Erwartetes Format: TT/MM/JJJJ, zum Beispiel 14/07/1990</p>
<input type="text" id="geburtsdatum" name="geburtsdatum"
       aria-describedby="geburtsdatum-hint" aria-required="true">

<!-- Feldgruppe: fieldset und legend (H71),
     mit sichtbarer Beschriftung für jedes Teilfeld (H44) -->
<fieldset>
  <legend>Adresse</legend>
  <label for="plz">Postleitzahl</label>
  <input type="text" id="plz" name="plz">
  <label for="ort">Ort</label>
  <input type="text" id="ort" name="ort">
</fieldset>

Fehler für Screenreader ankündigen: die Techniken des W3C

Das Kriterium 3.3.1 verlangt keine programmatisch ermittelbaren Informationen: Ein Text oder eine Textalternative, die das Feld benennt und den Fehler beschreibt, genügt. Das W3C merkt jedoch an, dass die Fehlerkennzeichnung mit Informationen kombiniert werden kann, die Browser und assistive Technologien nutzen können; dieser Aspekt kann unter andere Kriterien wie 4.1.2 „Name, Rolle, Wert“ (Name, Role, Value) fallen. Zu den hinreichenden Techniken für 3.3.1, nach Situation geordnet, gehören ARIA21 „aria-invalid zur Kennzeichnung eines fehlerhaften Feldes verwenden“ für nicht ausgefüllte Pflichtfelder sowie ARIA19 „ARIA role=alert oder Live-Regionen zur Fehlerkennzeichnung verwenden“, ARIA18 „aria-alertdialog zur Fehlerkennzeichnung verwenden“ und SCR32 „Clientseitige Validierung mit Hinzufügen des Fehlertextes über das DOM“ für Eingaben außerhalb des geforderten Formats oder der zulässigen Werte.

Eine mögliche Umsetzung kombiniert eine per aria-describedby mit dem Feld verknüpfte Meldung, ein aria-invalid-Attribut am fehlerhaften Feld und eine Zusammenfassung in einem Bereich mit role="alert". Als empfohlene Techniken nennt das W3C außerdem G139 „Einen Mechanismus schaffen, mit dem Nutzer direkt zu den Fehlern springen können“, umsetzbar über Links zu jedem Feld in der Zusammenfassung, und G199 „Erfolgsrückmeldung geben, wenn Daten erfolgreich übermittelt wurden“.

<form id="signup" novalidate>
  <div id="error-summary" role="alert"></div>

  <label for="email">E-Mail-Adresse (Pflichtfeld)</label>
  <input type="email" id="email" name="email" aria-describedby="email-error">
  <p id="email-error" hidden></p>

  <button type="submit">Konto erstellen</button>
</form>

<script>
  const form = document.getElementById('signup');
  form.addEventListener('submit', (e) => {
    const field = document.getElementById('email');
    const msg = document.getElementById('email-error');
    const summary = document.getElementById('error-summary');
    // Vor jeder Prüfung zurücksetzen
    msg.textContent = '';
    msg.hidden = true;
    summary.innerHTML = '';
    field.removeAttribute('aria-invalid');

    let error = '';
    if (!field.value.trim()) {
      error = 'E-Mail-Adresse: Dieses Feld ist ein Pflichtfeld.';
    } else if (!/^[^@\s]+@[^@\s]+\.[^@\s]+$/.test(field.value)) {
      error = 'E-Mail-Adresse: ungültiges Format. Geben Sie eine Adresse im Format [email protected] ein.';
    }
    if (error) {
      e.preventDefault();
      msg.textContent = error;
      msg.hidden = false;
      field.setAttribute('aria-invalid', 'true');
      summary.innerHTML = '<p>1 Fehler: <a href="#email">E-Mail-Adresse</a></p>';
    }
  });
</script>

Reicht die native HTML-Validierung?

Bei nativer HTML-Validierung (Attribute wie required oder type="email") verhindert der Browser das Absenden eines unvollständigen oder ungültigen Formulars und zeigt eine allgemeine Meldung an. In der Regel setzt er den Fokus zurück auf das erste fehlerhafte Feld, und bei den meisten gängigen Kombinationen aus Browser und Screenreader kündigt der Screenreader die Fehlermeldung und den programmatischen Namen des Feldes an. Das W3C sieht damit das Kriterium 3.3.1 als erfüllt an.

Dennoch listet das W3C mehrere Nachteile auf und betont, dass Entwickler sorgfältig prüfen müssen, ob die native Validierung im Sinne der WCAG barrierefrei unterstützt ist („accessibility supported“).

• Je nach Browser bleibt die Meldung womöglich nicht dauerhaft sichtbar oder scrollt nicht mit der Seite mit.
• Je nach Browser wird die Meldung beim Zoomen nicht vergrößert: Sie bleibt in der Größe der Browseroberfläche und ist womöglich zu klein.
• Die Standardmeldungen sind meist recht allgemein und liefern womöglich keine ausreichenden Vorschläge für 3.3.3.
• Nur der erste Fehler wird angezeigt: Nutzer müssen das Formular womöglich mehrmals korrigieren und erneut absenden.

Häufige Fragen

Weiterlesen bei Conformly

• Formularfeld ohne Beschriftung in HTML korrigieren
• RGAA-Kriterium 11.10 zur Eingabekontrolle
• RGAA-Kriterium 11.11 zu Korrekturvorschlägen

Quellen

Dieser Artikel stützt sich auf die am Seitenende genannten offiziellen Quellen.

• W3C — Comprendre 3.3.1
• W3C — Comprendre 3.3.3
• W3C — Comprendre 3.3.2