Einfaches ARIA Tip #2: aria-invalid und role „alert“

Mein zweiter Tip rund um ARIA (Accessible Rich Internet Applications) beschäftigt sich mit einem Problem, das wohl jedem von uns beim Ausfüllen eines Formulars schon mal begegnet ist: Man vertippt sich bei der E-Mail-Adresse bzw. der eventuell geforderten Wiederholung davon, oder ähnliches passiert beim Kennwort. Man hat vielleicht vergessen, ein erforderliches Feld gänzlich auszufüllen. Man hat also fleißig seine 20 Felder ausgefüllt, drückt den Schalter „Abschicken“, und dann kommt der Server mit einer oder mehreren Fehlermeldungen zurück, und man muss die Formularfelder korrigieren und die übrigen nochmals durchgehen um sicherzustellen, dass keine Informationen zurückgesetzt oder entfernt wurden.

Wäre es da nicht schön, wenn man ein Formular so umgestalten könnte, dass Fehler sofort erkannt würden und man darauf hingewiesen werden würde? Mit dem Einsatz von ARIA ist dies kein Problem!

Das Formular

Als Beispiel soll folgendes einfaches Kontaktformular herhalten:

<html>
<head>
<title>Kontaktformular</title>
</head>
<body>
<form method="post" action="post.php">
<fieldset><legend>Bitte gib deine Kontaktdaten an</legend>
<label for="name">Dein Name (erforderlich):</label>
<input name="name" id="name" aria-required="true"/><br />
<label for="email">E-Mail-Adresse (erforderlich):</label>
<input name="email" id="email" aria-required="true"/><br />
<label for="website">Website (optional):</label>
<input name="website" id="website"/>
</fieldset>
<label for="message">Bitte gib deine Nachricht ein (erforderlich):</label><br />
<textarea name="message" id="message" rows="5" cols="80" aria-required="true"></textarea><br />
<input type="submit" name="submit" value="Nachricht abschicken"/>
<input type="reset" name="reset" value="Formular zurücksetzen"/>
</form>
</body>
</html>

Nichts Großes, aber wir wollen damit ja auch keinen Schönheitswettbewerb gewinnen. 😉 Einzige Besonderheit ist das Attribut aria-required, welches ich bereits früher ausführlich behandelt habe.

Der Hinweis, dass etwas fehlerhaft eingegeben wurde

Ziel ist es, sowohl beim Feld „Name“ als auch beim Feld „E-Mail-Adresse“ einen Hinweis zu geben, wenn eine fehlerhafte Eingabe entdeckt wurde. Hierzu testen wir, ob im namen ein Leerzeichen vorkommt (es sind also mindestens Vor- und Nachname erforderlich), und ob in der E-Mail-Adresse das „@“-Zeichen vorkommt. Ist die Eingabe fehlerhaft, so wird zum einen das Feld selbst mit dem Attribut aria-invalid versehen, dessen Wert auf „true“ gesetzt wird. Dies bewirkt, dass aktuelle Screen Reader das Feld als eines mit einer ungültigen Eingabe versehenen identifizieren können. Zum anderen wird unterhalb des Formulars eine kleine Box eingeblendet, die einen entsprechenden Hinweis auf den Fehler enthält. Diese Box, die mit einem einfachen div-Element gestaltet wird, bekommt durch das role-Attribut die Rolle eines sogenannten Alerts, eines Hinweises. Dies verhält sich dann entsprechend der aus Firefox 3 bekannten Hinweismeldung „Soll Firefox dieses Passwort speichern?“. Der Fokus wird nicht zu diesem Hinweistext verschoben, es kommt auch kein Dialogfeld hoch, das man erst wegdrücken muss, sondern der Hinweis wird im Laufenden Vorgang des Ausfüllens des Formulars gegeben und man kann sofort weiterarbeiten.

Das ganze passiert in dem Moment, wo der Anwender den Fokus von dem entsprechenden Eingabefeld weg bewegt, es also den Fokus verliert. JavaScript-versierte ahnen es: Dies geschieht durch das onblur-Ereignis, welches immer dann ausgelöst wird, wenn ein Element den Tastaturfokus verliert. Im Kopf der HTML-Datei definieren wir uns jetzt also drei helfende Funktionen:

  1. removeOldAlert: Diese Funktion entfernt lediglich den vom letzten Fehler aufgegangenen Hinweis. Dieser wird entfernt, wenn entweder ein neuer Hinweis erscheinen soll oder der Fehler erfolgreich korrigiert wurde.
  2. addAlert: Diese Funktion fügt einen Hinweis in das Dokument ein. Sie entfernt dazu zunächst alte eventuell noch vorhandene Hinweise, erzeugt ein div-Element und gibt diesem zwei Attribute: Eine ID, mit der das Element später wiedergefunden werden kann, und das bereits erwähnte Attribut role. Schlussendlich wird der übergebene Text als Inhalt des divs eingefügt und das gesamte Element dem Dokument hinzugefügt. Alles weitere, sprich das Auslösen des Alert-Ereignisses wird automatisch durch Firefox veranlasst, wir müssen uns hier um nichts weiter kümmern.
  3. checkValidity: Diese Funktion ist das eigentliche Herzstück. Sie sucht zunächst innerhalb des durch den Parameter aID angegebenen Elements nach dem als aSearchTerm übergebenen Suchbegriffs. Ist diese Suche nicht erfolgreich, wurde also eine ungültige Eingabe getätigt, werden die oben beschriebenen Schritte zur Kenntlichmachung der Ungültigkeit eingeleitet. Ist die Suche hingegen erfolgreich, der Eintrag also nicht ungültig, werden eventuelle Hinweise entfernt und das Attribut aria-invalid auf „false“ gesetzt.

Der zugehörige JavaScript-Code sieht wie folgt aus:


<script type="application/javascript">
  function removeOldAlert()
  {
    var oldAlert = document.getElementById("alert");
    if (oldAlert)
      document.body.removeChild(oldAlert);
  }

  function addAlert(aMsg)
  {
    removeOldAlert();
    var newAlert = document.createElement("div");
    newAlert.setAttribute("role", "alert");
    newAlert.setAttribute("id", "alert");
    var msg = document.createTextNode(aMsg);
    newAlert.appendChild(msg);
    document.body.appendChild(newAlert);
  }

  function checkValidity(aID, aSearchTerm, aMsg)
  {
    var elem = document.getElementById(aID);
    var invalid = (elem.value.indexOf(aSearchTerm) < 0);
    if (invalid) {
      elem.setAttribute("aria-invalid", "true");
      addAlert(aMsg);
    } else {
      elem.setAttribute("aria-invalid", "false");
      removeOldAlert();
    }
  }
</script>

Einhängen des Codes in die Ereignisbehandlung

Dies ist einfach: Es wird jetzt nur noch ein Aufruf von checkValidity als Wert des onblur-Attributes für die „name“ und „email“-Input-Elemente eingefügt. Die geänderten Zeilen sehen so aus:

<input name="name" id="name" aria-required="true" onblur="checkValidity('name', ' ', 'Ungültigen Namen eingegeben!');"/><br />

<input name="email" id="email" aria-required="true" onblur="checkValidity('email', '@', 'Ungültige E-Mail-Adresse');"/><br />

Testen des Beispiels

Das vollständige Beispiel habe ich zum Ausprobieren hochgeladen. Das Formular tut nichts, es ist lediglich als Anschauungsobjekt gedacht. Probiert mal folgendes:

  1. Gebt ins Feld „Name“ nur euren Vornamen ein und drückt Tab.
  2. Gebt in das Feld „E-Mail-Adresse“ eine verklausulierte E-Mail-Adresse ein, die kein „@“-Zeichen enthält, und drückt Tab.

Einige Anmerkungen

Warum hast du keine Ereignisbehandlungsroutine für das Feld „message“ erstellt?
Dies überlasse ich dem geneigten Leser, sozusagen als „Hausaufgabe“ zum selbst ausprobieren. 😉
Warum setzt du das Wort „erforderlich“ in die Beschriftung der Textfelder, wenn diese doch per aria-required als erforderlich gekennzeichnet sind?
Wir müssen davon ausgehen, dass auch Anwender mit Browsern und/oder Screen Readern unsere Seiten besuchen, die ARIA nicht verarbeiten können bzw. das Mitteilen eines erforderlichen Feldes nicht unterstützen. IE 7 und JAWS 8.0 sind solche Beispiele. Solange also noch eine große Anzahl Browser und/oder Screen Reader in Umlauf sind, die diese neuen Techniken noch nicht unterstützen, ist auch weiterhin eine eindeutige verbale Kennzeichnung erforderlicher Felder auf Webseiten nötig. Screen Reader, die dies jedoch schon unterstützen, können erforderliche Felder auch anders als durch Sprache, z. B. durch das Abspielen eines bestimmten Klanges, kennzeichnen, so dass die Verwendung dieses Attributes Anwendern aktueller Screen Reader auf jeden Fall weitere Vorteile ermöglicht.
Warum setzt du den Fokus nicht automatisch auf das ungültige Feld zurück?
Weil dies von mindestens der Windows-API-Dokumentation und möglicherweise anderen nicht erlaubt ist. Man darf bei einem Fokuswechsel nicht auf das Feld zurückkehren, von dem man gerade weg navigiert. Außerdem ist es nicht besonders benutzerfreundlich, den Fokus ohne Eingriff des Benutzers zuviel herumspringen zu lassen.

Weiterhin ist natürlich anzumerken, dass das obige Beispiel keinen Anspruch auf Vollständigkeit erhebt. Neben den hier gezeigten Methoden zur Kenntlichmachung von ungültigen Feldern kann man natürlich ein ungültiges Feld auch mit visuellen Stilen kenntlich machen, indem man es z. B. rot einfärbt. Der Experimentierfreudigkeit sind hier kaum Grenzen gesetzt.

Auch ist es natürlich möglich, wenn serverseitig schon Mechanismen zur Kontrolle der Eingaben vorhanden sind, diese per AJAX durchführen zu lassen anstatt innerhalb der Seiten diesen Code zu duplizieren. Der Verwendung von ARIA tut dies keinen Abbruch.

Fazit

Dieses Beispiel zeigt meiner Meinung nach eindrucksvoll, wie das immer als so wenig barrierefrei hingestellte und verschriene JavaScript genutzt werden kann, um das Ausfüllen eines Formulars wesentlich barrierefreier zu gestalten als dies heute gängige Praxis ist.

Ich würde mir wünschen, dass diese Art der frühzeitigen Warnung vor fehlerhaften Eingaben möglichst bald in großer Anzahl verwendet wird. Es ist meiner Meinung nach wesentlich benutzerfreundlicher, sofort auf Eingabefehler hinzuweisen, so dass diese dann noch während des Ausfüllens des Formulars korrigiert werden können. Ich persönlich finde es immer sehr mühselig, nach eventuell fehlerhaft gemachten Eingaben auf der nächsten Seite die Formularfelder alle nochmals durchgehen zu müssen, um das fehlerhafte zu finden, und um zu kontrollieren, dass auch ja keine der gültigen Angaben verlorengegangen sind.

Frühere Einfache ARIA Tipps

6 Gedanken zu „Einfaches ARIA Tip #2: aria-invalid und role „alert““

  1. Hallo Marco,
    die Funktion ist ja an sich klasse, jedoch glaubst du wirklich, das jeder Webentwickler weiß, wie diese Arias zu machen sind bzw. das es sie gibt? Wäre doch auch mal schön, wenn es irgendwann Browser gibt, die es auch unterstützen. Da diese Aria-Geschichte mit Accessibillity zu tun hat, glaube ich ehrlich gesagt garnicht daran, das diese Features auf einer Webseite eingesetzt werden, außer auf irgendwelchen staatlichen Seiten oder Blinden-homepages. Man müsste die Webentwickler ja dazu „zwingen“ es einzusetzen bzw. eine Vorschrift machen.

    Viele Grüße
    Ali

  2. Hallo Ali,

    ARIA ist mitnichten nur noch irgendeine Nischen-Geschichte. Neben dem Firefox 3, der diese Spezifikation vollständig implementiert, arbeiten auch Microsoft im IE 8, Apple im Webkit (Grundlage für Safari) und Opera daran, ARIA-Unterstützung in ihre Browser einzubauen. ARIA befindet sich auf dem Wege, in Bälde W3C-Standard zu werden.
    Dies wird höchstwanrscheinlich noch in diesem jahr passieren und zukünftig genauso in BITV- und ähnlich gelagerte Dokumente einfließen wie bisherige W3C Accessibility Guidelines.

    Und erste privatwirtschaftliche Unternehmen haben angefangen, ARIA bereits einzubauen. Yahoo! und Google sind hier Vorreiter. Siehe z. B. folgenden Test, den ich in meinem englischsprachigen Blog zu ARIA in Gmail durchgeführt habe:
    http://www.marcozehe.de/2008/08/06/aria-in-gmail-2-enhancing-the-chat-experience/

    Dieser Test ist nur deshalb bis jetzt noch nicht in diesem deutschen Blog erscheinen, weil Google diese Erweiterungen bisher erst im englischsprachigen Gmail im Angebot hat.

    Gruß
    Marco

  3. Hallo,

    einige kleine Anmerkungen:

    1. An sich ist das mit ARIA eine feine Sache. Leider bringt es – soweit ich es bisher testen konnte – nur etwas für Leute mit Sprachausgabe. Arbeitet man mit der Zeile, so bleiben die neuen Erkenntnisse verborgen. 🙁 Wobei dass jetzt vermutlich weniger an ARIA selbst, sondern z. B. an Jaws liegt (ich teste hier gerade die aktuelle 10ner Deutsch).

    2. Wenn man im Klartext noch auf ein Pflichtfeld hinweisen will, sollte man nicht unbedingt das selbe Wort nehmen, was auch der Browser übermittelt. 2 X „erforderlich“ könnte bei Anfängern etwas zu Verwirrungen führen und es ist auch nicht wirklich schön. Dann wäre der Stern für die optische Variante eher zu nutzen.

    3. Zwei Dinge zu deinem Blog:

    a) Auf der Seite des zweiten Aria Tipps bist du bei den Überschriftsebenen durcheinander gekommen – nach der 3 folgt hier die 5, dann die 4. 🙂

    b) Auch wird mir als Label für das Formularfeld, in das ich gerade schreibe, nicht „Gib deine Mitteilung …“ o. ä. angezeigt, obgleich es im Quelltext steht. Evtl. ein FEature von Jaws 10? 🙂

    Ansonsten lesenswerte Infos, die du so hast … Danke.

    Viele Grüße

    Sebastian

  4. Hallo,

    mit einem onblur Eventhandler kann man doch auch eine Funktion aufrufen, die als Ergebnis ggf. eine Warnung per JavaScript Alert Box erzeugt. Diese Alert Box kriegen dann alle Besucher zu sehen, auch, aber nicht nur, Benutzer von Jaws 10.0 mit Firefox 3.x
    Auch gegen Setzen des Fokus in das fehlerhafte Feld nach Quittieren der Alert Box spricht IMHO nichts.

  5. Hallo,

    ich habe gerade das Kontaktformular der Seite di ich betreuen darf umgearbeitet. Die Maske war alt und label habe ich eingebaut und das Layout
    mit tabelle entfernt.
    Bei der Überprüfung der Seite meckerte das zuständigen Script dass das ein oder andere Feld leer war. Dementsprechend habe ich die Überprüfung von
    onblur auf onsubmit geändert. Natürlich ich es nicht im Sinne des Berichtes von Marco. Bei der Überprüfung einzelne Felder sollte nicht das Fokus auf das fehlerhaftes Feld gesetzt werden, wie hier Fritz Weisshart es vorschlug. Der Anwender wird gezwungen irgend etwas Sinnvoll einzutragen, auch wenn er einfach die Maske anschliessend verlassen möchte.

Was denkst Du darüber?