Sollten Webseiten mit Screenreadern getestet werden?

Diese Frage wird in einem englischsprachigen Weblog gestellt. Darauf gibt es eine recht eindeutige Antwort. Nein, es sei denn, die Website wird primär von Blinden und Screenreader-Nutzern aufgesucht.
Bis heute verwechseln viele Webdesigner und Frontend-Entwickler Barrierefreiheit mit blindenfreundlich. Das ist teilweise berechtigt: Menschen mit motorischen Einschränkungen verwenden oft die Tastatur statt der Maus, so dass sie ähnlich wie Blinde durch eine Website tabben. Andererseits: wenn jemand aus motorischen Gründen keine Maus benutzen kann, wird er wohl auch Schwierigkeiten haben, eine Tastatur zu bedienen.
Das wird vor allem dann relevant, wenn man wie bei Access-Keys üblich zwei oder drei Tasten gleichzeitig drücken muss, um eine Aktion auszulösen oder einen seiteninternen Bereich anzuspringen. Übrigens käme wohl kein webdesigner auf die Idee, einem sehenden Nutzer so eine Akrobatik aufs Auge zu drücken.
Bei dem Thema Barrierefreiheit bleiben vor allem Menschen mit Lernschwierigkeiten und geringen Internet-Erfahrungen komplett außen vor. Sie werden von der Vielzahl an Elementen gestört, sie wissen oft nicht, was anklickbar ist und was nicht und häufig genug ist die Navigation von Marketing- statt von Usability-Aspekten geprägt.
An dieser Stelle laufen Usability- und Accessibility eindeutig zusammen. Allerdings haben sich Usability-Tests – mehr oder weniger – fest etabliert, während man Zugänglichkeitstests mit Nutzern bisher kaum findet.
Ich frage mich allerdings auch, was einen Webdesigner oder Frontend-Entwickler zum Zugänglichkeits-Guru qualifiziert. Die Lektüre der BIT-V und der WCAG ist zwar langatmig, aber sicher nicht ausreichend. Und hier kommen wir zum Ausgangspunkt zurück: Nicht jede Website sollte mit einem Screenreader getestet werden, aber der Webworker sollte zumindest einmal intensiver mit einem Screenreader (und anderen Zugänglichkeitstechniken) gearbeitet haben.
Wir müssen es zugeben: die WCAG ist schön und gut, aber für den arglosen Leser total unverständlich. Er versteht nicht, warum Überschriften als HTML-Headline umgesetzt werden sollen, warum Formularlemente Labels brauchen und warum jeder Winkel der Seite mit der Tastatur erreichbar sein soll. Und wenn der Webworker nicht praktische Erfahrungen mit Hilfstechniken sammelt (und frisch hält), wird er vermutlich sein Pflichtprogramm abspulen, aber ohne Phantasie und Interesse. Denn er weiß, dass er etwas Bestimmtes tun muss, er kann aber nicht nachvollziehen, warum er es tun soll. So kommen Webseiten mit einem Dutzend Sprungankern am Anfang der Seite zustande, deshalb werden unsinnige Access-Keys generiert und deshalb sehen viele – vorgeblich – barrierefreie Websites so aus, als ob sie auf einem 14-Zoll-Schwarzweiß-Monitor kreiert wurden.