Ungültige Eingabe  

Ein paar Unregelmäßigkeiten des aria-invalid-Attributs

Eingabefeld mit Fehlermeldung "Es wurde keine Telefonnummer angegeben".

Eingabefehler in einem Web-Formular können nach einer Formularvalidierung mit dem aria-invalid-Attribut gekennzeichnet werden. In Verbindung mit einem aria-errormessage-Attribut können passende Fehlermeldungen mit dem Eingabefeld verknüpft werden. Allerdings funkt das required-Attribut manchmal dazwischen.

Nach der aktuellen ARIA 1.1-Spezifikation darf das aria-invalid-Attribut erst nach einer Formularvalidierung zu einem Element hinzugefügt werden. Das folgende Beispiel stellt eine solche Situation dar. Ein Formular mit einem Pflichtfeld wurde abgeschickt. Weil das Pflichtfeld nicht ausgefüllt wurde, wird eine Fehlermeldung vor dem Formular angezeigt und das Formularelement wird mit aria-invalid=“true“ gekennzeichnet:

<p>Es wurde keine Telefonnummer eingegeben.</p>

<p><label for="foo">Telefonnummer*</label>
<input aria-invalid="true" type="tel" id="foo" name="tel"></p>

Das aria-invalid-Attribut wird nur von Screenreadern unterstützt. Es beeinflusst die Funktionalität oder das Aussehen eines Eingabefelds im Browser nicht, sondern bewirkt lediglich, dass Screenreader einen Text „ungültiger Eintrag“ o.ä. hinzufügen, wenn sie den Namen des Eingabefelds ausgeben, hier also z.B. „Telefonnummer* Ungültiger Eintrag“.

Diese Information kann hilfreich sein, wenn Screenreadernutzer nach einem inkorrekt ausgefüllten Formularfeld suchen. Deswegen ist das Attribut erst nach einer Formularvalidierung einzusetzen.

Das required-Attribut

Oben wurde das Pflichtfeld im Formular mit einem * als Pflichtfeld gekennzeichnet. Statt mit einem * kann das Eingabefeld aber mit einem required-Attribut gekennzeichnet werden:

<p><label for="foo">Telefonnummer</label>
<input required type="tel" id="foo" name="tel"></p>

Mit dem required-Attribut erfahren alle, dass es sich um ein Pflichtfeld handelt, auch Screenreadernutzer. Browser unterbinden außerdem das Abschicken des Formulars, wenn in solchen Pflichtfeldern keine Eingabe vorgenommen wurde.

Browser interpretieren dabei das required-Attribut gemäß HTML-Spezifikation und kennzeichnen solche Formularelemente nicht nur als erforderlich, sondern auch als „suffering from being missing“. Browser kennzeichnen das Eingabefeld deshalb als ungültig (aria-invalid=“true“). Screenreader werden Formularelemente mit dem required-Attribut z.B. sowohl als „erforderlich“ (required) als auch als „Ungültiger Eintrag“ (aria-invalid=“true“) Kennzeichnen. Das Eingabefeld wird in einem Screenreader z.B. als „Telefonnummer erforderlich Ungültiger Eintrag“ identifiziert werden.

Dieser Umstand kann bei einzelnen Formularelementen ignoriert werden, aber bei umfangreichen Formularen ist zusätzlicher Text oft ein Problem beim Ausfüllen in einem Screenreader. Die doppelte Kennzeichnung eines Pflichtfelds kann natürlich mit aria-invalid=“false“ unterdrückt werden:

<p><label for="foo">Telefonnummer</label>
<input required aria-invalid="false" type="tel" id="foo" name="tel"></p>

Diese Vorgehensweise steht im Konflikt mit der ARIA-Spezifikation, die den Einsatz des aria-invalid-Attributs erst nach einer Formularvalidierung zulässt. Aus Nutzersicht kann der Einsatz aber trotzdem hilfreich sein.

Das aria-errormessage-Attribut

Ein Formularfeld kann mit einem zusätzlichen Text per aria-describedby-Attribut verknüpft werden:
<p id="foo">Es wurde keine Telefonnummer eingegeben.</p>

<p><label for="bar">Telefonnummer*</label>
<input aria-describedby="foo" type="tel" id="bar" name="tel"></p>

Wenn Screenreader das Formularelement fokussieren, werden Name („Telefonnummer*“ und die verknüpfte Beschreibung („Es wurde keine Telefonnummer eingegeben.“) herangezogen und Screenreader geben bei Fokus „Telefonnummer* Es wurde keine Telefonnummer eingegeben.“ aus.

Da hier eine Fehlermeldung verknüpft ist, könnte statt eines aria-describedby-Attributs ein aria-errormessage-Attribut zum Einsatz kommen. Das aria-errormessage-Attribut für ein Formularelement funktioniert aber nur, wenn das Formularelement ein aria-invalid-Attribut besitzt, dessen Wert nicht „false“ ist (neben „true“ gibt es auch die Werte „grammar“ und „spelling“). Um das aria-errormessage-Attribut einzusetzen, muss der Code wie folgt angepasst werden:

<p id="foo">Es wurde keine Telefonnummer eingegeben.</p>

<p><label for="bar">Telefonnummer*</label>
<input aria-errormessage="foo" aria-invalid="true" type="tel" id="bar" name="tel"></p>

Wie das aria-invalid-Attribut bewirkt das aria-errormessage einen zusätzlichen Text im Screenreader, der in etwa „Enthält Fehler“ lautet. Da die Fehlermeldung auch gelesen wird, geben Screenreader beim vorstehenden Beispiel in etwa folgendes aus: „Telefonnummer*: Ungültiger Eintrag Enthält Fehler Es wurde keine Telefonnummer eingegeben.“

Ob dadurch wirklich was gewonnen wird, kann durchaus bezweifelt werden. Da es auf den Text der Fehlermeldung ankommt, kann die Verknüpfung auch mit dem aria-describedby-Attribut vorgenommen werden und auf die aria-invalid- und aria-errormessage-Attribute verzichtet werden.

Nochmal zum required-Attribut

Wenn das required-Attribut vorhanden ist, dann ist das aria-invalid-Attribut auf „true“ gesetzt. Im nachfolgenden Beispiel wird die mit aria-errormessage verknüpfte Fehlermeldung bei der Identifizierung des Eingabefelds mit vorgelesen:

<p id="foo">Es wurde keine Telefonnummer eingegeben.</p>

<p><label for="bar">Telefonnummer</label>
<input required aria-errormessage="foo" type="tel" id="bar" name="tel"></p>

Screenreader identifizieren das Feld in etwa mit „Telefonnummer erforderlich Ungültiger Eintrag Enthält Fehler Es wurde keine Telefonnummer eingegeben.“ Hier erscheint die Technik mit dem aria-errormessage-Attribut ebenso nicht geeignet.

Testdatei

Die beschriebenen Situationen stehen auf einer Testseite zur Verfügung. Es wurden JAWS auf Chrome, NVDA auf Firefox und VoiceOver auf Safari (OS X) getestet. Die Ergebnisse sind nicht gleich. Während JAWS recht viel Text produziert, steigen NVDA und VoiceOver bei aria-errormessage aus.

Fazit

Der Einsatz des aria-invalid-Attributs ist erstmal nur sinnvoll, wenn das required-Attribut nicht im Einsatz ist und wenn das aria-invalid-Attribut nach einer Formularvalidierung einem Element hinzugefügt wird. Dann ist das Attribut hilfreich bei der Suche nach Eingabefehlern.

Mit dem aria-errormessage-Attribut kann ich mich nicht richtig anfreunden. Es gibt zu den vorgestellten Ergebnissen auch einige weitere Anforderungen an die Umsetzung, die in der ARIA-Spezifikation genauer beschrieben werden. Aus meiner Sicht müsste das Attribut anstelle und nicht zusammen mit dem aria-invalid-Attribut angewandt werden. Aktuell funktioniert das Attribut allerdings nicht gut.

Natürlich ist die doppelte textliche Kennzeichnung von Eingabefeldern bei Einsatz von aria-invalid und aria-errormessage mit „Ungültiger Eintrag“ und „Enthält Fehler“ redundant (JAWS, siehe Testseite). Wenn beide Attribute vorhanden sein müssen, dann müsste sich daraus ein einzelner Text ergeben. Unter dem Strich sollte aber die Ausgabe der verknüpften Fehlermeldung ausreichen, was dem Verhalten von aria-describedby entspricht.

Man kann sich fragen, warum die Windows-Browser das aria-invalid-Attribut bei Vorhandensein eines required-Attributs automatisch setzen. Ich halte das für falsch, aber das Problem ist mindestens 11 Jahre alt. Ob das Browserverhalten mit einem aria-invalid=“false“ verändert werden soll, muss jeder selbst entscheiden. Im Zweifel würde ich so vorgehen.

1 Gedanke zu “Ungültige Eingabe – Ein paar Unregelmäßigkeiten des aria-invalid-Attributs

  1. Mal wieder super erklärt! – Freut mich, dass du wieder etwas veröffentlicht hast!
    In der Tiefe habe ich mich damit nich gar nicht beschäftigt, deshalb: mal wieder was Neues gelernt beim Herrn Hellbusch!

Schreibe einen Kommentar zu Marc Haunschild Antworten abbrechen

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.