Bereits bei einfachen Formularen oder Mischformen aus Dokumenten- und Formular- bzw. Anwendung­stypen 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 Unter­stützung testen; so bietet die YUI Library sogar ein eigenes Test-Framework, das JavaScript-basierte Web-Anwendungen gegen die Implemen­tierungen in allen halbwegs standard­konformen 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 Experten­systeme, bei denen man wochenlange Einarbeitung braucht, um zumindest die nötigsten Tastatur­befehle 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 Formular­elemente automatisch auch per Tasten­druck 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 irgend­welche anderen – dann haben Sie id- oder for-Attribute falsch gesetzt und müssen diese korrigieren. Ein Nutzer, der auf Tastatur­bedienung 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 Sprach­erkennung 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. Tasten­druck benötigen. Eine Liste von Hyperlinks ist zudem einfacher zu erfassen. Drop-down-Menüs bedeuten für den Nutzer jedoch mehr Lern­aufwand 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 Fehler­meldungen etc. drauf, dass diese nicht alleine durch farbliche Markierungen gekennzeichnet sind. Wenn Sie beim Testen auf Fehler­meldungen stoßen (z. B. durch den unvoll­ständigen Versand eines Formulars), dann benötigen diese zusätzliche Struktur- und Gestaltungs­elemente jenseits von roter Hintergrund­farbe, um wirklich in allen Ausgabe­formen 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-Betriebs­system sogenannte Kontrastmodi. Typischer­weise wird durch diese der Bildschirm­inhalt invertiert bzw. mit benutzerdefinierten Farben dargestellt, also zum Beispiel beiger Text auf schwarzem Hintergrund, um eine Blendwirkung zu vermindern. Diese Kontrast­modi haben aus Designer-Sicht eine unangenehme Eigenschaft: während alle CSS-Positionierungen beibehalten werden, verschwinden sämtliche Hintergrund­farben und vor allem auch Hintergrundbilder! Wenn Sie also Warn­hinweise per CSS (z. B. .fehler {background-image: warnung.gif;}) realisiert haben, so sind diese für viele seh­behinderte Nutzer nicht mehr wahrnehmbar, weil schlichtweg nicht vorhanden. Zur Vermeidung sollten Sie daher Ihre gesamte Anwendung unbedingt einmal vollständig im Windows-Kontrast­modus 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 barriere­freies Angebot hat. Ein übermäßiger Einsatz aller in HTML vorgesehenen Hilfen zur Orientierung und Navigation kann sogar für manche Nutzer­gruppen dazu führen, dass eine Seite weniger benutzbar wird. Das ist insbesondere dann der Fall, wenn die eingesetzte Technik einen übermäßigen Lern­aufwand erfordert, der die Vorteile der Technik aufwiegt oder sogar übersteigt. Ein solcher Kandidat sind die von den gängigen Vorgaben für Barriere­freie Internet­auftritte verlangten Tastatur­kü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 Tastatur­kü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 Buch­staben 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 Platt­formen wie dem Apple Macintosh sind es statt der Alt-Taste die Ctrl-Taste (auch ohne Enter), Opera macht hier wieder die Aus­nahme 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 Behin­derungen, für die sie auch gedacht waren, durch die Not­wendig­keit zum gleich­zeitigen 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 Werk­zeuge 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 Bundes­regierung 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 Vorher­sagen 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 Eingabe­feld 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 Reihen­folge 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 kontra­produktiv, da Sie nicht vorhersagen können, in welcher Reihen­folge der Benutzer durch die Seite navigieren möchte oder an welcher Stelle der Benutzer mit der Navigation beginnt. Zudem entspricht die Tab­reihen­folge grundsätzlich dem Ablauf des Quell­codes – wenn sie hier für eine vernünftige und nach­voll­ziehbare 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 Text­eingaben gemacht werden sollten, nicht der Reihen­folge dieser Elemente im Quelltext entspricht. Dies kann zum Beispiel bei der Eingabe von Post­leitzahl und Ort in zwei unter­schiedliche Felder der Fall sein. Diese werden vom Benutzer in genau dieser Reihen­folge erwartet, müssen aber im Quell­text 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 Kontroll­element (Textfeld, Checkbox usw.) definieren. So stellen Sie sicher, dass diese Beschriftungen von einer Sprach­ausgabe 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 ent­sprechenden Vorgaben in den WCAG und damit auch der BITV10.4 stammen noch aus einer Zeit, als angeblich manche Screenreader leere Text­felder nicht erkannten und darüber hinweg lasen. Uns ist jedoch kein einziges Hilfs­mittel 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 Navigations­leisten, 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 Maus­bedienung erscheinen, für Tastatur­nutzer bleiben sie in sämtlichen grafischen Browsern verborgen.