Accessibility Ad-hoc-Testing als niedrigschwellige und ressourcenschonende Methode

Ausgangslage: Es ist eine Wüste…!

Wer in IT-Projekten das Thema Barrierefreiheit vertreten und einbringen soll, wähnt sich häufig mit Durst in einer Wüste, und keine Oase ist weit und breit in Sicht. Erste Frage in die Runde der Projektmitarbeitenden: «Welche Entwickler*innen und Content-Verantwortliche verstehen eine Webseite als Dokument und setzen durchgängig korrekte Semantik um?» Alle Hände bleiben unten. Zweite Frage: «Welche Designer*innen kennen die Mindestkontrastwertgrenzen und stellen konsistent ausreichende Kontraste von Inhalten sicher?» Auch hier zeigt sich viel zu oft wenig Zustimmung. Dritte Frage, an allfällig beteiligte Multimedia-Produzierende: «Ist Untertitelung bei jedem von Ihnen produzierten Video immer von Anfang an eingeplant und wird umgesetzt?» Auch hier sieht es leider vielfach düster aus, und man könnte das beliebig fortsetzen für weitere Anforderungsbereiche.

Was sich daraus inzwischen ergeben hat, ist die völlig falsche Einschätzung, Barrierefreiheit sei teuer, zeitintensiv und mühsam. Aber das Problem liegt schlicht darin, dass da Grundlagenwissen fehlt bei allen Beteiligten und deshalb selbst kostengünstig und einfach umzusetzende Aspekte unberücksichtigt bleiben. Oder anders gefragt: Welche Web-Agentur würde einem Relaunch-Projekt den HTML-Grundkurs seiner Web-Entwickler*innen in Rechnung stellen? Na also.

Lamentieren bringt aber nichts, sonst verdursten wir (wobei das hier alles andere als schwarzgemalt ist: auf Barrierefreiheit angewiesene Nutzer*innen sind das im übertragenen Sinne schon längst). Die Frage ist: Wie schaffen wir es, diese Situation zu ändern? Wie ermöglichen wir den Verantwortlichen eines digitalen Angebots einen effizienten Einstieg ins Thema Barrierefreiheit? Wie können wir ihnen bestehende Barrieren in einem Projekt aufzeigen und dabei gleichzeitig Test-Know-how aufbauen, unterschiedliche Nutzungsweisen (u.a. Screenreader-Zugriff) vermitteln und sie fürs Thema sensibilisieren?

Das ist alles viel verlangt, und die oft erträumten «Silberkugeln» gibt es auch hier nicht. Aber Accessibility Ad-hoc-Testing ist eine vielversprechende Methode, effizient gleich mehrere «Fliegen mit einer Klappe» zu schlagen und in einem Projekt schnell «in die Gänge» zu kommen

Was ist Accessibility Ad-hoc-Testing?

Beim Ad-hoc wird gerade nicht zuerst «im stillen Kämmerchen» getestet, dann mit einigem Aufwand aus den Ergebnissen ein Prüf-Bericht erstellt, den sich dann Empfänger*innen mit einigem Aufwand und dem Risiko von Missverständnissen zu Gemüte führen müssen. D.h. der «Umweg» über die schriftliche Dokumentation fällt komplett weg. Das Testen findet direkt mit Anwesenheit von System-Verantwortlichen statt und zwar mehrheitlich durch eine*n direkt betroffene*n Accessibility-Experten bzw. eine -Expertin. Probleme werden verständlich aufgezeigt, unmittelbar «vor den Augen und Ohren» derjenigen Personen, welche die Barrieren auch beheben können. Das kann vor Ort oder noch ressourcenschonender per Bildschirm- und Ton-Übertragung erfolgen. Wichtig ist, dass Entwickler*innen, Content-Verantwortliche und allenfalls auch Designer*innen live mit dabei sind und unmittelbar erleben, wie der Zugriff erfolgt, und welche Probleme sich dabei zeigen. Und wenn zusätzlich Entscheidungsträger*innen teilnehmen, dann ist das umso besser, weil das auch ihnen sehr konkret aufzeigt, wie es um die Barrierefreiheit eines Systems steht.

Dabei scheint uns Screenreader-Testing durch einen blinden Accessibility-Experten bzw. eine blinde -Expertin ein kritischer Erfolgsfaktor dieses Vorgehens zu sein, aus folgenden Gründen: Erstens kann mit dem Screenreader ein breites Set an Anforderungen abgedeckt werden: Von Textalternativen für Grafiken, über semantische Struktur, Tastaturbedienbarkeit, bis hin zur Screenreader-Bedienbarkeit und -Verständlichkeit von dynamischen Widgets, uvm. Und zweitens erfolgt dies auch gleich noch «aus Sicht» eines betroffenen Nutzers bzw. einer betroffenen Nutzerin, also nicht nur indirekt mittels irgendwelcher Prüf-Werkzeuge. Teilnehmende erleben, wie ein*e reale*r Nutzer*in das System verwendet, auf seine bzw. ihre spezifische Zugangs-Weise (mittels Screenreader). Man erlebt unmittelbar, wie die Nutzerin bzw. der Nutzer dabei strauchelt und was die konkreten Probleme sind. So kann man mit einer einzigen Person, die den Screenreader nutzt, bereits einen ähnlichen Effekt erzielen wie mit Usability-Tests, bei denen die System-Verantwortlichen zuschauen und sehen, wie sich Nutzer*innen mit ihrem System abmühen. Diese Beobachtungs-Situation im Ad-hoc-Testing lässt dann nicht mehr sinnvoll ein «Ja, aber…» oder ein Begründen der aktuellen Systemgestaltung zu. Es ist klar, dass das so nicht funktioniert, die aufgezeigten Probleme sind augenfällig. Zudem ist das auch kein Mäkeln irgendeines selbsternannten Experten bzw. einer Expertin, der oder dem man Glauben schenken müsste, sondern ein direkter Nutzer*innen-Zugriff und damit nur noch begrenzt hinterfragbar.

Das ist teils brutal für die entsprechenden Systemverantwortlichen und die Landung ist hart. Aber das braucht es, die Augen fürs Thema Barrierefreiheit und für die konkreten Probleme öffnen sich erfahrungsgemäss so am besten. (Und, bei aller Empathie: ein solches System als Betroffene*r nicht nutzen zu können, wegen völlig unnötigen technischen Barrieren, das ist zweifellos noch viel härter.)

Zusätzlich zum blinden Accessibility-Experten bzw. zur blinden Expertin ist sinnvoll, eine sehende Person mit Expertise mit dabei zu haben. Er bzw. sie kann die visuellen Anforderungen abdecken, wie zum Beispiel Kontrastanforderungen, Farbverwendung und Fokus-Sichtbarkeit. Weiter kann damit eine Interpretation der Screenreader-Ausgaben effizienter erfolgen. Ansonsten kann es in der spontanen, mehrheitlich unvorbereiteten Test-Situation schwierig sein, schlecht umgesetzte Elemente wie beispielsweise Tabs oder Akkordeons nur mittels Screenreader als solche zu erkennen. Klar könnte das auch im Gespräch mit den kundenseitigen Teilnehmenden stattfinden, braucht erfahrungsgemäss aber mehr Zeit. Und zudem können so auch gleich alternative Prüf-Werkzeuge demonstriert werden, mit denen auf visueller Ebene dieselben Anforderungen ebenfalls prüfbar sind, z.B. für semantische Strukturen. Dies ist wichtig, da eigenes Screenreader-Testing für Accessibility-Neulinge erfahrungsgemäss schwierig ist und eine grosse Einstiegs-Hürde darstellt. Bei eingespielter Durchführung des Ad-hoc-Testings können sich beide Expert*innen gleichberechtigt ergänzen.

Was wird mit Accessibility Ad-hoc-Testing erreicht?

Die eigentliche Effizienz der Methode zeigt sich im Ergebnis, und hier erweist sich Ad-hoc-Testing als durchwegs beeindruckend:

• Aufzeigen vieler verschiedener Accessibility-Probleme: Es werden auf effiziente Weise viele, ganz konkrete Accessibility-Probleme eines Systems aufgezeigt, und das gleich für eine ganze Reihe von WCAG-Anforderungsbereichen. In einer Test-Telco von zwei Stunden können gut und gerne 20 bis 30 sehr relevante Barrieren bzw. WCAG-Verletzungen identifiziert, anschaulich vermittelt und auch gleich kurz besprochen werden, einschliesslich erster Hinweise auf Wege der Behebung (natürlich abhängig vom System-Zustand).
• Verständlichkeit der Ergebnisse sehr gut: Die Befunde können verständlich erläutert und direkt auch Rückfragen dazu geklärt werden, und das erreichte Verständnis bei den Teilnehmenden ist besser als bei einem schriftlichen Ergebnis-Bericht.
• Aufbau von Test-Know-how: Zusätzlich lernen Teilnehmende weitere, einfacher zu handhabende Test-Werkzeuge kennen. Sie erfahren, worauf bei einfach zu prüfenden Aspekten (wie z.B. Fokus-Sichtbarkeit) zu achten ist. Dadurch bauen die Beteiligten erstes Test-Know-how auf, mit dem sie entsprechende Anforderungen künftig auch selbst besser einschätzen können.
• Sensibilisierung fürs Thema Barrierefreiheit: Zusätzlich hören wir immer wieder, wie eindrücklich es für sehende Projektpartner*innen ist, wenn sie (erstmals) erleben, wie jemand mittels Screenreader auf Websites oder Mobile Apps zugreift. Das funktioniert nicht bloss auf der rationalen Ebene der Wissensvermittlung, sondern ist ein authentischer Einblick in diese Zugriffs-Weise. Ad-hoc-Testing zeigt unmittelbar auf, welche unüberwindlichen Barrieren bestehen, die auf visueller Ebene meist gar nicht erkennbar sind. Der Sensibilisierungseffekt ist dadurch gross, für alle Teilnehmer:innen in allen Rollen, und das kann der Berücksichtigung der Barrierefreiheit in einem Projekt sehr förderlich sein.

Gibt es Nachteile von Accessibility Ad-hoc-Testing?

Jede Methode hat ihre Grenzen und teils auch Nachteile, beim Ad-hoc-Testing sind die folgenden Punkte zu bedenken:

• Fehlende Dokumentation: Gleichzeitiges Testen und Dokumentieren ist schwierig, deshalb entsteht in einer solchen Test-Sitzung keine ausführliche Dokumentation. Vielmehr werden die Teilnehmenden direkt in die Pflicht genommen, entsprechende Notizen zu den Befunden festzuhalten (wodurch sie aber auch sehr aktiv dabei sind, eine solche Sitzung ist für sie kein «Konsumieren», das ist zielgerichtete Mitarbeit).
• Abdeckung von WCAG-Anforderungen begrenzt: Man muss realistisch bleiben: In einer zweistündigen Sitzung sind keine 50 WCAG Erfolgskriterien der Konformitätsstufen A und AA abzudecken. Und eine solche Test-Sitzung nur einfach beliebig zu verlängern erscheint auch nicht zielführend. Die Methode eignet sich am besten, in einem ersten Schritt die grundlegenden und zentralen Barrieren eines Systems aufzuzeigen, dies aber durchaus für ein breites Set an WCAG-Anforderungen. Weitere Schritte sind im Anschluss sinnvoll und nötig, damit ein System gut barrierefrei wird.
• Nicht für alle Systeme geeignet: Die Methode setzt voraus, dass ein System nicht nur i.S. von «Malen auf Screen» umgesetzt ist. Bei Websites ist ein Minimum an Berücksichtigung der HTML-Spezifikation und ein gewisses Mass an Tastaturbedienbarkeit erforderlich. Ansonsten ist ein System gar nicht erst testbar, zumindest nicht mittels Screenreader. Bei den meisten Systemen (u.a. Mobile Apps und Webumsetzungen) klappt dies aber gut.

Zusammenfassender Ausblick und Empfehlung

Wir behaupten nicht, dass Accessibility Ad-hoc-Testing eine neue Methode wäre, klar ist das «Alter Wein in neuen Schläuchen». Bei der Stiftung «Zugang für alle» führen wir solche live Accessibility-Tests unter Anwesenheit von Kunden-Vertreter*innen durch zwei Accessibility Expert*innen bereits seit vielen Jahren durch. Und wir gehen davon aus, dass dies auch anderswo eine Standard-Methode im Thema sein sollte. Dennoch scheint uns diese Methode nach wie vor nicht den Stellenwert zu haben, den sie verdient. Vielmehr gelangt sie häufig nur dann zum Einsatz, wenn dies bestimmte Rahmenbedingungen nahelegen, z.B. wenn ein Projekt-Budget knapp ist. Ihr ungebrochenes Potential, einem Projekt-Team einen sehr effizienten Einstieg ins Thema Barrierefreiheit zu ermöglichen, wird deshalb noch immer zu wenig ausgeschöpft.

Wir empfehlen die Methode des Accessibility Ad-hoc-Testings allen Projekten, die an bereits bestehenden Systemen arbeiten, die noch Wissen aufbauen müssen zum Thema Barrierefreiheit, und denen auch noch Sensibilisierung fürs Thema förderlich sein kann.