Ein paar Screenreader AHAs – 2. Teil

Dieser Beitrag ist die Fortsetzung von „Ein paar Screenreader AHAs – 1. Teil“.

Wir testeten vor kurzem eine umfangreiche Website eines Ministeriums mit blinden Testpersonen, mit den Screenreadern JAWS und Virgo. Anhand von 5 Use Cases versuchten wir verschiedene für die Nutzung mit Screenreader interessante Bereiche abzudecken:

  • Orientierung auf der Startseite,
  • Suche nach einer bestimmten Detailinformation, die auf verschiedenen Wegen erreicht werden konnte,
  • Suche nach einer Veranstaltung, die Navigation in einer Datentabelle erforderte,
  • Ausfüllen eines Formulars mit verschiedensten Formularelementen und
  • Abspielen eines Webvideos.

Hier ein paar interessante Ergebnisse davon.

Unterschiedliche Suchstrategien

Die informationslastige Website hatte ein dementsprechend sehr umfangreiches CSS/JavaScript Dropdown-Menü mit 3 Hierarchien. Aus Accessibility-Sicht war es gut programmiert. Nur die Hauptmenüpunkte waren mit der Tastatur ansteuerbar, was TastaturnutzerInnen das Durch-tabben langer Linklisten erspart. Die Submenüpunkte waren auf Unterseiten in einem “statischen” Submenü nochmals abgebildet.

Die JAWS NutzerInnen erhielten vorerst also nur das übersichtlich knappe Hauptmenü auf der Startseite. Sie nutzten diese wenigen Menülinks, Links im Inhaltsteil oder die Website Suche zur Lösung der gestellten Informationssuchaufgabe.

Den onmouseover-Befehl, um das Menü aufzuklappen (vorgelesen und auch markiert mit der Abkürzung omo auf der Braillezeile), benutzten selbst die absoluten Web-Profis nicht von allein. Sie wussten auch die Tastenkombination dafür (Strg + JAWS Taste + Eingabe) nicht auf Anhieb. JAWS User haben aber im Prinzip den gleichen Vorteil von richtig gemachtem “progressive disclosure” wie Sehende. Ein korrekt programmiertes Dropdown-Menü kann auch mit Screenreader aufklappen, der Fokus bleibt an der aufgeklappten Stelle, weil die Seite nicht neu lädt.

Virgo+Webformator TesterInnen erhielten das gesamte Menü mit allen Sub- und Subsubmenüpunkten in einer Hierarchie, d.h. in einer sehr sehr langen Liste von Links, dargestellt. Welche Menüpunkte davon Submenüpunkte waren, konnten sie sich nur zusammenreimen.
Im Webformator kann man zwar einstellen, dass versteckte Inhalte nicht von vornherein ausgelesen werden, aber keine der Testpersonen nutzte diese Konfigurationsmöglichkeit.

Die lineare komplette Darstellung des Dropdown-Menüs hat natürlich auch Vorteile.
Virgo TesterInnen nutzten verstärkt die Webformator / Browser Suche und waren damit bei der Lösung der Suchaufgabe sehr schnell, weil für sie bereits alle möglichen Menülinks, also wahrscheinlichen Suchbegriffe, auf der Startseite verfügbar waren.

Umgang mit Formularen

Wir testeten ein Feedbackformular mit mehrzeiligen Fragen und jeweils einer großen Anzahl von Antwortmöglichkeiten in Form von Radiobuttons oder Checkboxen und einigen Eingabefeldern.
Interessant war bereits, wie die Testpersonen das Formular auf der zu testenden Seite ansteuerten. Die meisten verwendeten eine Schnelltaste (E oder JAWS Taste + Strg + Pos1), um zu einem Formularfeld zu springen. Sie landeten damit mitten im Formular beim ersten Eingabefeld und mussten rückwärts navigieren, um zu den ersten Fragen mit Radiobuttons und Checkboxen zu kommen.

Die nach Lehrbuch korrekte Vorgangsweise für Gruppen von Auswahlschaltern / Kontrollfeldern ist, einzelne Fragen/Antwort Blöcke in Fieldsets zu gruppieren, die Frage als Legend auszuzeichnen, die auswählbaren Antworttexte als Labels. Damit die Zuordnung von Frage und Antworten eindeutig ist, wird die Frage damit bei jeder Checkbox / bei jedem Radiobutton wieder mitvorgelesen.

Labels bei Formularfeldern sind wichtig, Legends sind aber möglicherweise lästig.
Das “Legends? Biiittte nicht” einer Virgo Testerin klang richtig flehentlich. Die Zuordnung sei auch ohne Legends durch die Lesereihenfolge klar. Wenn man nicht mit Tab- sondern mit Pfeiltaste durch das Formular navigiert, wird auch Text, der nicht als Formularelement ausgezeichnet ist, wie z.B. eine Überschrift, vorgelesen.

Auch in JAWS ist die Legend bei einer Gruppe von Radiobuttons oder Checkboxen laut einem versierten Anwender nicht notwendig. Bei Radiobuttons und Checkboxen muss man nicht im Formularmodus arbeiten, in dem nur Formularelemente interpretiert werden. Den Formularmodus benötigt man nur bei Formularfeldern für die Texteingabe.

Hier ist man nun als WCAG treue WebdesignerIn im Dilemma: schadet man mit dem, was eigentlich nützen soll, womöglich? Die regeltreue Vorgangsweise ist natürlich doch, Legends vorzusehen. Was man tun kann, ist eine optisch versteckte Kurzversion langer Fragen / Texte als Legend zu verwenden und die Fragen selbst als Überschriften auszuzeichnen.

Für die korrekte Lesereihenfolge sind offensichtlich explizite Labels besser. Bei impliziten Labels war bei unserem Test nach dem Lesen der Labels ein Schritt zurück nötig, um das zugehörige Formularelement – Radiobutton oder Checkbox – auszuwählen.

Eindrucksvoll war der Effekt, den ein kleiner Verschachtelungsfehler bei einer Frage im Formular auslöste, span-Elemente, die innerhalb eines label-Elements geöffnet, aber erst danach geschlossen wurden. Im Firefox war die optische Darstellung korrekt, in anderen Browsern waren die Checkboxen nicht gefloatet. Mit Virgo plus Webformator wurden bei jeder einzelnen Checkbox die Labels aller Checkboxen wieder aufgelistet und das Formular damit schlicht unlesbar.

Datentabellen

Auch bei der Aufgabenstellung, zu einem vagen Veranstaltunghinweis den genauen Ort und Zeitpunkt zu suchen, war interessant zu sehen, wo die Testpersonen mit ihren Suchstrategien landeten: mittendrin in einer großen Event-Tabelle, die einzelnen Einträge  jeweils mit Datum, Veranstaltungsname und Detailinformationen.  Die Tabelle war nicht kompliziert aufgebaut, allerdings war die Headerzellenzuordnung nicht eindeutig und nicht 100% klar, welches Datum zu welcher Veranstaltung gehörte. Wieder war ein Zurücknavigieren an den Anfang der Tabelle nötig, um ihre Struktur einigermaßen verstehen zu können.

Mit einigen Testpersonen schauten wir uns auch das dazugehörige Kalender Widget in der Seitennavigation an: der Profi JAWS Nutzer hatte kein Problem damit, die Wochentage den Datumszellen zuzuordnen. Die Virgo Testerin meinte, ihr sei es egal, ob so ein Kalender vorschriftsmäßig ausgezeichnet sei. Er sei zu umständlich, sie würde ihn sowieso nicht benutzen. Ein anderer Virgo Tester identifizierte die linearen – für ihn unverständlichen – Tabellen-Informationen gar nicht als Kalender.

Webvideos

Wie nutzen blinde Menschen Videofilme? Wir testeten ein Video im FLV Format, eingebunden mit einem üblichen Flashplayer, der sich in einem Popup öffnete. Bei einem Vortest zeigte sich, dass Screenreader die Bedienelemente des Players unterschiedlich vorlasen. Wo NVDA nur ein “leer” las, gaben JAWS und Virgo “Pause” und “Play” aus. Zum Vergleich: Bei Videos, die mit dem besser zugänglichen aktuellen JW FLV Player eingebunden waren, war die Button Bezeichnung korrekt und auch für den NVDA Screenreader lesbar.

Die blinden Testpersonen hatten keine Schwierigkeiten, das getestete kurze Video zu öffnen. Die Benennung des Play/Pause-Buttons war im vorliegenden Player allerdings fehlerhaft, d.h. sie mussten auf den mit “Pause” beschrifteten Button klicken, um das Video zu starten.

Einer der JAWS-Tester fragte irritiert, ob das Video schon spiele, ob sein Ton ev. abgeschalten sei. Ihm wäre am liebsten, wenn ein Video gleich zu spielen beginne, wenn er schon einen Link zu einem Video anklicke, so wie bei Google Video, obwohl dies nicht WCAG konform ist.
Eine Virgo Testerin sagte, sie lade sich Videos lieber herunter als sie online anzusehen, weil es mit dem Windows Mediaplayer mehr Steuerungsmöglichkeiten gibt, z.B. vor- und zurückspulen. Sie lade sich vor allem Spielfilme, die mit Audiodeskription versehen sind, herunter.

PDFs – ein Dilemma

Wie gehen Sie mit PDFs um, fragten wir einige Testpersonen. Es blieb allerdings nicht genügend Zeit, um auch ein PDF zu testen.

PDF ist eine Technologie, die Barrierefreiheit unterstützt, und zumindest öffentliche Stellen sind gesetzlich verpflichtet, ihre ins Netz gestellten PDFs auch korrekt zu taggen, d.h. mit Strukturinformationen zu versehen, mit Markup für Überschriften, Absätze, Listen, Bildalternativen, Tabellen und Formulare.
Das Know-how dafür ist verfügbar (z.B. bei einfach für alle, wertewerk, im ebook  Barrierefreie PDF aus Word 2007 …), und alle auf Barrierefreiheit spezialisierten Agenturen bieten die Leistung an. Die nötige Knochenarbeit muss aber einkalkuliert, gemacht und bezahlt werden.

Ca. 50% der blinden WebnutzerInnen finden PDFs dennoch nach wie vor schwer zu lesen (vgl. WebAIM Screen Reader Survey). Ein Großteil der PDFs im Netz ist nicht strukturiert. Der Acrobat Reader ist umständlich und langsam in der Bedienung.

Das Antwortspektrum unserer TestteilnehmerInnen bei der Frage nach dem Umgang mit PDFs reichte von “lese ich gar nicht, meide ich tunlichst” bis zu “hab kein Problem damit, aber mit Formularen habe ich noch keine Erfahrung”. Die Antwort eines Testers, auf die Frage, was er mit einem unlesbaren, rein grafischen oder mit einem Gratistool konvertierten, für ihn nur aus Sonderzeichen bestehenden PDF mache, war wohl eher ironisch gemeint: „Ich drucke es aus, scanne es ein und lasse OCR Software drüberlaufen.“

Viele blinde WebnutzerInnen verwenden einen “PDF zu Text Konverter” – z.B. den ABBYY PDF Transformer – und wandeln PDFs wieder in Formate wie Word um, da sie damit besser und vor allem schneller umgehen können. Die Formatierung bleibt dabei zwar erhalten, die Strukturinformationen gehen aber wieder verloren.

Office Dokumente mit Formatvorlagen zu erstellen, die bei der PDF Generierung automatisiert in Tags umgewandelt werden, sollte selbstverständliche Qualitätsarbeit sein. Mit QuarkXpress für den Druck erzeugte PDFS nachträglich im Acrobat zu taggen, um sie guten Gewissens in Netz stellen zu dürfen, scheint aber noch eine eher unbedankte Liebesmühe zu sein. Wichtiger als das Taggen der PDFs ist hier noch die korrekte Lesereihenfolge, die man auch von Grafikbüros einfordern  und  leicht selber testen kann.

JAWS ist geschwätzig

WebentwicklerInnen testen in der Regel mit JAWS, dem gängigsten Screenreader. Bei uns, jedenfalls im Umfeld von Wiener Blindeninstitutionen, ist aber durchaus auch Virgo sehr gebräuchlich.

JAWS gibt mehr Hintergrundinformationen als Virgo, wenn man die Grundkonfiguration nicht ändert. Im Alltag brauchen blinde WebnutzerInnen aber z.B. die haarklein vorgelesene Zuordnung einzelner Tabellenzellen oder die genaue Analyse von verschachtelten Listenstrukturen nicht immer unbedingt. „JAWS ist sooo geschwätzig“, sagte eine Screenreader-Expertin. Man könne die Strukturinfos nicht bequem mit einem Tastenklick weg- oder herschalten. Auch Formulare fülle sie lieber mit Virgo aus, weil es im Formularmodus von JAWS (vor Version 10) leichter passiere, dass sie ein Formular vorschnell mit Enter abschicke.

Meine geliebte Eloquence

So nannte ein blinder JAWS Experte seine Sprachausgabe. Die Sprechgeschwindigkeit hatte er so schnell eingestellt, dass ich nichts mehr verstand. Sehende empfinden die roboterhafte, synthetische Computerstimme von Screenreadern eher als quälend. Ob RealSpeak, eine Text-to-Speech Technik, bei der menschliche Sprachsegmente verknüpft werden, nicht ein großer Fortschritt sei, fragte ich ihn. Nur bedingt, meinte er.

An der RealSpeak Stimme Steffie, mit angenehmer Sprachmelodie so menschlich klingend wie eine Zugansage von Chris Lohner, demonstrierte er die Zeitverzögerung bei der Sprachgenerierung durch Text-to-Speech, die ein flüssiges Interagieren zumindest derzeit – für ihn – noch unmöglich macht. Er verwende sie höchstens, um sich lange Texte vorlesen zu lassen, ansonsten sei Eloquence unersetzlich, weil sie viel schneller reagiere.

Auch Sprachauszeichnung einzelner fremdsprachiger Wörter nervt ungeduldige blinde InternetnutzerInnen, weil sie die Sprachausgabe bremst. JAWS NutzerInnen merken sie nur, wenn sie die automatische Spracherkennung nicht deaktiviert haben. Virgo NutzerInnen bekommen sie nicht mit, weil hier die Sprachumschaltung nur manuell passiert. Mit dem vorgeschaltenen Webformator funktioniert die Sprachumschaltung gar nicht. Bei WindowEyes funktioniert sie anscheinend im Firefox nicht.
Es gibt unterschiedliche Fachmeinungen dazu, pragmatisch Gesinnte lassen die Auszeichnung einzelner Wörter – vor allem wenn diese schon im Sprachgebrauch geläufig sind – im Text mittlerweile gerne wieder bleiben.

Fazit

Es gibt nicht immer eindeutige Antworten für Fragen der Zugänglichkeit, und vor allem sind sie im schnelllebigen Internetgeschäft nicht ewig gültig. Was heute stimmt, kann morgen schon wieder obsolet sein.

Grundsätzlich sind Nutzertests immer sehr spannend und aufschlussreich. NutzerInnen miteinzubeziehen, ist die sicherste Methode, nicht an den Menschen vorbei zu entwickeln.

3 thoughts on “Ein paar Screenreader AHAs – 2. Teil

  1. Hallo,

    nein, der die beiden Artikel sind nicht zu lange. Zumindest ein Mensch hat sie beide zu Ende gelesen, und konnte sich wertvolle, und vor allem aktuelle Informationen holen.
    Danke dafür.

    Fritz

  2. Vielen Dank für die Tests und Veröffentlichung. Das Hilft bei der Optimierung von Seiten für diese Zielgruppe ungemein.

Kommentare sind geschlossen.