Sie sind hier: Start > Artikel

Testen von Formularen und Web-basierten Anwendungen

Teil 5 unserer Serie zu barrierefreien Formularen

Autor: tc

Tags: , , , , ,

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

Klassische Webseiten, also web-basierte Text-Dokumente, sind relativ einfach zu testen. Was man machen darf und was nicht ist genau beschrieben, mögliche Fehler sind vorhersehbar und somit vermeidbar. Die Vermeidung von technischen Barrieren gehört mittlerweile zum Handwerkszeug eines guten Frontend-Entwicklers; Konzepter und Grafiker orientieren sich an Bedürfnissen und Gewohnheiten der Kunden. Jeder gute Redakteur ist daran interessiert, seine Leserschaft nicht mit seinen Texten zu überfordern. Eine ganze Reihe der Kriterien zur Barrierefreiheit sind sogar vollständig maschinell testbar oder zumindest halbautomatisch durch geschulte Tester zu verifizieren.

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 tatsächlich in Screenreader & Co. ankommt können Sie nur mit echten Nutzern solcher Programme herausfinden.

Dabei kann man nur dringend davon abraten, als Entwickler mal eben so im Vorbeigehen 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.

Zu einem vollständigen Test gehört, dass die Formulare nicht nur in ein oder zwei gängigen Browsern visuell überprüft werden, auch alternative Ein- und Ausgabeformen sollten berücksichtigt werden. Da es sich bei vielen assistiven Programmen um teils sehr komplexe Anwendungen handelt sollten Sie im Idealfall immer mit echten Nutzern solcher Werkzeuge testen.

Aber auch bereits während der Entwicklung eines komplexen Formulars kann es erhellend sein, Zwischenstände mit den entsprechenden Programmen zu testen. Bei der Initiative WebAIM gibt es eine Reihe Anleitungen, wie man verbreitete Screenreader zur Evaluation der Barrierefreiheit einsetzen kann:

Die Tests, die Sie bereits während der Entwicklung eines Angebots selber durchführen können sind meist recht simpel und bedürfen nicht mehr als ein paar unterschiedlicher Browser und diverser Erweiterungen.

In unserer »BITV-Reloaded«-Serie hatten wir für die dort beschriebenen Tests die »Web Developer Toolbar« für Firefox empfohlen; bei diesen Tests können Sie sich hingegen von der »Firefox Accessibility Extension« der University of Illinois unterstützen lassen. Aktuelle Versionen dieser Erweiterung unterstützen bereits den kommenden WAI-ARIA-Standard (Accessible Rich Internet Applications) und sind somit gerade für das Testen von web-basierten Anwendungen interessant. Neben den Optionen zum An- und Abschalten bestimmter Elemente lassen sich mit dieser Erweiterung auch selektiv bestimmte JavaScript-Events unterdrücken. Zudem erfährt man eine Menge über verwendete Events sowie Rollen und Zustände von Bedienelementen und 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 und das Prüfverfahren zum BIENE-Wettbewerb 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 darauf, 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.
Haben alle Radiobuttons einer Gruppe das gleiche name-Attribut?
Ein weiterer Fehler, den Sie nicht mit einem Validator finden können, sondern nur durch Ausprobieren: Damit Radiobuttons sich wirklich gegenseitig ausschließen, müssen alle zusammengehörigen Radiobuttons den gleichen Wert im name-Attribut stehen haben, ansonsten ist es möglich mehrere Buttons einer entweder-oder-Auswahl zu drücken.
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 auch nur um Hyperlinks handelt. Hyperlinks haben außerdem den Vorteil, dass sie 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 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 darauf, dass diese nicht alleine durch farbliche Markierungen gekennzeichnet sind. Wenn Sie beim Testen auf Fehlermeldungen durch den unvollständigen Versand eines Formulars stoßen, 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 so genannte 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: foo.gif;}) realisiert haben, so sind diese für viele sehbehinderte Nutzer nicht mehr wahrnehmbar, weil schlichtweg nicht vorhanden. Um das zu vermeiden, sollten Sie Ihre gesamte Anwendung unbedingt einmal vollständig im Windows-Kontrastmodus durchtesten.
Gibt es eine logische Abfolge der Elemente?
Für viele Nutzungsszenarien ist es von immenser Bedeutung, dass die Abfolge in einem Formular sowohl der optischen Anordnung als auch der Reihenfolge im Quelltext entspricht. Um das zu prüfen benötigen Sie gegebenenfalls eine Browser-Erweiterung wie zum Beispiel die Web Developer Toolbar für Firefox oder WAVE, mit denen Sie die Style Sheets ihrer Seite oder Anwendung unterdrücken können. Schalten Sie CSS ab und testen Sie, ob die Formulare immer noch bedienbar sind.

Zum Schluss: eine kurze Checkliste

Das Thema Barrierefreiheit lässt sich nicht auf eine simple Checkliste reduzieren – dafür ist es einfach zu komplex, und letztendlich geht es ja um Menschen, nicht um Maschinen. Trotzdem hilft eine Checkliste gerade bei der Erstellung komplexer web-basierter Anwendungen, weil man ja immer mal etwas vergessen kann. Daher hier eine kurze Checkliste (ohne Anspruch auf Vollständigkeit):

  • Entfernen Sie unnötige Inhalte von den Seiten
  • Verlangen Sie nur wirklich benötigte Daten
  • Akzeptieren Sie unterschiedlichste Datenformate und Schreibweisen
  • Achten sie auf die Tastatur-Bedienbarkeit
  • Erstellen Sie eine logische Tab-Reihenfolge
  • Achten Sie auf eine ruhige Gestaltung – gleiche Dinge sollten gleich aussehen und sich gleich verhalten.
  • Kennzeichnen Sie Pflichtfelder
  • Verwenden Sie sinnvolle Feldbeschriftungen
  • Sprechen Sie den Nutzer aktiv an (z.B. durch Verben, die eine Aktion beschreiben)
  • Übertreiben Sie es nicht bei der Anzahl auswählbarer Optionen
  • Stellen Sie intelligente Vorauswahlen zur Verfügung
  • Geben Sie dem Nutzer Auskunft über den Fortschritt innerhalb eines mehrteiligen Prozesses
  • Verwenden Sie Reset- oder Abbrechen-Buttons nur in begründeten Ausnahmefällen
  • Stellen Sie Informationen zum Datenschutz zur Verfügung
  • Verifizieren Sie die eingegebenen Informationen client- und serverseitig
  • Stellen Sie eventuell benötigte Anleitungen vor die betreffenden Felder
  • Geben Sie bei Bedarf Hilfen oder stellen Sie bei komplexen Angeboten eine Hotline zur Verfügung
  • Formulieren Sie freundliche und hilfreiche Fehlermeldungen
  • Machen Sie Ort und Art des Fehlers deutlich
  • Beschreiben Sie Möglichkeiten zur Problembehebung
  • Auch bei fehlerhaften Eingaben müssen die korrekt eingegebenen Daten erhalten bleiben
  • Vergessen Sie nicht die abschließende Bestätigungsseite
  • Testen Sie Ihr Formular, indem Sie alle Labels nochmal anklicken (dies wird immer wieder vergessen, und ein Validator findet falsch zugeordnete Labels nicht)
  • Überprüfen Sie Ihr Angebot mit Nutzertests, bevor es online geht

Weitere Kriterien zur Überprüfung Ihrer Website finden Sie in den Prüfschritten des BIENE-Wettbewerbs

Was sagen die WCAG 2.0 zu Formularen?

Die im Oktober 2009 als offizielle deutsche Übersetzung veröffentlichten Web Content Accessibility Guidelines (WCAG) 2.0 behandeln HTML-Formulare nicht direkt, da sie unabhängig vom Einsatzzweck und den verwendeten Techniken formuliert sind. Wertvolle Hinweise zur Umsetzung und Überprüfung finden sich jedoch in den sogenannten »Techniken und Fehler für die Richtlinien für barrierefreie Webinhalte«, die mittlerweile ebenfalls ins Deutsche übersetzt wurden.

Zur Erfüllung der Vorgaben der WCAG 2.0 ist zu beachten, dass je nach angestrebter Konformitätsstufe unterschiedlich hohe Messlatten anzusetzen sind. Eine gute Erklärung hierfür gibt es in Folge 158 des Technikwürze-Podcasts:

»… WCAG 2 unterscheidet die Fehlerbehandlung in drei Stufen: Auf Level A (Fehlererkennung) muss ein Fehler zumindest erkennbar sein mit Hilfe von Semantik, Text und / oder Farbe. Auf Level AA (Fehlererläuterung) sollen die Fehler nicht nur erkennbar, sondern auch mit Beispielen und Hilfen etwa nahe am Formularfeld erläutert werden. Auf Level AAA (Fehlerprävention) liegen dann erst jene Schritte und Bestätigungen, die für uns bei ausführlicheren Formularprozessen ohnehin längst gängige Praxis sind. Formulare, die in Schritten durchlaufen werden, müssen auch in Schritten erkennbar und benutzbar sein und Bestätigungsseiten anbieten, die dem Nutzer entweder noch einmal eine Möglichkeit geben, die Inhalte zu bestätigen, oder schlicht die Ergebnisse des Formulars noch einmal klar anzeigen. Folgerichtig wird hierbei der Level bei finanziellen und rechtlichen Transaktionen dann auf AA gehoben.«

Zum Abschluss noch eine Liste mit wertvollen Hinweisen und Tipps aus den Richtlinien zum Thema Barrierefreie Formulare:

Die WCAG 2.0 zum Thema Label:

Die WCAG 2.0 zum Thema Gruppierung von Formularelementen:

Die WCAG 2.0 zum Thema Fehlervermeidung und -behebung:

Die WCAG 2.0 zum Thema Dynamik:

Die WCAG 2.0 zum Thema Zeitbeschränkungen:

Die WCAG 2.0 zum Thema Pflichtfelder:

Die WCAG 2.0 zum Thema Farben & Schriften: