Fehlererkennung

Silktide untersucht Pflichtfelder in Formularen, die offenbar eine benutzerdefinierte Validierung statt der eingebauten Browserprüfung verwenden, und warnt, wenn es keinen ersichtlichen Weg gibt, wie die Fehlermeldung Menschen erreicht, die nutzen.

Warum das wichtig ist

Wenn ein Formular eine ungültige Antwort zurückweist, sehen sehende Personen normalerweise eine rote Umrandung oder eine Meldung in der Nähe des Felds. Ein -Nutzer erhält das alles nicht, sofern die Seite den Fehler nicht im Code offenlegt: Das Formular lässt sich einfach nicht absenden – ohne Erklärung, was schiefging oder wo. Das Ergebnis ist ein Formular, das manche Besuchende stillschweigend aussperrt.

Browser kündigen ihre eigenen integrierten Validierungsmeldungen automatisch an. Das Risiko entsteht, wenn eine Seite dies abschaltet oder durch eine eigene Validierung ersetzt – und vergisst, den Ersatz für anzubinden.

So beheben Sie das Problem

Geben Sie jedem benutzerdefiniert validierten Feld einen programmatischen Weg für seine Fehlermeldung, mithilfe von :

<!-- Problem: benutzerdefinierte Validierung ohne zugänglichen Fehlermeldungskanal -->
<form novalidate>
  <input type="text" required>
  <span class="error">Geben Sie Ihren Namen ein</span>
</form>

<!-- Lösung: Das Feld verweist auf seine Fehlermeldung -->
<form novalidate>
  <input type="text" required aria-describedby="name-error">
  <span id="name-error" class="error">Geben Sie Ihren Namen ein</span>
</form>

Eines der folgenden erfüllt die Prüfung:

aria-errormessage am Feld, das auf das Element zeigt, das Sie mit dem Fehlertext befüllen (setzen Sie aria-invalid="true", wenn der Fehler angezeigt wird).
aria-describedby am Feld, das auf das Meldungselement zeigt.
Eine innerhalb des Formulars – ein Element mit role="alert", role="status" oder aria-live –, in das Ihre Validierung Fehlermeldungen schreibt.

Alternativ entfernen Sie die Anpassung und lassen die native Browservalidierung die Fehler melden; sie ist standardmäßig barrierefrei.

So testet Silktide das

Sichtbare Pflichtfelder finden – Eingabefelder, Textbereiche und Auswahlmenüs, die mit required oder aria-required="true" gekennzeichnet sind.
Nur Felder behalten, bei denen es Anzeichen gibt, dass die native Browservalidierung umgangen oder ersetzt wird: Das Formular hat novalidate, ein Sende-Steuerelement hat formnovalidate, das Feld ist mit aria-invalid gekennzeichnet, es verwendet aria-required ohne das native required-Attribut, oder Feld bzw. Formular tragen Hinweise auf benutzerdefinierte Validierung (z. B. fehlerbezogene Attribute oder Container für Fehlermeldungen).
Für jedes solche Feld nach einem zugänglichen Fehlermeldungskanal suchen: ein gültiger aria-errormessage-Verweis, ein gültiger aria-describedby-Verweis oder eine Live-Region innerhalb des Formulars.
Felder ohne jeden Kanal werden als Warnung gemeldet. Dies ist eine Warnung und kein bestätigter Fehler, da sich das Validierungsverhalten zur Laufzeit nicht vollständig aus dem Code der Seite beobachten lässt.

Fehlerbehebung

Meine Fehlermeldungen werden korrekt angesagt

Die Prüfung sucht nach der Struktur, die Ansagen ermöglicht, nicht nach der Ansage selbst. Wenn Ihr Framework eine Live-Region oder die ARIA-Verweise erst in dem Moment einfügt, in dem ein Fehler auftritt, zeigt die geladene Seite keinen Kanal und das Feld wird markiert. Das (leere) Meldungselement und den Verweis von vornherein hinzuzufügen, behebt dies und ist zudem robuster.

Das referenzierte Meldungselement existiert noch nicht

Verweise müssen auf Elemente zeigen, die auf der Seite existieren. Ein aria-describedby, das auf eine ID zeigt, die erst später erzeugt wird, zählt als kein Kanal.