accessBlog:

14 Jun 2006

In dieser Woche dreht sich alles um aktuelle Trends in der Webentwicklung und wie man diese mit den Prinzipen der Barrierefreiheit vereinbaren kann. Zurzeit machen eine ganze Reihe neuer Schlagwörter die Runde, mit denen umschrieben wird, wie wir alle in Zukunft das Web wahrnehmen und nutzen sollen. Web two point oh oder Web Zwei Punkt Null, das Schreib-/Lese-Web, Software als Service oder auch technische Details wie Ajax sind ein paar Beispiele, mit denen wir uns heute mal etwas intensiver beschäftigen wollen.

Zum Mithören:

Podcast vom 14. Juni 2006 (.mp3, 16′43″, ca. 19 MB)

Zum Mitlesen:

Die Abschrift des Podcasts

Kommentare zu dieser Meldung: 1

Permalink Jan Eric Hellbusch meinte am 19.06.2006:

Ein schöner Beitrag und eine schöne Übersicht zur Thematik.

Zur Problematik des nicht möglichen multiplen Fokus für Screenreader habe ich eine Anmerkung, die u.U. helfen kann. Zumindest sollte es.

Es geht vor allem um die Benachrichtigung von Screenreader-Nutzern über einen Fehler. Die vorgeschlagene Lösung löst nicht unbedingt das Problem, dass sich auf einer Seite mehrere Inhalte ändern und der Screenreader dies nicht "mitkriegt". Vielmehr geht es um die Benachrichtigung eines Nutzers, wenn beispielsweise die Eingabe in einem Formularelement fehlerhaft war.

1. Man stelle sich vor, ein Nutzer müsse ein Paar Daten in ein Formular eintragen. Für die jenigen Eingaben die überprüfbar sind (gültige E-Mail-Adresse, ...) kann eine Plausibilitätsprüfung vorgenommen werden.

2. Bei einem Fehler wird in vielen AJAX-Anwendungen eine gelbe Fahne angezeigt. Diese Information ist visuell und muss Bedingung 2.1 erfüllen. D.h. sie darf nicht alleine per Farbe gekennzeichnet sein, braucht vielmehr ein border-Attribut o.ä. (visuell) und Inhalt (strukturell). Gerade letzteres ist etwas schwierig, denn der Screenreader-Nutzer ist noch nicht informiert!

3. Wie erfährt ein Screenreader-Nutzer, dass ein Fehler festgestellt wurde? Im Beitrag wurde auf ein Alert hingewiesen. Das ist natürlich möglich und sollte überall, wo JavaScript aktiviert ist, funktionieren. Aber wenn man sich dagegen entscheidet, müssen Alternativen ausprobiert werden. Die gelbe Fahne könnte mit Inhalt aufgefüllt werden, aber der Fokus des Screenreaders ist (noch) nicht da und den Fokus "klauen" ist vermutlich auch nicht der richtige Weg.

4. Wenn die Plausibilitätsprüfung erst dann erfolgt, wenn der Fokus das entsprechende Feld verlässt, dann ist unsicher, wo der Fokus hingewandert ist: im nächsten Feld bzw. auf dem nächsten Link per Tab? Auf dem vorherigen Feld mit Umschalt+Tab? Oder irgendwo auf der Seite oder in der Adresszeile per Tastaturkürzel oder gar Mausklick?

5. Um die Prüfung aller Eventualitäten zu vermeiden, kann mit onblur und bei Feststellung eines Fehlers (Plausibilitätsprüfung) ein JavaScript-Array erzeugt bzw. mit der Fehlermeldung ergänzt werden.

- es wird ein Array fehlermeldungen erzeugt.
Das Array - fehlermeldungen enthält soviele Einträge, wie es Formularelemente auf der Seite gibt.
- Für jeden Eintrag wird in der Seite ein LABEL-Element erzeugt; wichtig ist die Verknüpfung mit den einzelnen Formularelementen mit for/id. Weil diese Information für Screenreader-Nutzer gedacht ist, können die LABELs ausserhalb des sichtbaren Fensterbereiches positioniert werden.
- Bei Feststellung eines Eingabefehlers wird die Fehlermeldung in jedes LABEL geschrieben. Diese können bei weiteren Fehlern ergänzt werden bzw. bei Korrektur auch wieder entfernt werden. Es sollte jedoch sicher gestellt werden, dass die Einfügen- und Entfernen-Aktionen jeweils in alle dieser LABELs vorgenommen werden.
- Sobald der Screenreader-Nutzer auf ein anderes Formularelement gelangt, wird das LABEL mit der Fehlermeldung mit ausgelesen (z.B. "Bei der E-Mail-Adresse wurde ein Fehler festgestellt.").
- Die Information kann auch in das BUTTON-Element hineingeschrieben werden (sofern anwendbar). Mit Text,der ausserhalb des sichtbaren Bereichs positioniert wird, könnte eine Redundanz vermieden werden. "Sicherer" ist aber die Verwendung der unsichtbaren LABELs und des sichtbaren Textes im BUTTON-Element. Dann haben alle was davon - auch diejenigen, die vielleicht ein gelbes Fähnchen nicht sehen, weil es Bedingung 2.1 nicht erfüllt oder weil es sich ausserhalb des sichtbaren Bereichs (z.B. in Vergrößerungssystemen und u.U. auch Bildschirmlupen) befindet.

Kommentar abgeben?

 


Tipp: HTML ist nicht zulässig; Webadressen können Sie so: [url=domain.de]Text[/url] eingeben.