Testen von Formularen und Web-basierten Anwendungen

Bereits bei einfachen Formularen oder Mischformen aus Dokumenten- und Formular- bzw. Anwendungstypen stimmt diese Aussage jedoch nicht mehr: hier ist man noch stärker auf die Beobachtung echter Nutzer angewiesen. Technische Hürden lassen sich zwar auch im Web 2.0 mit maschineller Unterstützung testen; so bietet die YUI Library sogar ein eigenes Test-Framework, das JavaScript-basierte Web-Anwendungen gegen die Implementierungen in allen halbwegs standardkonformen Browsern testet. Solche Tests können jedoch nur verhindern, dass man per JavaScript den Browser des Nutzers »abschiesst« – was dann tatsächlich in Screenreader & Co. ankommt können Sie nur gemeinsam mit Nutzern solcher Programme herausfinden.

Dabei kann man nur dringend davon abraten, als Entwickler selbst mit einem Screenreader zu testen. Zum Einen läuft man so Gefahr, das Thema Accessibility einzig und allein auf den fast schon sprichwörtlichen »blinden Nutzer mit JAWS« zu reduzieren; zum Anderen sind solche Hilfsmittel schon fast Expertensysteme, bei denen man wochenlange Einarbeitung braucht, um zumindest die nötigsten Tastaturbefehle verinnerlicht zu haben. Ein salopper Test bringt daher im Zweifelsfall kaum brauchbare oder im Ernstfall sogar falsch positive Ergebnisse.

Testen, testen, testen und immer an den Nutzer denken …

Diese Warnhinweise bedeuten natürlich nicht, dass Sie Ihre Webanwendung gar nicht mehr testen sollten, im Gegenteil! Die Tests, die Sie bereits während der Entwicklung eines Angebots selber durchführen können sind sogar recht simpel und brauchen nicht mehr als ein paar Browser und verschiedene Firefox-Erweiterungen.

In unserer »BITV-Reloaded«-Serie hatten wir für die dort beschriebenen Tests die »Web Developer Toolbar« empfohlen; bei diesen Tests können Sie sich hingegen von der »Firefox Accessibility Extension« der University of Illinois unterstützen lassen. Die neueste Version dieser Erweiterung unterstützt bereits den zurzeit noch in der Entwicklung befindlichen WAI-ARIA-Standard (Accessible Rich Internet Applications) und ist somit gerade für das Testen von Web-basierten Anwendungen interessant. Neben den auch in anderen Toolbars zu findenden Optionen zum an- und abschalten bestimmter Dinge lassen sich mit dieser Erweiterung auch selektiv bestimmte JavaScript-Events unterdrücken. Zudem erfährt man eine Menge über verwendete Events und, sofern vorhanden, über Roles and States von Elementen, also Rollen und Zustände von Bedienelementen und DHTML-Widgets im Sinne der WAI-ARIA.

Der Minimaltest

Für eine detaillierte Beschreibung von Barrieren und wie man sie aufspürt legen wir Ihnen nochmals unsere »BITV-Reloaded«-Serie nahe. An dieser Stelle nun einige Tipps, wie Sie Ihre Formulare mit ein paar kurzen Tests überprüfen können:

Sind alle Inhalte und Funktionen per Tastatur erreichbar und bedienbar?

Legen Sie die Maus beiseite und bewegen Sie sich ausschließlich per Tastatur durch Ihr Angebot. Im Gegensatz zu reinen Textseiten, wo die Navigation per Tastatur je nach Browser nur mit einem begrenzten Satz von Tasten funktioniert und Formularelemente automatisch auch per Tastendruck zugänglich sind, können in Web-basierten Applikationen weitere Tasten wie Leertaste, Escape, Control, Alt und Command mit Funktionen belegt sein. Achten Sie bei Ihren Tests auch darauf, dass diese nicht nur funktionieren, sondern auch irgendwo erklärt sind!

Sind alle Label korrekt verknüpft?

Für diesen Test dürfen Sie die Maus nun wieder zur Hand nehmen: klicken Sie auf sämtliche Labels Ihrer Formulare. Achten Sie besonders bei Radiobuttons und Checkboxen, dass die jeweils korrekten Elemente markiert werden und nicht irgendwelche anderen – dann haben Sie id- oder for-Attribute falsch gesetzt und müssen diese korrigieren. Ein Nutzer, der auf Tastaturbedienung angewiesen ist hat keine Chance, ein nicht korrekt zugeordnetes Element über sein Label zu bedienen – ein Fehler, den kein Validator bemerken kann und den Sie nur durch tatsächliches Ausprobieren finden können.

Werden durch Navigationsbewegungen Formulare ungewollt verändert oder sogar abgeschickt?

Ein häufiger Fehler ist, Formularelemente mit JavaScript 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 schlichtweg unmöglich machen. Eine detailliertere Diskussion dieser Barrieren finden Sie in unserer »BITV Reloaded«-Serie bei Anforderung 9, Bedingung 9.3.

Die wohl am meisten verbreitete Anwendung dieser Technik sind Drop-down-Menüs, die gerne genommen werden um Platz zu sparen und die Navigation bzw. die Anzahl der Optionen weniger komplex erscheinen zu lassen. In den weitaus meisten Fällen wäre hier ein klassischer Hyperlink das semantisch korrektere Element, da es sich streng genommen ja um Hyperlinks handelt. Diese hätten zudem den Vorteil, dass Hyperlinks nur einen Klick bzw. Tastendruck benötigen. Eine Liste von Hyperlinks ist zudem einfacher zu erfassen. Drop-down-Menüs bedeuten für den Nutzer jedoch mehr Lernaufwand und Mühe in der Bedienung: ein Drop-down-Menü muss man ansteuern und aufklappen, um alle Optionen zu sehen. Selbst dann sieht man je nach Anzahl der Optionen oder je nach Browser nicht alle Optionen auf einen Blick und muss die Liste herunterscrollen.

Bei Ihren Tests sollten Sie also darauf achten, dass Funktionen, die letztendlich nichts anderes als Hyperlinks sind, auch als Hyperlinks umgesetzt wurden.

Ist alles auch ohne Farbe erkennbar?

Achten Sie insbesondere bei Fehlermeldungen etc. drauf, dass diese nicht alleine durch farbliche Markierungen gekennzeichnet sind. Wenn Sie beim Testen auf Fehlermeldungen stoßen (z. B. durch den unvollständigen Versand eines Formulars), dann benötigen diese zusätzliche Struktur- und Gestaltungselemente jenseits von roter Hintergrundfarbe, um wirklich in allen Ausgabeformen wahrnehmbar und damit nutzbar zu sein. Gleiches gilt sinngemäß nicht nur für die Meldung, sondern auch für die Markierung des Ortes des Fehlers.

Für manche Formen der Sehbehinderung bietet das Windows-Betriebssystem sogenannte Kontrastmodi. Typischerweise wird durch diese der Bildschirminhalt invertiert bzw. mit benutzerdefinierten Farben dargestellt, also zum Beispiel beiger Text auf schwarzem Hintergrund, um eine Blendwirkung zu vermindern. Diese Kontrastmodi haben aus Designer-Sicht eine unangenehme Eigenschaft: während alle CSS-Positionierungen beibehalten werden, verschwinden sämtliche Hintergrundfarben und vor allem auch Hintergrundbilder! Wenn Sie also Warnhinweise per CSS (z. B. .fehler {background-image: warnung.gif;}) realisiert haben, so sind diese für viele sehbehinderte Nutzer nicht mehr wahrnehmbar, weil schlichtweg nicht vorhanden. Zur Vermeidung sollten Sie daher Ihre gesamte Anwendung unbedingt einmal vollständig im Windows-Kontrastmodus durchtesten.

Strittige Punkte

Es gibt einige Punkte, bei denen selbst unter Experten und Betroffenen keine Einigkeit herrscht, ob sie sinnvoll sind, oder ob man diese Techniken auslassen kann und trotzdem noch ein barrierefreies Angebot hat. Ein übermäßiger Einsatz aller in HTML vorgesehenen Hilfen zur Orientierung und Navigation kann sogar für manche Nutzergruppen dazu führen, dass eine Seite weniger benutzbar wird. Das ist insbesondere dann der Fall, wenn die eingesetzte Technik einen übermäßigen Lernaufwand erfordert, der die Vorteile der Technik aufwiegt oder sogar übersteigt. Ein solcher Kandidat sind die von den gängigen Vorgaben für Barrierefreie Internetauftritte verlangten Tastaturkürzel zur Navigation, die sogenannten Accesskeys.

Accesskeys – Ja oder Nein?

Die Idee hinter dem accesskey-Attribut in HTML ist eigentlich bestechend einfach: Wie in den gewohnten Desktop-Anwendungen kann man auch in HTML-Seiten Tastaturkürzel definieren, durch die bestimmte Aktionen ausgelöst werden. In HTML können diese Attribute einer Vielzahl von Elementen zugewiesen werden und somit unterschiedlichste Aktionen auslösen. Wie alle Attribute hat auch dieses einen Wert, der in Form von einzelnen Buchstaben oder Zahlen angegeben wird. Dieses Zeichen entspricht der Taste, die der Benutzer zusammen mit einer oder mehreren weiteren Tasten drücken muss, um die gewünschte Aktion auszulösen. Und genau da beginnt das Problem:

Unter den Browserherstellern herrscht keine Einigkeit, welche Tasten zusätzlich neben dem im accesskey angegebenen Zeichen zu drücken sind. Unter Windows sind dies im Internet Explorer die Alt-Taste + Accesskey + Enter, im Mozilla Alt-Taste + Accesskey ohne Enter, in Opera sind es Shift + Esc + Accesskey (ohne Enter). Auf anderen Plattformen wie dem Apple Macintosh sind es statt der Alt-Taste die Ctrl-Taste (auch ohne Enter), Opera macht hier wieder die Ausnahme mit Shift + Esc und so weiter – sie sehen die Unmöglichkeit, einen erklärenden Hilfe-Text für eine Website zu verfassen. Zudem sind Accesskeys gerade für Menschen mit motorischen Behinderungen, für die sie auch gedacht waren, durch die Notwendigkeit zum gleichzeitigen Drücken mehrerer Tasten kaum zu gebrauchen.

Erschwerend kommt hinzu, dass die meisten Tasten, die man definieren kann, schon in anderen Programmen vergeben sind. Wenn man die gängigsten Browser untersucht und verbreitete assistive Werkzeuge wie Screenreader und Sprach-Browser hinzunimmt, wird man sehr schnell feststellen, dass fast alle Zeichen auf der Tastatur schon von einem Programm benutzt werden.

Ein noch entscheidenderer Fehler ist die Möglichkeit, dass jeder Web-Entwickler entscheiden kann, wie er diese Tasten vergibt. Für die Vergabe der Accesskeys gibt es keine einheitliche Vorgabe, so dass der Benutzer auf jeder Website, die er neu ansurft, zunächst einmal die Accesskeys erlernen müsste. Diese nicht kontrollierbaren Folgen sind einer der Gründe, warum die kanadische Bundesregierung die Verwendung von Accesskeys wieder aus ihrem Style Guide gestrichen hat.

Ausnahme:

Wenn Sie eine Web-basierte Anwendung mit vielen ähnlichen Formularen für ein Extra- oder Intranet entwickeln, können Sie natürlich genauere Vorhersagen darüber treffen, welche Accesskeys in Ihrer Umgebung funktionieren. In diesem Fall haben Sie ja die volle Kontrolle über die zu verwendende Zugangssoftware. Bei einem solchen System kann die Definition von Accesskeys für immer wiederkehrende Funktionen (also z. B. immer das erste Eingabefeld oder unterschiedliche logische Blöcke) sinnvoll und lohnenswert sein. In diesem Fall reden wir aber von Webinhalten, die keinen Dokumenten-Charakter haben, sondern eindeutig Anwendungs-Charakter. Bei Webseiten, die lediglich aus strukturierten Texten, der dazugehörigen Navigation und gelegentlichen simplen Formularen bestehen, lohnt sich der Einsatz generell nicht.

Tabindex – Ja oder Nein?

Ein enger Verwandter des accesskey-Attributes ist der tabindex. Mit diesem Attribut können Sie die Reihenfolge festlegen, in der sich ein Anwender per Tabulator-Taste durch eine Seite bewegen kann. Dies geschieht jedoch nicht in willkürlicher Form wie bei den Accesskeys, sondern in der Reihenfolge die Sie bei der Erstellung des Formulars definieren:

<input type="text" id="suche" tabindex="1">

Da die meisten Browser und assistiven Programme von sich aus die Navigation per Tabulator-Taste unterstützen, brauchen Sie nicht jedes Element einer Seite mit einem Tabindex zu dekorieren. Dies wäre kontraproduktiv, da Sie nicht vorhersagen können, in welcher Reihenfolge der Benutzer durch die Seite navigieren möchte oder an welcher Stelle der Benutzer mit der Navigation beginnt. Zudem entspricht die Tabreihenfolge grundsätzlich dem Ablauf des Quellcodes – wenn sie hier für eine vernünftige und nachvollziehbare Abfolge sorgen, dann ist das tabindex-Attribut eigentlich nicht mehr nötig.

Sinnvoll erscheint der Einsatz des tabindex-Attributes in Formularen, wenn die Reihenfolge, in der Kontrollelemente bedient oder Texteingaben gemacht werden sollten, nicht der Reihenfolge dieser Elemente im Quelltext entspricht. Dies kann zum Beispiel bei der Eingabe von Postleitzahl und Ort in zwei unterschiedliche Felder der Fall sein. Diese werden vom Benutzer in genau dieser Reihenfolge erwartet, müssen aber im Quelltext nicht unmittelbar aufeinander folgen und können unter Umständen nicht nacheinander von der Tabulator-Taste angesprungen werden.

Wenn Sie in Ihren Formularen tabindex setzen wollen, sollten Sie diese für das <label>-Tag und nicht für das eigentliche Kontrollelement (Textfeld, Checkbox usw.) definieren. So stellen Sie sicher, dass diese Beschriftungen von einer Sprachausgabe zugeordnet und vorgelesen werden.

Tipp:

Wenn Sie in mehreren Bereichen einer Seite Werte für tabindex vergeben, können Sie dies auch in 10er-Schritten machen. Mit diesem kleinen Kniff brauchen Sie bei Erweiterungen mitten in einer Seite nicht alle folgenden Elemente mit tabindex-Attribut neu zu nummerieren. Uns ist bisher noch kein Browser begegnet, der dieses Attribut zwar versteht, aber nicht von tabindex="14" nach tabindex="20" springen kann, wenn die Werte dazwischen nicht vergeben sind.

Vorbelegung von Formularfeldern

Ein weiterer Punkt, an dem sich die Geister scheiden: die Vorbelegung von Formularelementen wie z. B. Textfeldern durch einen Text, der im jeweiligen Feld angezeigt wird. Die Wurzeln der entsprechenden Vorgaben in den WCAG und damit auch der BITV10.4 stammen noch aus einer Zeit, als angeblich manche Screenreader leere Textfelder nicht erkannten und darüber hinweg lasen. Uns ist jedoch kein einziges Hilfsmittel bekannt, das nach wie vor diesen Fehler aufweist, somit lässt sich diese Forderung der BITV nicht weiter aufrecht erhalten.

Übermäßiger Einsatz von title-Attributen

Nicht nur in Navigationsleisten, auch in Formularen und Web-Anwendungen findet man häufig Inhalte und Funktionen, deren Sinn und Zweck sich erst erschließt, wenn man mit der Maus ein Tooltip auslöst. In diesen per title-Attribut realisierten kleinen Fähnchen stehen dann oftmals erläuternde Hinweise dazu, was sich hinter der jeweiligen Funktion verbirgt, da die Funktion selbst nicht verständlich beschriftet ist. Wenn Ihre Funktionen ohne diese Tooltips nicht verständlich sind – sollten Sie dann nicht lieber den Aufwand für die technische Umsetzung und Betextung dieser title-Attribute in verständlichere Icons, Buttons und Links stecken? Zumal diese title-Attribute nur bei Mausbedienung erscheinen, für Tastaturnutzer bleiben sie in sämtlichen grafischen Browsern verborgen.