Dynamik in Formularen

Teil 4 unserer Serie zu barrierefreien Formularen

Autor: tc

Tags: , , , , ,

Anforderungen für barrierefreies JavaScript

In den Anfangstagen des Web waren die Auswirkungen nicht-barrierefreier Formulare noch nicht so gravierend: es gab nur eine sehr begrenzte Anzahl möglicher Formular-Elemente. Die Anzahl der Fehler, die ein Entwickler machen konnte, war schon deswegen eher überschaubar. Außerdem hatten Hilfsmittel wie Screenreader eingebaute Reparatur-Mechanismen, um die gröbsten Schnitzer auszubügeln.

Dass diese relativ entspannten Zeiten vorbei sind, erkennt man alleine schon am Umfang der Literatur zu diesem Thema: Das Kapitel »Forms and interaction« aus Joe Clarks Buch »Building Accessible Websites« von 2002 hatte man in einer guten Stunde durch und war damit auf dem damals aktuellen Stand der Technik. Seitdem hat sich die Komplexität von web-basierten Formularanwendungen vervielfacht und somit auch die Dinge, die man als Entwickler berücksichtigen muss. Dass die Entwicklung barrierefreier Formulare immer komplexer geworden ist, erkennt man am Umfang der Dokumentation: während die WCAG 1 noch mit einigen Seiten (mehr schlecht als recht) erklärender Texte auskam, so erstrecken sich die Techniken zur Umsetzung der WCAG 2.0 ausgedruckt auf über fünfhundert Seiten (hier die Deutsche Übersetzung der Techniques).

Dynamische Inhalte, d.h. Inhalte, die sich mit oder ohne Einwirkung des Nutzers verändern, sind für viele Computer-Hilfsmittel ein echtes Problem. Schon wenn herkömmliche statische Webseiten mit Skripten angereichert werden, 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, führt dies Regelmäßig zu Problemen in der Nutzbarkeit. Diese Schwierigkeiten sind jedoch im Kern nicht auf die Änderung per Skript zurückzuführen, denn die Hilfstechnologien 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.

Besonders problematisch aus Sicht der Nutzer von Hilfsmitteln sind Formulare, bei denen Inhalte dynamisch nachgeladen werden. Viele Werkzeuge und selbst modernste Screenreader haben je nach Art der Umsetzung Probleme damit, Veränderungen in einer Seite zu erkennen und dem Nutzer entsprechend zu präsentieren – teilweise werden Änderungen komplett ignoriert, oder sie werden wie ein Neuladen der Seite behandelt und der Screenreader beginnt wieder ganz oben auf der Seite.

Bei Desktop-Anwendungen können sich Nutzer oftmals damit 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 Skripte 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 nun, auch dank Techniken wie WAI-ARIA, eher mit Dynamik in Webseiten zurecht. Allerdings beziehen sich solche Aussagen immer nur auf die neuesten Versionen der Programme – man kann alleine wegen der teils 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 Empfehlung, zuerst eine statische Variante eines Formularprozesses zu entwickeln, bei der die gesamte Logik zunächst nur auf dem Server läuft und die nicht zwingend auf clientseitiges JavaScript angewiesen ist. Dieses kommt erst im zweiten Schritt zum Zuge. Positiver Zusatznutzen: So bedienen Sie auch die je nach Meßmethode 1 bis 6% Nutzer, bei denen JavaScript bewusst abgeschaltet ist oder aus anderen Gründen nicht ausgeführt werden kann. Anbietern, die noch der alten BITV 1 unterliegen bleibt zudem nichts anderes übrig, da diese in Anforderung 6 verlangt:

»Internetangebote müssen auch dann nutzbar sein, wenn der verwendete Benutzeragent neuere Technologien nicht unterstützt oder diese deaktiviert sind.«

JavaScript: vom optionalen Sahnehäubchen zur unverzichtbaren Zutat

Nachdem JavaScript lange Zeit verpönt war und viele sinnvolle Anwendungen de facto verboten waren, hat diese clientseitige Skriptsprache in den letzten Jahren 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. JavaScript kann damit gerade für Nutzer mit Behinderung Barrieren abbauen.

Mit JavaScript können Sie zum Beispiel Eingaben des Benutzers überprüfen, bevor er das Formular absendet. Ohne clientseitige Prüfung müsste er auf eine Antwort des Servers warten, der eine komplett neue Seite erstellen und ausliefern muss. Mögliche Anwendungszwecke für diese Technik sind zum Beispiel Trefferlisten oder Rechtschreibkorrekturen in Suchmaschinen und bei der Eingabe von Texten, Hinweise, dass bestimmte Kombinationen von Eingaben nicht möglich sind oder die sofortige Überprüfung 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 Ihr Formular hingegen 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 ausgefü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 Funktionen ü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.

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 eine weiterhin funktionierende Struktur, bestehend aus dem absolut notwendigen Grundgerüst der Seite oder der Anwendung.

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 HTML-Alternative anbieten, die auf Kosten der Interaktivität ohne JavaScript auskommt, so ist dies bei der browser-basierten Tabellenkalkulation Google Text und Tabellen prinzipiell nicht mehr möglich. Wie viele der sogenannten Web2.0-Angebote beruht auch sie auf Funktionalitäten, die sich nicht mehr serverseitig nachbilden lassen. Ohne JavaScript-Unterstützung wären sie nur derart umständlich zu bedienen, dass sie niemand nutzen könnte. Der Erfolg solcher Angebote hängt also unmittelbar davon ab, dass die Browser der Anwender sämtliche Webstandards 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 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 der Blick in die WCAG 2.0 – viele dieser Bedürfnisse erschließen sich besser, wenn man die Hintergründe für die einzelnen Prinzipien, Richtlinien, Erfolgskriterien und Techniken kennt.

Folgerichtig gehen die WCAG 2 dieses Thema nun endlich wesentlich entspannter an: statt JavaScript pauschal für unzugänglich zu erklären wird für den Einsatz lediglich die Bedingung aufgestellt, dass die Technik nachweislich mit verbreiteten Web Clients und Hilfsmitteln nutzbar ist:

»Die Nutzung einer Technik auf eine die Barrierefreiheit unterstützende Art und Weise bedeutet, dass sie mit assistierenden Techniken (AT) und den Barrierefreiheitsfunktionen von Betriebssystemen, Browsern und anderen Benutzeragenten funktioniert.«

Gängige Funktionen und ihre typischen Probleme

Betrachten wir 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 assistierender Programme wie Screenreader und Lupensoftware besteht hier das Problem, dass die Programme Änderungen im Browser oft nicht bemerken und den Nutzer weder informieren noch zu den Änderungen hinführen können. Teilweise verhalten sich Hilfsmittel bei Veränderungen in einer Seite so, als sei die Seite komplett neu geladen worden und beginnen z.B. wieder ganz oben an vorzulesen.
  • 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 Web 2.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.
  • Dabei entstehen Barrieren nicht nur bei der Verwendung von spezialisierten Hilfsmitteln – manche dynamische Techniken führen auch schon bei Nutzungsarten zu Problemen, die wesentlich häufiger anzutreffen sind. So führt der Trend zu endlos lang scrollenden Seiten wie z.B. bei Twitter dazu, dass weite Teile des Interfaces per Tastatur schlichtweg nicht mehr erreichbar sind.
    Screenshot: Infinite-Scroll-Interface bei twitter
    Für Twitter-Nutzer gibt es nun zum Glück mit Accessible Twitter ein alternatives Interface – allerdings wäre es aus Sicht der Betroffenen wünschenswerter, wenn das Original zugänglich wäre.

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 das Textinputfeld eines Formulars verändert. Hier kann man nun den Titel des Bildes ändern und diese Änderung speichern oder verwerfen:
  • Eigentlich eine gute Idee. Das Problem bei dieser Form der Interaktion beginnt jedoch bereits mit der Tatsache, dass diese Überschriften in den 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. Hinzu kommt das Problem der »Entdeckbarkeit« (in der englischsprachigen Fachliteratur »Discoverability« genannt): welches Element einer Seite tatsächlich auf diese Art editierbar ist erfährt der Nutzer erst durch Ausprobieren.

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 nie für solche Zwecke gedacht war. Man sehnt sich nach einer schnelleren Standardisierung von HTML5 oder XForms. Bis dahin 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 verschoben werden.
  • Einerseits haben wir also das Problem der Geräteunabhängigkeit in der Bedienung, und darüber hinaus sind Hilfsmittel auch noch 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 es 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 HTML4, CSS & JavaScript nach, so mag dies zwar wie ein Fortschrittsbalken aussehen, für einen Screenreader ist dies jedoch eine Ansammlung sinnfreier leerer Elemente. Hier werden Sie also für die Herstellung der Barrierefreiheit nicht umhin kommen, entweder auf HTML5 und seine erweiterten Möglichkeiten zu setzen, oder die Funktionen bei einer älteren Codebasis (HTML4/XHTML1) per WAI-ARIA nachzurüsten.

Ein Praxisbeispiel: Formularbereiche ein- und ausblenden

Bei komplexen Formularen kann es sinnvoll sein, nur die im Kontext eines aktuellen Arbeitsschrittes relevanten Bereiche eines Formulars anzuzeigen. Banken und Finanzinstitute z.B. haben oft Formulare mit einer Reihe von Variablen, und welche Daten der Nutzer eingeben muss hängt unmittelbar davon ab, welche Variable der Nutzer auswählt: möchte er Geld überweisen oder einen Kredit beantragen? Oder will er sein Auto oder sein Haus versichern?

Aus Sicht der allgemeinen Gebrauchstauglichkeit scheint es sinnvoll, dem Nutzer nur die Teile der Formulare zu zeigen, die im vorliegenden Fall relevant sind. Dies kann insbesondere für Nutzer mit kognitiven Behinderungen oder Lernschwierigkeiten hilfreich sein, aber auch für Nutzer mit wenig Computer-Erfahrung.

Nun kann man eine Kombination aus HTML, CSS und JavaScript verwenden, um verschiedene Bereiche eines Formulars ein- und auszublenden. Gerade hier sollte man sehr sorgfältig vorgehen um sicherzustellen, dass neu eingeblendete Bereiche zum Beispiel für Screenreader-Nutzer zugänglich sind. Gleichzeitig sollte verhindert werden, dass das Programm bei einer Änderung des Inhalts wieder zum Beginn der Seite springt.

Hier hilft die Lektüre der Dokumentation zu den WCAG 2.0: die Technik SCR26 wird empfohlen, um das Erfolgskriterium 2.4.3 – Fokus-Reihenfolge – zu erfüllen:

»SCR26: Einfügen von dynamischen Inhalten in das Document Object Model unmittelbar anknüpfend an sein auslösendes Element«

Das W3C erklärt die Technik wie folgt:

»Diese Technik fügt neuen Inhalt in das DOM unmittelbar nach dem Element, das aktiviert wurde, um das Skript auszulösen, ein. Das auslösende Element muss ein Link oder eine Schaltfläche sein und das Skript muss von seinem onclick-Event aus aufgerufen werden. Diese Elemente sind nativ fokussierbar und ihr onclick-Event ist geräte-unabhängig. Der Fokus bleibt auf dem aktivierten Element und der neue Inhalt, dahinter eingefügt, wird sowohl in der Tabreihenfolge als auch in der Lesereihenfolge der Screenreader der nächste Punkt.

Beachten Sie, dass diese Technik bei synchronen Aktualisierungen funktioniert. Bei asynchronen Aktualisierungen (manchmal AJAX genannt) wird eine zusätzliche Technik benötigt, um die assistierende Technik darüber zu informieren, dass der asynchrone Inhalt eingefügt wurde.«

Das folgende Formular enthält einen sich verändernden Bereich zur Auswahl einer Eissorte, der je nach Auswahl der Radiobuttons mit unterschiedlichen Inhalten befüllt wird. Wenn der Radiobutton »Hörnchen« ausgewählt wird, bekommt der Nutzer die Abfrage der Größe zusätzlich zur Geschmacksrichtung, bei der Auswahl »Becher« entfällt die Größenabfrage. Der Code in der Beispieldatei eissorten.html ist in aktuellen Versionen der Screenreader JAWS und Window Eyes getestet:

Screenshot: Formular mit ein- und ausblendbaren Bereichen

Noch ein Praxisbeispiel: Auswahloptionen ändern

Manche Formulare enthalten eine Reihe von Auswahlmenüs auf Basis des SELECT-Elements, und je nach Auswahl ändert sich der Inhalt weiterer Formularelemente. Dieses Szenario wird unter anderem in Richtlinie 3.2 der WCAG 2.0 behandelt, wo es heißt:

»3.2.5 Änderung auf Anfrage: Änderungen des Kontextes werden nur durch Benutzeranfrage ausgelöst oder es gibt einen Mechanismus, um solche Änderungen abzuschalten.«

Das WCAG 2.0 Erfolgskriterium 3.2.5 deckt eine ganze Reihe von möglichen Barrieren ab und listet Techniken zu ihrer Vermeidung auf. Im Zusammenhang mit der Benutzung solcher SELECT-Menüs wird die folgende Technik empfohlen:

»SCR19: Benutzung eines onchange-Events auf einem ausgewählten Element, ohne eine Änderung des Kontextes auszulösen«

SCR19

Vergleichbare Vorgaben finden sich auch im Prüfverfahren des BIENE-Wettbewerbs:

»18. Änderungen von Teilbereichen einer Bildschirmseite werden sinnvoll eingesetzt, angekündigt und sind durch die Nutzerin / den Nutzer kontrollierbar.«

Kriterium 18

»19. Jegliche Funktion der Seite ist auch über die alleinige Verwendung der Tastatur in einer schlüssigen Reihenfolge zu erreichen, wobei die jeweils ausgewählte Funktion in der Standardansicht gut sichtbar ist.«

Kriterium 19

Das folgende Beispiel enthält zwei SELECT-Elemente: »Kontinent« und »Land«. Wenn ein Kontinent ausgewählt wird, z.B. »Nordamerika«, dann werden die möglichen Länder für diesen Kontinent eingeblendet (Kanada, Mexiko & USA). Wenn ein anderer Kontinent ausgewählt wird, dann wird die folgende Länderauswahl automatisch geändert und stellt nun die eine andere Liste von Ländern zur Auswahl (Deutschland, Frankreich, Italien, …).

JavaScript wird hier benutzt, um die angebotenen Auswahlmöglichkeiten im zweiten SELECT auf Basis der Auswahl im ersten SELECT zu verändern. Der Code in der Beispieldatei laenderauswahl.html mit dem benötigten HTML, CSS und JavaScript ist in aktuellen Versionen von JAWS und Window Eyes getestet (Beispiele adaptiert mit freundlicher Erlaubnis von Roger Hudson). Der Vollständigkeit halber sollten Sie dann noch Vorkehrungen für das Szenario treffen, dass JavaScript nicht ausgeführt werden kann, z.B. durch ein statisches Fallback mit allen verfügbaren Optionen.

Theorie der Praxis und Praxis der Theorie

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 auch 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.

Sie werden also nicht umhin kommen, Ihre Formulare einem Praxistest durch Nutzer verschiedener Hilfsmittel zu unterziehen. Gerade wenn man moderne Techniken wie HTML5, WAI-ARIA und unaufdringliches JavaScript einsetzt wird es auch in den neuesten Versionen der Hilfsmittel zu Fehlern kommen. Um ein konkretes Beispiel zu geben: Sie können sich nicht darauf verlassen, dass Ihr Code in allen möglichen Browser- & Hilfsmittel-Konfigurationen wie gewünscht funktioniert. Es gibt eine ganze Reihe empfehlenswerter Techniken, die zum Beispiel in JAWS 10 zusammen mit Internet Explorer 8 ohne negativen Befund einen Test passieren, nimmt man JAWS 10 zusammen mit Firefox, dann funktioniert es auf einmal nicht mehr (und auch der umgekehrte Fall ist möglich). Eine gute Hilfe ist in solchen Fällen (neben Tests mit echten Nutzern) die Testreihe »Set of ARIA Test Cases« bei CodeTalks.org – hier finden Sie erwartete und tatsächlich eingetretene Testergebnisse für typische Anwendungsfälle von Web-basierten Widgets.

Um die Barrierefreiheit wirklich sicherzustellen dreht sich in der nächsten Folge alles um das »Testen von Formularen und web-basierten Anwendungen«.