Screenreader Optimierung ist eines der faszinierendsten Spezialgebiete im weiten Feld der Barrierefreiheit. Man kann sich hier sehr vertiefen und alle gängigen Screenreader für Windows in mehreren Versionen installieren: JAWS, Virgo, COBRA, WindowEyes. Es gibt von allen Demoversionen. Die Open Source Screen Reader NVDA für Windows, Orca für Linux und den integrierten Mac Screenreader nicht zu vergessen. Alle verhalten sich etwas unterschiedlich.

Man kann alle möglichen Tastenkombinationen lernen und die verschiedensten Konfigurationsmöglichkeiten ausprobieren…man kann zukunftsorientiert alle verfügbaren WAI-ARIA Implementierungen testen, die auch bereits dem kleineren Teil der blinden Internet NutzerInnen, die nicht mehr IE7 oder IE6 verwenden, theoretisch zur Verfügung stehen…

Und trotz all dieses Expertentums wird man als sehender Mensch eine Website nicht so wahrnehmen wie es ein blinder Mensch tut, auch nicht, wenn man den grafischen Browser und die Maus deaktiviert.

Ich jedenfalls kann weder mein visuelles Vorstellungsvermögen und webdesign-technisches Vorwissen abdrehen, noch die strukturelle Logik und die Bedienungskompetenz mit der komplexen Screenreader Software erreichen, die erfahrene blinde NutzerInnen haben.

Wenn man Websites mit blinden Testpersonen testet, hat man AHA-Erlebnisse, die vorgefasste Hausverstands-Annahmen und verfestigte Lehrmeinungen wieder über den Haufen werfen und im Endeffekt mehr bringen als die eigenen Testbemühungen. Wer Web Accessibility ernst meint, kommt nicht umhin darum, sich mit Screenreadern auszukennen, dieser Artikel ist trotzdem ein Plädoyer dafür, „echte“ NutzerInnen in die Webentwicklung miteinzubeziehen.

“Ich bin Sozialarbeiter, kein EDV Profi”

Bei unseren letzten Nutzertests mit blinden ProbandInnen hatten wir die Gelegenheit, neben den versierten und testerfahrenen Screenreader-NutzerInnen auch mit “Durchschnittsusern” ohne spezielles Accessibility Know-how zu testen.

Die Screenreader Profis können die Zugänglichkeit komplexer Anwendungen besser ausloten und wertvolles Hintergrundwissen vermitteln, die blinden DurchschnittsnutzerInnen sind aber wie ihre sehenden Pendants keine EDV-Profis und zeigen dafür umso besser, wo die Usability Hürden liegen.

Ältere Testpersonen hatten größere Konzentrationsprobleme als jüngere. Auch blinde Durchschnittsnutzer wissen nicht, was Begriffe wie RSS oder Browser bedeuten. Während ein Teil der Testpersonen keine Schwierigkeiten hatte, ein Kalender Widget als solches zu identifizieren, hielt ein weniger interneterfahrener User die aufgelisteten Wochentage (1,2,3,4….) für schlecht beschriftete Grafiken…

Ein mit 40 Jahren späterblindeter Mann hatte Schwierigkeiten, sich auf einer ungewohnten Tastatur zu orientieren und war ratlos, als die bei ihm zuhause voreingestellten Tastenkombinationen in der Testumgebung nicht funktionierten.

Ein etwa 50jähriger blinder Nutzer bewegte sich nur mit Tab- und Pfeiltaste durch die zu testende Website, also von Link zu Link oder von Zeile zu Zeile. Er verwendete weder vorbelegte Tasten, um zu längerem Fließtext zu springen (und damit Menülinks zu überspringen) oder um Formulare anzusteuern, noch bereitgestellte Skiplinks und strukturelle Überschriften, noch die Browsersuche oder die Suchfunktion der Website selbst und keine Navigationshilfen wie Link- oder Überschriftenliste.

Er sei Sozialarbeiter, kein EDV Experte, meinte er, wenn er Seitenteile überspringe, übersehe er möglicherweise wichtige Information.

Die Schere zwischen technischer Machbarkeit, messbarer Benutzbarkeit und schlussendlicher praktischer Nutzererfahrung kann ziemlich auseinanderklaffen, egal ob mit assistierenden Technologien gearbeitet wird oder nicht.

Weniger ist mehr

Die meisten ScreenreadernutzerInnen verwenden einige wenige Navigationsschnelltasten, sie reizen die Möglichkeiten ihrer Software nicht aus. Auch die zentrale Wichtigkeit von struktureller Navigationsunterstützung wird vermutlich ein wenig überschätzt.
Wenn mehr als 95% aller Websites keine bieten, kann man nicht erwarten, dass sie auf den weniger als 5% screenreader-optimierten Sites intensiv genutzt wird.

Nichtsdestotrotz sind 1-2 Skiplinks (z.B. „Zum Inhalt springen“) nützlich. Wenn sie bei Fokus sichtbar werden, hilft man, zumindest theoretisch, allen TastaturnutzerInnen, nicht nur Blinden.

Auch strukturelle, aus dem Viewport geschobene Überschriften vor Navigationsteilen (auch wenn sie eines Tages von landmark roles abgelöst werden) sind sinnvoll. Ob eine sonst kaum genutzte H6, wie Jan Hellbusch vorschlägt, oder eine der Überschriftenhierarchie folgende Headline für versteckte Überschriften verwendet wird, ist weniger wichtig.

Usability spielt auch für Blinde eine ebenso große Rolle wie die rein technische Zugänglichkeit. Eindeutige Seitentitel und Links, logische Struktur, weboptimierte Texte, übersichtliche Suchergebnisse und Tastaturbedienbarkeit sind wichtig.

Ein Skiplink zum Suchfeld ist schon wieder unnötig, weil Anspringen von Formularen simpel ist, ebenso eine versteckte Überschrift vor einer korrekt gelabelten Suche.

Hausverstand hilft natürlich doch: Bei verlinkten Bildern muss das Linkziel im alt-Attribut angeführt werden, weil der Alternativtext als Linktext verwendet wird. Bei PDFs sollte der Dateihinweis PDF im Linktext stehen und nicht danach. Sonst merkt man als BlindeR erst beim Klick auf den Link, dass man sich auf ein PDF einlässt, das womöglich riesengroß ist und den etwas mühsam zu bedienenden Acrobat Reader startet.

80-zu-20

Screenreadertauglichkeit ist keine Geheimlehre. Die wichtigsten Grundregeln dafür sind sogar so einfach, dass man sie auch in HTML Anfängerkursen lernen könnte. Anleitungen gibts zuhauf, auf deutsch z.B. bei einfach-fuer-alle.de oder wai-austria.at.

Das Paretoprinzip oder die 80-zu-20 Regel gilt auch hier: 80 % der Ergebnisse werden mit 20 % des Arbeitseinsatzes erreicht. Die verbleibenden 20 % verursachen die eigentliche Arbeit.

Dieser Artikel wird zu lang, den liest kein Mensch, befand mein Kollege Sascha, der bei den Usertests dabei war. Konkretere AHA Erlebnisse zu Suchstrategien, Formularen, PDFs, Videos und Sprachauszeichnung folgen deshalb in einem eigenen Beitrag. Fortsetzung folgt…