Dynamik in Formularen

Dynamische Inhalte, d. h. Inhalte, die sich mit oder ohne Einwirkung des Nutzers verändern, sind für viele Computer-Hilfsmittel ein echtes Problem. Bereits durch ein wenig mit Skripten angereicherten herkömmlichen Webseiten kommen Screenreader oder Lupenprogramme häufig aus dem Tritt, wenn sich Dinge innerhalb einer Seite ändern und diese Änderung nicht im unmittelbaren Fokus des Nutzers bzw. seiner Anwendung ist.

Tags: , , , ,

Stand: 06.09.2007, Autor: tc

Diese Schwierigkeiten sind jedoch im Kern nicht auf die Änderung per Skript zurückzuführen: diese Anwendungen haben vergleichbare Probleme, wenn die Änderungen statisch, d. h. durch das Neuladen der Seite zustande gekommen sind. Das Problem ist also nicht die Dynamik im speziellen, sondern die Änderung im allgemeinen.

Bei Desktop-Anwendungen können sich Nutzer behelfen, indem sie Ihre Hilfsmittel sehr genau auf das Verhalten der häufig benutzten Anwendungen einstellen. Der verbreitete Screenreader JAWS bietet zum Beispiel die Möglichkeit, Anwendungen mit sogenannten JAWS Scripts zugänglich zu machen. Mittlerweile ist um dieses Prinzip herum ein ganzes Biotop von Anbietern entstanden, die solche Scripts für alle möglichen Anwendungen, von Office-Paketen bis zu Skype und iTunes, entwickeln und kostengünstig oder gratis ins Netz stellen.

Für Anwendungen, die im Webbrowser laufen gibt es diese Möglichkeiten (bisher) kaum. Hilfsmittel wie Screenreader, Lupenprogramme usw. sind in den letzten Jahren zwar stark verbessert worden und kommen eher mit Dynamik in Webseiten zurecht, als dies noch vor einigen Jahren der Fall war. Allerdings beziehen sich solche Aussagen immer nur auf die neuesten Versionen der Programme – man kann alleine wegen der teilweise erheblichen Kosten für Updates nicht davon ausgehen, dass mit dem Tag der Veröffentlichung einer neuen Version alle Nutzer sofort umsteigen und damit alle Probleme gelöst sind.

Daher gilt nach wie vor die dringende Empfehlung, zuerst eine vollkommen statische Variante zu entwickeln, bei der die gesamte Logik zunächst nur auf dem Server läuft und die nicht auf clientseitiges JavaScript zwingend angewiesen ist. Dieses kommt erst im zweiten Schritt zum Zuge.

JavaScript: vom Pfui-Wort zum Modetrend

Nachdem JavaScript lange Zeit verpönt war, hat diese clientseitige Skriptsprache in der letzten Zeit eine wahre Renaissance erlebt. Und zu Recht: richtig angewendet kann JavaScript gerade in komplexen Formularen oder Web-basierten Anwendungen den Nutzer unterstützen, Fehlbedienungen verhindern und ihm eine Menge Arbeit und Wartezeit abnehmen.

Mit JavaScript können Sie zum Beispiel Eingaben des Benutzers überprüfen, noch bevor dieser das Formular absendet und auf eine Antwort des Servers warten muss, von dem ein komplett neue Seite geladen wird. Mögliche Anwendungszwecke sind Trefferlisten oder Rechtschreibkorrekturen in Suchmaschinen und bei der Eingabe von Texten, Hinweise, dass bestimmte Kombinationen von Eingaben nicht möglich sind oder die sofortige Validierung von Eingaben mit hoher Fehlerquote. Bei einer Nutzerregistrierung können Sie Ihre Kunden schon während der Eingabe darauf hinweisen, dass ein gewünschter Benutzername bereits vergeben oder das gewählte Passwort zu unsicher ist und Vorschläge zur Korrektur machen.

All dies ist zwar auch ohne aktives Scripting möglich, dies bedeutet jedoch für den Nutzer eine längere Wartezeit und eine weniger unmittelbare Interaktion mit der Anwendung. Mit JavaScript können Sie hingegen Ihr Formular mit Komfortmerkmalen und unterstützenden Funktionen anreichern und so auf die Bedürfnisse von Nutzern mit kognitiven oder Lernbehinderungen reagieren.

Solche Skripte funktionieren jedoch nur, wenn mit der Zugangsart des Benutzers JavaScript tatsächlich ausführt werden kann. Für Fälle, in denen JavaScript ausgeschaltet ist oder nur unzureichend unterstützt wird hilft nur ein sogenanntes »Fallback« auf den Server, der identische Funktion übernimmt. Eine Verlagerung von Logik und Rechenleistung auf den Client sollten Sie daher immer erst dann vornehmen, wenn diese auch auf dem Server bereitgestellt wird.

Vom Schichtenmodell zur Wiener Melange

Schaubild mit der Trennung von Struktur, Präsentation und Verhalten In den guten alten Zeiten des Webdesigns waren die Fronten klar und die Zuständigkeiten ordentlich verteilt: auf dem Server lief die Geschäftslogik, HTML sorgte für strukturierte Inhalte und Funktionen, CSS lieferte die Oberfläche und obendrauf konnte man mit JavaScript noch ein wenig optionalen Komfort mitgeben. Wenn man in diesem Schichtenmodell die Verhaltensschicht wegnimmt, hat man nach wie vor eine ansehnliche und funktionale Seite; nimmt man auch noch CSS weg, so bleibt das reine HTML der Seite – nicht mehr ganz so hübsch, aber funktionabel.

In Zeiten wo Web-basierte Applikationen Aufgaben übernehmen, die früher reinen Desktop-Anwendungen vorbehalten waren, lässt sich diese strikte Trennung nicht mehr länger durchsetzen. Während Angebote wie Google Mail noch eine statische Alternative bieten können, die (auf Kosten der Interaktivität) vollkommen ohne JavaScript auskommt, so ist dies bei der Browser-basierten Tabellenkalkulation (in Deutschland: Google Text & Tabellen) prinzipiell nicht mehr möglich.

Tasse Kaffee mit Milchschaum Wie viele der sogenannten Web 2.0-Angebote beruhen auch diese auf Funktionalitäten, die sich nicht mehr serverseitig nachbilden lassen bzw. ohne JavaScript-Unterstützung nur derart umständlich zu bedienen wären, dass sie niemand nutzen könnte. Der Erfolg solcher Angebote hängt also unmittelbar davon ab, dass die Browser der Anwender sämtliche Web-Standards korrekt unterstützen – was im vorliegenden Fall ausdrücklich JavaScript mit einschließt.

So sollte man nicht mehr JavaScript pauschal für unzugänglich erklären; stattdessen ist die spannende Aufgabe nun herauszufinden, wie aktive und dynamische Inhalte mit den besonderen Bedürfnissen von Menschen mit Behinderung und den Fähigkeiten der Computer-Hilfsmittel in Einklang zu bringen sind. Auch hier hilft, so komisch das klingen mag, der Blick in die BITV – viele dieser Bedürfnisse erschliessen sich, wenn man die Hintergründe für die einzelnen Anforderungen und Bedingungen kennt.

Gängige Funktionen und typische Probleme

Betrachten wir mal einige typische Funktionen von Web-basierten Anwendungen:

  • Inhalte werden dynamisch verändert, mit oder ohne Zutun des Nutzers und ohne dass die Seite bzw. Anwendung komplett neu vom Server geladen wird. Für Nutzer assistiver Programme wie Screenreader und Lupensoftware besteht hier das Problem, dass die Programme Änderungen im Browser unter Umständen nicht bemerken und den Nutzer weder informieren noch zu den Änderungen hinführen können.
    Auch für normalsichtige Nutzer können bei solchen Funktionen eines Web-Angebots Hürden entstehen. Zunächst müssen die geänderten Konzepte im Web2.0 verstanden werden – im Gegensatz zu statischen (Text-) Seiten verlangen Web-basierte Applikationen wesentlich umfassendere Fertigkeiten im Umgang mit Inhalten und Funktionen – für Nutzer mit Lernbehinderungen definitiv eine Barriere. Allerdings: eine statische Alternative scheidet oftmals aus grundsätzlichen Überlegungen aus – ein Börsenticker, der sich nicht selbsttätig aktualisiert ist ein Muster ohne Wert.
  • Statische Inhalte werden erst durch Interaktion zu dynamischen Elementen. Ein Beispiel für diese Technik findet sich in der Foto-Community flickr: hochgeladene Bilder werden zunächst mit den Bezeichnungen abgelegt, mit denen die Digitalkamera die Bilder benannt hat (DSC_1234.jpg); flickr verwendet diese für die korrekt als Überschriften (<h2>) ausgezeichneten Titel der Bilder. Klickt man diese Überschriften mit der Maus an, so werden diese per Skript in ein Formular verändert. Hier kann man nun den Titel des Bildes ändern und diese Änderung speichern oder verwerfen:
    Bildschirmfoto von flickr mit der zuvor beschriebenen Funktionalität
    Bildschirmfoto von flickr mit der zuvor beschriebenen Funktionalität
    Das Problem bei dieser Form der Interaktion beginnt bereits mit der Tatsache, dass diese Überschriften in den weitaus meisten Browsern nicht per Tastatur erreichbar sind, es sei denn man verwendet das für Überschriften (H1-6) eigentlich nicht erlaubte tabindex-Attribut und riskiert so, dass der Code nicht mehr validiert.
  • Anwendungen bilden Funktionen nach, die in HTML (bisher) nicht vorgesehen sind. Für einfache Zwecke reicht der begrenzte Satz von Formularelementen, den HTML bietet, in der Regel vollkommen aus. In Web-basierten Anwendungen stößt man jedoch schnell an die Grenzen dieser Markup-Sprache, die bekanntlich nie für so etwas gedacht war, und sehnt sich nach einer schnelleren Standardisierung von HTML5 oder XForms. So lange bleibt dem Webentwickler nichts anderes übrig, als Funktionen bzw. Elemente wie Fortschrittsbalken, Schieberegler, Tri-State-Checkboxen u.v.m. mit den vorhandenen Mitteln nachzubilden.
    Und genau hier beginnt das Problem für viele Nutzungsszenarien, die für Menschen mit Behinderungen typisch sind: Viele dieser Elemente sind zum Beispiel nicht per Tastatur zu bedienen, da es sich nicht um echte Interface-Elemente handelt, sondern beispielsweise nur um leere DIV und SPAN, die per Maus und JavaScript manipuliert werden.
    Hilfsmittel sind darauf angewiesen, dass es in der jeweiligen Accessibility-API des Betriebssystems ein entsprechendes Pendant zu den Formular- und Kontrollelementen gibt, um die Bedienbarkeit zu gewährleisten. So wird z. B. ein Fortschrittsbalken in echten Desktop-Anwendungen (wenn's bei Uploads, komplexen Abfragen oder Berechnungen mal wieder etwas länger dauert) im Screenreader erkannt; die Werte werden in Intervallen wiedergegeben (20%, 30%, 40%, …). Bildet man diese Funktion (zumindest optisch) mit den Bordmitteln von HTML , CSS & JavaScript nach, so mag dies zwar wie ein Fortschrittsbalken aussehen, für einen Screenreader ist dies jedoch eine Ansammlung sinnbefreiter leerer Elemente.

Ein Blick in die Zukunft: WAI-ARIA

Alle verbreiteten Betriebssysteme bzw. grafischen Benutzeroberflächen (GUI) verfügen mittlerweile über sogenannte Accessibility APIs (Application Programming Interfaces). Über diese Schnittstellen werden Hilfsmittel wie Braillezeilen, Lupenprogramme und Screenreader, aber auch alternative Eingabeformen mit den nötigen Informationen darüber versorgt, was gerade auf dem Bildschirm geschieht und wie Funktionen zu bedienen sind.

Für Windows ist dies die Microsoft Active Accessibility-Schnittstelle (MSAA), unter Linux gibt es das Gnome Accessibility Toolkit (ATK), bei Apple ist es das Accessibility-API for Cocoa und auch Sun hat mit dem Java Accessibility-API eine entsprechende Schnittstelle. Um über diese Schnittstellen kommunizieren zu können und dem Nutzer den Zugriff zu gewährleisten brauchen Ihre Elemente klar festgelegte Rollen und Zustände (Roles = Was ist dieses Element und was kann ich damit machen? bzw. States = In welchem Zustand befindet sich das Element?)

Prüftool in Firefox zur Analyse verschiedener JavaScript-Funktionen Im Falle statischer HTML-Seiten mit Strukturelementen, Links und einfachen Formularelementen sind die Rollenverteilungen und Zustände klar verteilt und sollten somit kein Problem für die assistiven Hilfsmittel darstellen. Der Browser teilt die Informationen über die jeweiligen Elemente und ihre Zustände (gedrückt, angekreuzt, besucht) über das Accessibility-API mit.

Wenn nun jedoch per HTML , CSS & JavaScript Bedienelemente nachgebildet werden, die über den begrenzten Satz von HTML hinausgehen, eröffnet sich das Problem, dass diese »Nachbauten« vom Accessibility-API nicht verstanden werden und somit auch nicht an ein Hilfsmittel weitergereicht werden können.

Die WAI-ARIA-Roadmap (sperriger Name: »World Wide Web Consortium Web Accessibility Initiative Accessible Rich Internet Applications Roadmap«) zeigt einen Ausweg auf, wie dies in Zukunft zu vermeiden ist. Die in der Entwicklung befindliche Spezifikation wird zum Zeitpunkt dieser Veröffentlichung bereits von den aktuellen Versionen der Screenreader Window Eyes und JAWS sowie von Firefox ab v.1.5 unterstützt, weitere Hilfsmittel und Browser werden in Zukunft sicher folgen. Bis dahin haben diese Techniken jedoch nur experimentellen Charakter – darauf verlassen können Sie sich nur in kontrollierten Umgebungen, wo Sie als Anbieter einen Einfluss auf die verwendeten User Agents haben, wie z. B. in Intranets.

Was haben wir gelernt?

Anders als bei klassischen Webseiten, die sich an der statischen Dokumenten-Metapher orientieren, lassen sich Barrieren in Web-basierten Anwendungen nur schwer vorhersagen und somit kaum in ein abstraktes Regelwerk für systematische Tests einsortieren. Selbst wenn Sie für Ihre Anwendung eine JavaScript-Library wie Dojo verwenden, bei der die Accessibility eine wichtige Rolle spielt, ist noch lange nicht garantiert, dass das Ergebnis auch tatsächlich barrierefrei zu nutzen ist. Um dies sicherzustellen kommen Sie nicht um Tests mit echten Nutzern herum. Daher dreht sich in der nächsten Folge alles um das »Testen von Formularen und Web-basierten Anwendungen«.