Dieser Blogpost (accessibility.net.nz/blog/should-sighted-developers-use-screenreaders-to-test-accessibility) hat in den letzten Tagen für recht kontroverse Stellungnahmen gesorgt. Verständlich. Da hat sich "Webmaster Fritzchen" die Demoversion von JAWS mit 160+ MB installiert, nach Studium von WebAim (deutsche Übersetzung) sich die ersten Tastaturkürzel zur Bedienung von JAWS angeeignet, nach anfänglichem Erschrecken vor der mechanischen Stimme sogar festgestellt, dass das, was JAWS da vorliest, seine eigene Seite ist, und nun wird ihm gesagt, dass das alles Unfug sei.

Einspruch Euer Ehren! Lass mich etwas Ordnung in die Dinge bringen:

Wenn JAWS mir meine Seite vorliest, dann ist sie barrierefrei.

Falsch! Genau  vor dieser Einstellung warnt der zitierte Blogpost. Denn zum einen ist Barrierefreiheit mehr als nur die Lesbarkeit einer Seite mit einem Screen Reader. Zum anderen sagt die Tatsache, dass dein Screen Reader etwas liest, im Prinzip nicht mehr aus, als dass du ihn (den Screen Reader) richtig installiert hast.

Ich nutze als sehender Webworker Screen Reader, um bestimmte Details auf ihre Kompatibilität mit Screen Readern zu testen.

Das klingt doch gleich anders. Ein paar Beispiele gefällig?

• Funktionieren die Sprungmarken aka Skiplinks?
• Sind die Formulare und Datentabellen korrekt ausgezeichnet und mit dem Screen Reader zu bedienen?
• Vie verhält sich der Screen Reader auf Seiten, die sich dynamisch ändern? Z. B. mittels DHTML,  JavaScript oder AJAX.
• Ist WAI-ARIA korrekt eingesetzt?
• Sind Flash-Objekte auf der Seite mit Screen Reader zugänglich?

All diese Sachen kann man natürlich theoretisch einfach richtig machen, indem man die WCAG 2.0 verinnerlicht hat, und entprechend umsetzt. Chapeau, wer das ohne Tests schafft. Der braucht sicher auch keine Debugging-Tools für seine Scripts und Programme.

Ich nutze übrigens viel lieber den NVDA anstelle von JAWS. NVDA ist wesentlich leichter, er belastet mein System weniger, und startet in Sekunden. Webseiten mit dem NVDA testen.