BITV Reloaded – Anforderung 9

Bedingung 9.3: Geräteunabhängige Event-Handler (Prio. 1)

In Scripts sind logische anstelle von geräteabhängigen Event Handlern zu spezifizieren.«

Was heißt das?

Event-Handler sind sozusagen das Bindeglied zwischen HTML und JavaScript: hiermit können Sie Ereignisse angeben, die von einem Skript zur weiteren Verarbeitung ›abgefangen‹ werden können. Über den Event-Handler wird die Art des Ereignisses mitgeteilt, das der Nutzer durch seine Interaktion mit der Seite ausgelöst hat. Dies kann ein einfacher Klick oder ein Doppelklick sein, eine Tastatureingabe oder bestimmte Bewegungen mit der Maus. Auf Basis dieser verschiedenen Interaktionen können dann per Skript zum Beispiel die Inhalte einer Seite modifiziert oder weitergehende Aktionen wie die Überprüfung von Formulareingaben ausgelöst werden.

HTML und JavaScript kennen eine ganze Reihe solcher Event-Handler, im einzelnen sind dies:
onblur, onchange, onclick, ondblclick, onfocus, onkeydown, onkeypress, onkeyup, onload, onmousedown, onmousemove, onmouseout, onmouseover, onmouseup, onreset, onselect, onsubmit, onunload. Des weiteren gibt es noch Browser-spezifische Events wie onabort und onerror, die aber nicht Teil der HTML-Spezifikation sind und nicht von allen Browsern verstanden werden.

In HTML gibt es nicht für alle geräteabhängigen Event-Handler einen entsprechenden logischen Event-Handler. So nützt es bei ondoubleclick leider nichts, statt dessen zweimal die Aktion onkeypress ausführen zu lassen.

Tipp: ignorieren Sie bei diesem Punkt die Dokumentation der entsprechenden Richtlinie in den WCAG 1.0 bzw. in den Techniken zur Umsetzung – diese ist ausgesprochen lücken- und fehlerhaft. Die Techniken stammen noch aus Zeiten, als Scripting von Teilen des W3C als generell schädlich angesehen wurde. Zudem lag noch keine ausreichende Erfahrung im Umgang von assistiven Werkzeugen, insbesondere Screenreadern mit modernen Formen des Scripting vor. Leider sind diese Dokumente seit der Verabschiedung im Jahr 1999 nicht mehr aktualisiert worden, auch der aktuelle Stand des Nachfolgers WCAG 2.0 hat in diesem Bereich noch Luft nach oben.

Probleme bei der Bewertung

Die meisten in der Literatur zu findenden Ansätze, vermeintlich geräteabhängige Event-Handler wie Maus-Ereignisse mit einem (ebenso vermeintlich) geräteunabhängigen Event-Handler zu paaren sind, gelinde gesagt, mit Vorsicht zu genießen. Dies liegt zum Teil daran, dass die Event-Handler zum Teil mißverständlich benannt sind. Entgegen landläufiger Meinung lassen sich keine Rückschlüsse auf ihre Geräteunabhängigkeit alleine auf Basis des Vorkommens von Wörtern wie Mouse oder Click machen. ›Onclick‹ müsste strenggenommen ›onactivation‹ heißen, da dieser Event auch durch Tastatureingaben ausgelöst wird.

Auch der umgekehrte Fall tritt auf: Events wie onfocus und onblur sind nach der HTML-Spezifikation geräteunabhängige Ereignisse. In den üblichen Browsern sind diese aber als Events implementiert, die ausschließlich über die Tastatur (und in diesem Fall nicht durch die Maus) ausgelöst werden.

Negatives Beispiel:

Ein häufiger Fehler ist, Formularelemente per onchange oder onblur zu prüfen. Diese Art der Überprüfung ist zwar direkt und schnell und damit scheinbar hilfreich, kann aber das Ausfüllen eines Formulars per Tastatur oder Spracherkennung zu einer Tortur machen. Die wohl am meisten verbreitete Anwendung dieser Technik sind Dropdown-Menüs:

HTML:

1. <form>
2. <label for="go2">Gehe zu:</label>
3. <select name="go2" id="go2" onchange="send(this)">
4. <option value="anforderung-7.php">Anforderung 7</option>
5. <option value="anforderung-8.php">Anforderung 8</option>
6. <option value="anforderung-9.php">Anforderung 9</option>
7. </select>
8. </form>

JavaScript:

1. function send(f)
2. {
3. var chosen;
4. chosen=f.options[f.selectedIndex].value;
5. self.location=chosen;
6. }

Dieses nicht-barrierefreie Beispiel zum ausprobieren

Das Hauptproblem hierbei ist, dass Tastaturnutzer versuchen werden, mit Tabulator- und Pfeiltasten eine der Optionen auszuwählen. Sie werden jedoch niemals weiter als die erste Möglichkeit kommen, da die Funktion send() durch das Event onchange ausgeführt wird, sobald sich etwas ändert.

Erfahrene Tastaturbenutzer wissen, dass man zuerst per Alt + ↓ die Liste anzeigen muss, um dann die Option mittels der Pfeiltasten und Eingabe auszuwählen. Allerdings ist diese Bedien-Technik nicht jedem Besucher bekannt.

Zudem passiert im obigen Beispiel nichts, wenn JavaScript abgeschaltet ist, da das Formular für diese Fälle keinen Absenden-Button als Fallback vorsieht.

Positives Beispiel:

Das folgende Beispiel funktioniert immer und erspart einen Besuch beim Server, wenn JavaScript vorhanden ist. Sollte JavaScript abgeschaltet sein, übernimmt das serverseitige change.php-Skript die weitere Verarbeitung.

HTML:

1. <form action="change.php" method="post" ↵
2. onsubmit="return send(this)">
3. <label for="go2">Gehe zu:</label>
4. <select name="go2" id="go2">
5. <option value="anforderung-7.php">Anforderung 7</option>
6. <option value="anforderung-8.php">Anforderung 8</option>
7. <option value="anforderung-9.php">Anforderung 9</option>
8. </select>
9. <input type="submit" value="OK">
10. </form>

JavaScript:

1. function send(f)
2. {
3. var chosen;
4. chosen=f.go2.options[f.go2.selectedIndex].value;
5. self.location=chosen;
6. return false;
7. }

PHP:

1. <?PHP if(isset($_POST['go2'])){
2. header('Location:'.$_POST['go2']);
3. }?>

Dieses barrierefreie Beispiel zum ausprobieren

Und was ist mit onkeypress?

In den Techniken zu WCAG 1.0 findet sich die Vorgabe, Aktionen ausschließlich über solche Befehle aufzurufen, die unabhängig vom Eingabegerät sind:

»[…] if you must use device-dependent attributes, provide redundant input mechanisms (i.e., specify two handlers for the same element):

• Use ›onmousedown‹ with ›onkeydown‹.
• Use ›onmouseup‹ with ›onkeyup‹
• Use ›onclick‹ with ›onkeypress‹

Das klingt zunächst plausibel, wirft allerdings in der realen Welt Probleme auf. Der Befehl onkeypress ist in einigen Browsern sehr schlecht implementiert. Mozilla und Firefox zum Beispiel starten die Aktion, sobald man die Tabulator-Taste betätigt – was eigentlich den Mausklick nicht ersetzen, sondern zum nächsten interaktiven Element gehen sollte.

Websurfer, die auf Tastaturen angewiesen sind, haben häufig eine bestimmte Taste als Ihre ›Klicktaste‹ definiert, meistens die Leertaste oder Eingabe, um einen onclick-Befehl auszuführen. Wenn wir zusätzlich zu diesem noch einen onkeypress-Befehl verwenden, kann es passieren, dass das notwendige Tastaturkürzel blockiert oder die Funktion mehrmals aufgerufen wird. Beispiele für Tastaturfunktionen sind Mozillas Such- und Tippfunktion, Operas Tastaturkürzel (wie zum Beispiel ›A‹ für den nächsten Verweis) oder die Tastaturkürzel von Screenreadern wie JAWS.

Es kann also passieren, dass eine Befolgung der Richtlinien bis ins letzte Detail Besucher aussperrt oder es Ihnen unnötig schwierig macht, eine Seite oder Anwendung zu benutzen. Falls Sie befürchten müssen, dass Ihre Seiten einem automatisierten Accessibilitytest unterzogen werden, dann können Sie für die Dauer des Tests ein zusätzliches onkeypress einbauen und hinterher wieder auskommentieren.

Sonderfall Screenreader

Einen speziellen Anwendungsfall für barrierefreies JavaScript stellen die verbreiteten Screenreader wie JAWS, Virgo oder Window Eyes dar. Einfache Events wie onmouseover oder Klick-Events bei Links oder Formularelementen werden von diesen mittlerweile unterstützt. Das Problem hierbei ist, dass gängige Screenreader gut mit waghalsigen Code-Konstrukten aus dem vergangenen Jahrhundert zurechtkommen (s. diese Beispielseite), bei moderneren (und damit WCAG- bzw. BITV-konformen) Methoden der Umsetzung solcher Funktionen regelmäßig scheitern, wie Untersuchungen von Accessibility-Experten gezeigt haben.

Ein möglicher Lösungsweg aus diesem Dilemma könnte sein, den eigentlich unerwünschten alternativen Versionen für Screenreader-Nutzer zu neuem Leben verhelfen. In Web-basierten Anwendungen kann es durchaus sinnvoll sein, eine statische Alternative anzubieten. Dem Nutzer wird dadurch die Wahl gelassen zwischen einer statischen, jedoch weniger komfortablem Version und einer dynamischen, mit JavaScript angereicherten Version. Diese statischen Alternativen sollten jedoch nur als Interims-Lösung betrachtet werden, um den Herstellern von Hilfsmitteln die Chance zu geben, ebenfalls standardkonforme Anwendungen zu entwickeln.