Tipp: Mit einem Screen Reader mit den dynamischen Menüs des WordPress-3.3-Adminbereiches umgehen

WordPress 3.3 führt neue, dynamische Menüs im Administrationsbereich ein. Dieser einfache Tipp soll zeigen, wie man als Blinder mit einem Screen Reader diese dynamischen Menüs bedienen kann. Hierfür verwende ich NVDA 2011.3RC und Firefox, es geht aber auch mit anderen Screen-Reader- und Browser-Kombinationen.

Diese Untermenüs ermöglichen einen schnelleren Zugriff auf die Untermenüpunkte. Man muss nicht erst einen Hauptmenüpunkt anklicken, auf das erneute Laden der Seite warten und dann auf die aufgeklappten Menüs zugreifen. Stattdessen werden die Untermenüpunkte sichtbar, indem man mit der Maus drüberfährt, sogenanntes Hovern, oder mit tab auf den jeweiligen Link springt und Enter drückt.

Das Problem für Screen-Reader-Benutzer ist, dass die Enter-Taste in der Regel vom Screen Reader abgefangen und für eine Funktion innerhalb des sogenannten virtuellen Dokuments oder Browse-Modus verwendet wird. Normalerweise wird durch Druck auf Enter ein Link aktiviert.

Genau das wollen wir ja aber nicht, denn das Aktivieren eines Links erzeugt ein Neuladen der Seite, und sämtliche Vorteile des schnelleren Zugriffs auf die dynamischen Menüs wären dahin.

Stattdessen tun wir folgendes:

  1. Mit dem virtuellen Cursor auf einen dieser „Untermenü Link“-Elemente wandern.
  2. NVDA-Taste+F2 drücken, um NVDA anzuweisen, den nächsten Tastendruck ungefiltert an den Browser weiterzugeben.
  3. Enter drücken.
  4. Mit dem virtuellen Cursor nach unten wandern und ein aufgeklapptes Menü vorfinden.

Diese Methode funktioniert analog mit anderen Screen Readern. Manche Screen Reader fokussieren jedoch nicht automatisch das unter dem virtuellen Cursor befindliche Element. Vor dem obigen Schritt 2 muss also eventuell noch eine Tastenkombination gedrückt werden, mit der der System-Fokus oder PC Cursor zum virtuellen Cursor gezogen wird.

Die oben beschriebene Methode ist ein Tastendruck mehr. Das stimmt, aber diese Vorgehensweise ist immer noch schneller als auf das erneute Laden einer Seite zu warten und dann die aufgeklappten Menüs wieder vom Anfang des virtuellen Dokuments an suchen zu müssen.

Viel Spaß beim Bloggen!

Von WAI-ARIA nach HTML5 und zurück, oder doch nicht?

Auf dem Multimediatreff 28 in Köln am 3. Dezember hielt ich einen Vortrag über Barrierefreiheit mit WAI-ARIA und HTML5. Als Beispiel zog ich hierfür meinen einfachen ARIA-Tip #2 heran und entwickelte diesen weiter. HTML5 bietet inzwischen viele der Fähigkeiten, die WAI-ARIA mitbringt, nativ, und viele davon sogar besser.

Von WAI-ARIA nach HTML5

Wer das im obigen verlinkten Artikel entwickelte Formular nicht mehr ganz parat hat, dem empfehle ich einen erneuten Blick darauf zu werfen. Die folgenden Änderungen habe ich vorgenommen, um das Formular von WAI-ARIA und HTML 4.01 auf HTML5 zu bringen:

  1. Allen JavaScript-Code rausschmeißen. Die Formularvalidierung von HTML5 nimmt uns viel Arbeit ab. Da bauen wir lieber wieder was ein, wenn wir merken, dass das Formular zu wenige Features hat.
  2. aria-required ändern in required. Sämtliche erforderlichen Formularfelder bekommen das WAI-ARIA-Attribut inklusive Wert gestrichen und einfach das HTML5-Formularelementattribut required verpasst.
  3. Das Feld „name“ bekommt ein pattern-Attribut mit einem regulären Ausdruck verpasst, der besagt, dass das Feld nur dann gültig ausgefüllt ist, wenn der eingegebene Name aus beliebigen Zeichen, einem Leerzeichen und weiteren beliebigen Zeichen besteht. Ein Name ist in unseren Breiten üblicherweise aus Vor- und Nachname zusammengesetzt, und das sollte das Formular wissen.
  4. Das Feld „email“ bekommt als type den Wert „email“, das Feld „website“ den type „url“ gesetzt. Dadurch weiß der Browser, dass er eine E-Mail- bzw. Webseiten-Adresse zu erwarten hat. Weiterhin hat dies den positiven Nebeneffekt, dass auf mobilen Geräten gleich die entsprechend verbesserten virtuellen Tastaturen eingeblendet werden. Mir ist bewusst, dass die meisten Browser zur Zeit noch nichts mit internationalen Domains anfangen können bzw. Felder mit solchem Inhalt noch nicht validieren. Wir decken der Einfachheit halber aber mal den großen Teil der allgemeinen Fälle ab.
  5. Im Feld Name fügen wir noch ein Attribut x-moz-errormessage hinzu. Das Präfix besagt, dass dies kein Standard-Attribut für HTML5 ist. Mozilla-basierte Browser können aber eine bessere Fehlermeldung ausgeben. Achtung, die ist natürlich dann nicht lokalisiert, erscheint also auch in einem englischen Firefox auf deutsch!

Mit diesen Änderungen kann unser Formular jetzt folgendes:

  1. Namen, E-mail-Adresse und Webseitenadresse automatisch validieren und den Status auf „ungültig“ setzen, wenn ein Feld die Anforderungen nicht erfüllt.
  2. Der Firefox schickt bei mindestens einem ungültig ausgefüllten Formular dieses beim Klick auf den Button nicht ab, sondern gibt eine Fehlermeldung aus und setzt den Fokus auf das Eingabeelement, in dem noch ein Problem besteht. Bei Tests im Safari in Mac OS X Lion zeigte sich, dass dieser das Formular dennoch abschickt, obwohl ungültige Eingaben vorhanden sind. Hier weichen die Implementierungen also voneinander ab

Und zurück zu WAI-ARIA

Und was kann unser Formular noch nicht wieder? Richtig: Die Ausgabe einer Fehlermeldung bei Verlassen eines Eingabefeldes. Dies unterstützen Browser bisher nicht standardmäßig, eine Validierung bei Fokusverlust, die sofort per Fehlermeldung bescheid sagt, wenn etwas nicht in Ordnung ist. Also müssen wir das JavaScript aus dem ursprünglichen Formular wieder einbauen und wie folgt abändern:

  1. Den Namen der function „checkEntryValidity“ in „testIfEntryIsValid“ ändern, weil der ursprüngliche Name im HTML5-Kontext mit einem reservierten Bezeichner kollidiert.
    Die Parameterliste verschlanken. Die Funktion braucht nur noch die ID des zu überprüfenden Elements, weil alles andere von HTML5 erledigt bzw. bereitgestellt wird.
    Die Funktion so abändern, dass:

    1. Keine aria-invalid-Attribute mehr gesetzt werden.
    2. Keine zeichenvergleiche mehr angestellt werden, sondern lediglich das Ergebnis des Funktionsaufrufs checkValidity() ausgewertet wird. checkValidity() gibt true zurück, wenn das Feld einen gültigen Eintrag enthält, sonst false.
    3. Den bisherigen Parameter aMsg ersetzen durch einen Aufruf der Eigenschaft validationMessage des jeweiligen Elements. Diese enthält die Fehlermeldung, die Firefox auch beim Absenden des Formulars generiert und die beim Drüberfahren mit der Maus als Tooltip angezeigt wird. Enthält das Element ein title-Attribut, wird dessen Wert an diese Fehlermeldung angehängt. Ist x-moz-errormessage angegeben, enthält der erste teil von validationMessage diesen Text.

    </li

  1. Den Feldern „name“ und „email“ wieder onBlur-Handler geben, die die Funktion testIfIsEntryValid aufruft und die ID des zu prüfenden Feldes übergibt, damit bei Fokusverlust des Feldes eine Prüfung erfolgt und ggf. ein Alert generiert wird.

Mit diesen Änderungen ist unser Formular nun wieder voll funktionsfähig, besitzt jedoch verbesserte Validierungseigenschaften als vorher. Auf mobilen Geräten werden entsprechende Tastaturen eingeblendet, wenn man die E-Mail- und Webseiten-Adressen ausfüllt.

Zusammenfassung

HTML5 bietet uns also viele Funktionen frei haus, die wir früher mit eigenem JavaScript nachbauen mussten. Der Code wird schlanker. Die Lücke, die HTML5 nicht schließt, ist die Validierung bei Fokusverlust und die Ausgabe der Fehlermeldung. Diese müssen wir weiterhin durch WAI-ARIA realisieren. Wir gehen also zu einem guten Stück von WAI-ARIA-Attributen weg, und das ist auch gut so! Dort, wo es sinnvoll ist und es eine Ergänzung darstellt, nutzen wir es aber weiterhin, um unser einfaches Formular noch benutzerfreundlicher zu gestalten. Wo man kann, sollte man WAI-ARIA also durch HTML5 ersetzen, wenn man moderne Webseiten und -applikationen entwickelt. Dort, wo es Sinn macht oder HTML5 noch Lücken lässt, sollte man WAI-ARIA aber nach wie vor einsetzen!

Sämtliche drei Beispiele sind von dieser Seite verlinkt. Viel Spaß beim Spielen und Nachbauen!

Ich freue mich selbstverständlich über Feedback! Das JS hier ist jedoch absichtlich sehr einfach gehalten, weil es nur das Konzept verdeutlichen soll und keine fertige Lösung darstellt.