Barrierefreie Fehlermeldungen: So funktionieren sie mit JAWS, NVDA und VoiceOver

Barrierefreie Webformulare erfordern mehr als nur technische Umsetzung – sie müssen für alle Nutzer verständlich und nutzbar sein. Ein häufiges Problem sind Fehlermeldungen, die zwar technisch korrekt sind, aber für Screenreader-Nutzer unsichtbar oder unvollständig bleiben. Zwei reale Beispiele aus Audits zeigen, wie selbst gut gemeinte Lösungen scheitern können.

Warum viele Fehlermeldungen Screenreader-Nutzer im Stich lassen

Die meisten Entwickler testen Formulare mit Tastatur oder Maus, doch Screenreader-Nutzer wie JAWS-, NVDA- oder VoiceOver-Nutzer haben andere Anforderungen. Eine Fehlermeldung, die per Tooltip oder Popup erscheint, wird oft nicht oder zu spät angekündigt. Die Folge: Nutzer korrigieren Fehler blind – oder übersehen sie komplett.

Fall 1: Die verschwindende Fehlermeldung im E-Learning-Tool

Ein Bildungsanbieter setzte auf automatisch verschwindende Toasts, um Validierungsfehler anzuzeigen. Mit einer Verzögerung von acht Sekunden schien die Lösung praktikabel. Doch Screenreader-Nutzer benötigen oft deutlich mehr Zeit:

• Die Fehlermeldung muss gehört werden.
• Der Nutzer muss sie verstehen.
• Er muss zurück zum Eingabefeld navigieren.
• Die Korrektur vornehmen und das Formular erneut absenden.

Auf komplexen Formularen reicht diese Zeitspanne nicht aus. Die Meldung verschwindet, bevor der Nutzer handeln kann – ein klarer Verstoß gegen die Richtlinien für barrierefreie Webinhalte (WCAG), konkret gegen Erfolgskriterium 2.2.1 („Zeitbegrenzung anpassbar“).

Die Lösung: Verzichten Sie auf automatisch verschwindende Toasts für Fehler. Nutzen Sie stattdessen statische Fehlermeldungen, die direkt neben dem Eingabefeld angezeigt werden und bis zur Korrektur sichtbar bleiben. Toasts eignen sich nur für redundante, niedrigpriore Benachrichtigungen.

Fall 2: Die Fehlermeldung, die bei Fokusverlust verschwindet

Ein anderes Formular zeigte Fehler nur an, solange das Eingabefeld den Fokus hatte. Sobald der Nutzer per Tabulator zur nächsten Eingabe wechselte, wurde die Fehlermeldung ausgeblendet. Screenreader wie JAWS oder NVDA kündigten daraufhin nur „Ungültige Eingabe“ an – ohne Kontext oder Handlungsanweisung.

Zwei grundlegende Probleme traten hier auf:

• Die Fehlermeldung verschwand beim Verlassen des Feldes, sodass sie selbst bei erneuter Fokussierung nicht mehr sichtbar war.
• Es fehlte die Verbindung zwischen Fehlermeldung und Eingabefeld (aria-describedby), sodass Screenreader die Meldung nicht automatisch vorlasen.

Die Lösung: Entfernen Sie die onblur-Logik, die Fehlermeldungen bei Fokusverlust ausblendet. Nutzen Sie stattdessen aria-describedby, um die Fehlermeldung programmatisch mit dem Eingabefeld zu verknüpfen. So wird die Meldung bei jedem Fokuswechsel automatisch vorgelesen – und bleibt sichtbar, bis der Nutzer den Fehler korrigiert.

Best Practices für zugängliche Fehlermeldungen

Damit Fehlermeldungen für alle Nutzer funktionieren, sollten Entwickler folgende Muster beachten:

• Statische Anzeige: Zeigen Sie Fehler direkt neben dem Eingabefeld an und lassen Sie sie sichtbar, bis der Nutzer die Eingabe korrigiert.
• Programmatische Verknüpfung: Nutzen Sie aria-describedby, um die Fehlermeldung mit dem Eingabefeld zu verknüpfen. Dies stellt sicher, dass Screenreader die Meldung bei Fokus automatisch vorlesen.
• Verständliche Sprache: Formulieren Sie Fehlermeldungen klar und präzise. Vermeiden Sie Fachjargon und geben Sie konkrete Handlungsanweisungen.
• Keine Zeitlimits: Vermeiden Sie automatisch verschwindende Meldungen für kritische Fehler. Nutzen Sie Toasts nur für nicht-kritische Benachrichtigungen.

Ein weiteres Beispiel:

<label for="email">E-Mail-Adresse</label>
<input type="email" id="email" aria-describedby="email-error" required>
<span id="email-error" class="error-message" aria-live="assertive">
  Bitte geben Sie eine gültige E-Mail-Adresse ein.
</span>

In diesem Code wird die Fehlermeldung mit aria-describedby verknüpft und bleibt sichtbar, bis der Nutzer die Eingabe korrigiert. Der aria-live-Bereich stellt sicher, dass Screenreader die Meldung bei Änderungen sofort vorlesen.

Ausblick: Neue Herausforderungen bei VoiceOver und Safari

Während JAWS und NVDA in den meisten Fällen zuverlässig funktionieren, gibt es weiterhin Quirks in der Kombination aus VoiceOver und Safari auf iOS. Entwickler sollten diese Randfälle testen, um sicherzustellen, dass ihre Lösungen auch in diesen Umgebungen funktionieren.

Die Zukunft der barrierefreien Webformulare liegt in der konsequenten Umsetzung von Standards wie WCAG und ARIA. Indem Entwickler diese Muster verinnerlichen, schaffen sie digitale Erlebnisse, die wirklich für alle zugänglich sind.

Haben Sie bereits Erfahrungen mit spezifischen Herausforderungen in VoiceOver und Safari gemacht? Teilen Sie Ihre Erkenntnisse in den Kommentaren – denn nur durch den Austausch können wir die Barrierefreiheit im Web weiter verbessern.