"Surf-Alltag" ohne Bildschirm
Es gibt wohl niemanden, der nicht schon einmal eine wichtige Telefonnummer zu Hause vergessen hätte. Solche Probleme löst man durch den raschen Griff zu einem Telefonbuch. Was mich betrifft, so muss es ein digitales Telefonbuch sein, denn Print-Medien sind für mich unzugänglich.
Das Internet bietet mir den gewünschten Komfort: Tagesaktuell und weltweit verfügbar gibt es diesen Dienst und daher tippe ich 
www.otb.at ein.
Meine Erwartungshaltung
Zu finden hoffe ich:
- Ein gut bedienbares Formular, möglichst zu Beginn der Seite,
- eindeutige Beschriftungen,
- rasche Verfügbarkeit der Seite und
- ein leicht auffindbares Ergebnis meiner Suche.
Auf der Suche nach der Suche
Nun haben Screen Reader die Eigenschaft, den Text einer Seite linear, also in jener Reihenfolge vorzulesen, wie er im Dokument steht. Die Sprachausgabe plappert los "Version: 6.170 (ah8herold.at)", was ich ignoriere. Es folgen eine Reihe von Links, aber ich will ja zum Formular. Darum stoppe ich den Redefluss.
Jeder Screenreeader hat einen "Formularmodus", mit dem man Formulare rasch "aufspüren" kann; und diesen bemühe ich auch.
Das erste Formular ist die Branchensuche. Das entnehme ich dem Text vor dem Formular: "Gelbe Seiten - Firmen- u. Branchensuche". Eigentlich ist das eine Überschrift, jedoch nicht als solche gekennzeichnet.
Ich benötige jedoch eine Privatnummer. Also wandere ich zum nächsten Formular. Darüber steht der Text "Telefonbuch", von der Bedeutung her ebenfalls eine Überschrift.
Hier finde ich hintereinander drei Beschriftungen: "Name", "Vorname" "Ort od. PLZ", gefolgt von drei Eingabefeldern - ohne dazugehörige Beschriftung (Label). Diese scheint verzichtbar, denn optisch steht die Beschriftung ohnehin oberhalb des jeweiligen Feldes, so dass der Zusammenhang klar ist. Ein Programm wie das meine kann aber keine optischen Zusammenhänge erkennen, sondern muss die Verbindung zwischen Beschriftung und Eingabefeld aufgrund logischer Definitionen herstellen.
Da eine Sprachausgabe aber zuvor Gelesenes nicht im "Blickfeld" hat und zwischen Beschriftung und Eingabefeld kein logischer, sondern nur ein optischer Zusammenhang besteht, entfällt mir - typisch unkonzentriertes Anwenderverhalten - die Reihenfolge gleich wieder. Also rasch nochmals zurück und nachlesen.
Danach fülle ich das Formular ("Name: Haupt", "Vorname: Herbert", "PLZ od. Ort: Wien") aus und schicke die Anfrage mit dem darauf folgenden (unbeschrifteten) Schalter ab.
Die Stecknadel im Heuhaufen
Die Seite wird neu aufgebaut, mein Screen Reader beginnt "ganz oben" zu lesen und nach den ersten Silben bringe ich ihn zum Schweigen. Was ich jetzt brauche, ist das Suchergebnis; alles andere ist uninteressant geworden.
Suchvarianten
In der Hoffnung, dass das Suchergebnis mit einer Überschrift versehen ist - prominent genug wäre die Stelle jedenfalls -, versuche ich es mit dem entsprechenden Befehl: Fehlanzeige!
Aber wie jedes Programm verfügt auch ein Screen Reader über eine Suchmöglichkeit, und diese benutze ich.
Welche Eingabe führt mich wohl am raschesten ans Ziel?: "Ergebnis"? "Anfrage"? ... Den sichersten Erfolg, wenn auch nicht den kürzesten Weg verspricht der eingegebene Name, im konkreten Fall der unseres Sozialministers.
Der erste Treffer der Suche ist - wie zu erwarten - das ausgefüllte Formularfeld. Also "Weitersuchen"; aber das bringt kein Ergebnis, was mich für einen Moment stutzen lässt.
Umdenken - nicht aufgeben
Also sehe ich das ausgefüllte Formular näher an und entdecke, dass ich, obwohl ich Wien als Ort eingegeben habe, diesen in einer Auswahlliste (mit 19 Elementen) noch präzisieren muss. Ich entscheide mich für "Wien Stadt" und schicke die Anfrage ein zweites Mal ab.
Suche - die Dritte
Nach dem Neuaufbau der Seite kann ich mit meiner programmeigenen Suche "Weitersuchen", denn der Suchbegriff ist noch eingetragen. Ich werde zu den Einträgen geführt und erfahre, dass es vier Treffer gibt (1-4 von 4). Die Namen in dieser Liste sind als Links ausgeführt, gefolgt von der Adresse und einem unbeschrifteten, unaussprechlichen grafischen Link, dessen Ziel ich nicht näher ergründet habe. Telefonnummern gibt es noch keine; vermutlich muss ich meine Anfrage nochmals präzisieren; einleuchtend, aber lästig.
Im Finale
Ich klicke auf den verlinkten Namen, wonach natürlich die Seite nochmals neu aufgebaut wird und ich wieder die programmeigene Suche bemühe um zu den Treffern zu gelangen.
Ich lande wieder bei den vier gefundenen Einträgen - noch immer ohne dazugehörige Telefonnummer oder? Ah, doch: Nach den vier Einträgen wird derjenige, den ich ausgewählt habe, im Detail, also mit Telefonnummer, angezeigt.
Und während ich die Telefonnummer notiere und mir vorstelle, ich hätte nicht vier, sondern 25 Treffer gelandet (bei Mayer durchaus vorstellbar), beschleicht mich der Gedanke, ich hätte besser nach jemandem gesucht, der auf dieser so wichtigen Seite ein paar Erleichterungen schafft - nicht nur für Benutzer von Screen Readern, sondern für alle. Denn unser Sozialminister ist dafür wohl kaum zuständig.
Erleichterungen schaffen
Insgesamt betrachtet war die Suche wohl einigermaßen aufwändig, aber letztlich erfolgreich. Und was wie eine Odyssee und für Uneingeweihte frustrierend wirken mag, ist nur der Alltag im Internet, mit dem nicht nur behinderte Anwender, sondern auch viele andere zu kämpfen haben. Immerhin handelt es sich um eine komplexe Abfrage einer ziemlich großen Datenmenge. Dass diese Abfrage in Teilschritten abgehandelt wird, entlastet nicht nur den Server, sondern verkürzt auch die Wartezeiten des Suchenden.
Komplexe Suchanfragen stellen sowohl an den Benutzer als auch an die Programmierer hohe Anforderungen. Auf den ersten Blick scheint es daher schwierig bis unmöglich bei derart komplexen Abläufen auch noch Hilfestellungen für behinderte Anwender zu geben.
Doch auf Basis der WAI-Richtlinien lässt sich einiges bewerkstelligen, das nicht nur Menschen mit Behinderungen den erforderlichen Zugang zu den Informationen schafft.
Als Beispiel seien hier genannt:
- Anbringung von Überschriften, wo ein neues Thema beginnt. Sowohl das Auge als auch ein Zusatzprogramm für blinde Anwender können diese Information leicht auffinden.
- Logische Beschriftung von Formularfeldern, damit der Zusammenhang nicht nur optisch, sondern auch im Quelltext hergestellt wird.
- Korrekte Beschriftung von Bildern und Grafiken, vor allem von Schaltflächen, die eine Aktion auslösen. Immerhin ist die Datenübermittlung eine sensible Angelegenheit und man sollte wissen, worauf man klickt.
Dies sind nur einige Beispiele und sie beziehen sich stark auf blinde Anwender. Aber naturgemäß sind mir diese Erfordernisse am besten bekannt. Letztlich geht es aber um die Lösung vieler unterschiedlicher Probleme bei der Informationsbeschaffung und um eine für alle Besucher spür- und oft auch sichtbare Qualitätsverbesserung.
Falls Sie klicken wollen ...
- Checklist der WAI-Kriterien
Die deutsche Übersetzung der Richtlinien. - Barrierefreies Webdesign
Buch von Jan Eric Hellbusch und vielen weiteren Autoren. - BIENE Shortlist 2004
Die 23 "Finalisten" der Einreicher. - BIENE-Award
Die Sieger 2004 - Listen and Feel
Kurzvisite mit einem Screen Reader auf den Seiten der 23 BIENE-Anwärter - Postbank
Barrierearmes Net Banking erschließt neue Kunden
