Wie teste ich meine Webseite oder App auf Barrierefreiheit?

Ich werde in letzter Zeit häufiger angefragt, bestimmte digitale Angebote auf Barrierefreiheit zu testen. In den Gesprächen merke ich häufig, dass bei vielen Firmen Unklarheit darüber besteht, wie man am besten mit dem Thema Barrierefreiheit loslegt. Da erscheint es natürlich sinnvoll, als erstes eine Bestandsaufnahme durchzuführen, um zu schauen, ob es auf dem eigenen Angebot überhaupt Barrieren gibt (Wenn Sie sich diese Frage zum ersten Mal stellen, ist die Antwort in 99% der Fälle „ja, und zwar einige“). Aber wie wird eine Webseite, eine Smartphone-App oder Desktop-Software nun konkret auf Barrierefreiheit getestet?

Es gibt verschiedene Möglichkeiten, die ich im Folgenden vorstelle. Prinzipiell kann man jede davon jederzeit durchführen (lassen), aber wie so oft im Leben gibt es hier nicht die eine Variante, die für jeden am besten geeignet ist. Stattdessen gibt es für jede der unten aufgeführten Methode einen richtigen Zeitpunkt, wann diese am sinnvollsten durchzuführen ist. Wann dieser jeweils ist, hängt stark vom Zustand Ihres Produkts und dem Wissensstand über Barrierefreiheit in Ihrem Team ab.

---

Stufe 1: Automatisierte Checks

Der schnellste und einfachste Schritt, den man selbst unternehmen kann, ist die Nutzung von frei verfügbaren automatischen Accessibility-Check-Tools. Hier gibt es unter anderem folgende Optionen:

• Für Webseiten und Webapps: Google PageSpeed Insights kann umfangreiche Checks auf Barrieren der Seite vornehmen. Alternativ kann man auch den Lighthouse-Test der Chrome Developer Tools oder Browser-Erweiterungen wie den empfehlenswerten IBM Equal Access Accessibility Checker nutzen.
• Für Android-Apps: Die Accessibility Scanner-App kann automatisiert manche Prüfungen in nativen Android-Apps vornehmen, z.B. auf ausreichende Farbkontraste oder Buttongrößen.
• Für iOS-Apps: Der mit XCode mitgelieferte Accessibility Inspector kann ebenfalls manche Barrieren finden, vorausgesetzt man hat Zugriff auf den Quellcode der App.

Zu beachten ist, dass diese Tools immer nur ein kleinen Teil der tatsächlichen Barrieren finden können. Längst nicht alle Barrieren sind automatisch feststellbar, da diese Tools nur den technischen Aufbau einer Software testen können, aber nicht deren Inhalte verstehen. Daher werden oft einige Barrieren von den Tools übersehen und die dort vermittelten Ratschläge zur Behebung sind – falls überhaupt vorhanden – nicht immer hilfreich und zielführend.

Stufe 2: Informeller Expertentest

Der nächste Schritt wäre ein informeller Test durch eine erfahrene Testperson, um in vergleichsweise kurzer Zeit und mit geringem Budgeteinsatz möglichst viele Barrieren aufzuspüren. Hier kann man entweder eine Zeitbegrenzung festlegen (z.B. 4 Stunden) oder zielgerichtet nur bestimmte User Flows abtesten.

Die Person wird dann mit geschultem Auge die Software einem Check unterziehen und z.B. die Bedienbarkeit der Software mit der Tastatur und einer Screen Reader Software, die Kompatibilität mit den Bedienungshilfen des Betriebssystems (z.B. die Anpassung von Schriftgröße, Farben und Kontrasten) und das Vorhandensein und die Qualität von Alternativtexten bei Bildern sowie Untertiteln, Transkripten oder Audiodeskriptionen bei Videos überprüfen.

Das Ergebnis ist eine Auflistung der auffälligsten gefundenen Barrieren ohne Anspruch auf Vollständigkeit. Gerade wenn die Barrierefreiheit bei der Entwicklung der zu testenden Software bislang keine Rolle gespielt hat, treten hier aber in der Regel bereits genug Verbesserungspotentiale zu Tage, um ein Entwicklungsteam für mehrere Wochen zu beschäftigen.

Ein wichtiger Punkt dabei ist auch die Bestandsaufnahme über das Wissen und die Erfahrung zur Entwicklung barrierefreier Produkte im Team selbst. Eventuell ist gar kein derartiges Wissen vorhanden, dann wird es schwer, die gefundenen Probleme intern zu beheben. Eine begleitende Beratung und Schulung des Teams ist in diesem Fall angebracht. Vielleicht ist das Wissen im Team aber in Teilen auch schon vorhanden und die barrierefreie Umsetzung wurde bisher aus Zeit- oder Budgetgründen aufgeschoben. In dem Fall ist ein interner Wissenstransfer und eine Priorisierung der Aufgaben zur Herstellung der Barrierefreiheit im entsprechenden Backlog des Teams sinnvoll.

Stufe 3: Formeller Audit

Die nächste Stufe ist die Durchführung eines formellen Barrierefreiheits-Audits.

Für Webangebote gibt es die Web Content Accessibility Guidelines (WCAG), die verschiedene Erfolgskriterien in drei sogenannten Konformitätsstufen A (31 Kriterien), AA (24 Kriterien) und AAA (ebenfalls 31 Kriterien) festlegen, wobei AAA die strikteste Stufe ist und eine striktere Stufe jeweils die Kriterien der vorigen Stufen beinhaltet.

Für die europäische Norm zur digitalen Barrierefreiheit EN 301 549 (welche auch für die Konformität mit dem Barriere­freiheits­stärkung­sgesetz herangezogen wird) ist die Stufe AA maßgebend, also ein Test von 55 Kriterien. Diese Kriterien werden jeweils auf allen Unterseiten geprüft, die im Test enthalten sind. Dabei ist es sinnvoll, Unterseiten auszuwählen, die wichtig für das Angebot sind und häufig besucht werden, und die sich ausreichend stark voneinander unterscheiden, also z.B. nicht drei Blogartikel, wenn alle dasselbe Seitentemplate verwenden.

Wenn Sie eine Software haben, die persönliche Daten verarbeitet oder gar finanzielle Transaktionen beinhaltet, z.B. im Gesundheits-, Banking- oder eCommerce-Bereich, ist es oftmals notwendig, dass eine Testumgebung für den Audit bereitsteht, bei der alle Funktionen realitätsnah aus Kund:innensicht bedient werden können, aber bei der nicht wirklich Geld überwiesen oder Kaufverträge abgeschlossen werden. Oft sind solche Testumgebungen nur unternehmensintern zugänglich, daher muss vorher geprüft werden, wie diese für den Audit zugänglich gemacht werden kann.

Schließlich ist noch zu definieren, welche Testplattformen genutzt werden sollen. Webangebote funktionieren in der Regel auf verschiedensten Gerätetypen (Smartphone, Tablet oder PC), Betriebssystemen (Windows, MacOS, Linux, iOS, Android), Browsern (Chrome, Firefox, Safari, Edge) und Screen Reader-Programmen (JAWS, NVDA, VoiceOver, Narrator, TalkBack), auf denen jeweils unterschiedliche Barrieren auftreten können.

Für die Auswahl der Testplattform kann man z.B. die Ergebnisse der aktuellen Umfrage von Nutzenden von Screen Reader-Software oder auch Infos über die tatsächliche Nutzung der eigenen Software aus vorhandenen Analytics-Daten nutzen.

Was bekomme ich als Ergebnis eines Audits?

In welcher Form man das Ergebnis eines Audits erhält, kann sich je nach Anbieter etwas unterscheiden. Wenn ich einen Audit durchführe, ist in der Regel folgendes enthalten:

1. Ein Report mit den Ergebnissen (z.B. als PDF-Datei) in der gewünschten Sprache (Englisch oder Deutsch). Dieser Report enthält zunächst Infos über die Rahmenbedingungen des Audits, unter anderem:
   • die genaue Testplattform (Gerät, Betriebssystem, Browser, Screen Reader-Software)
   • das Datum, wann der Audit durchgeführt wurde
   • die Version der getesteten Software (falls bekannt)
   • die angewandten Prüfkriterien (z.B. WCAG 2.2 Level AA)
   Dann folgt eine Liste der getesteten Features mit einer benannten Auflistung der entsprechenden Unterseiten mit ggfs. deren verschiedenen Zuständen samt Screenshots. Daraufhin werden jeweils die getesteten Kriterien samt ihrer Beschreibung und entsprechenden Links zur WCAG sowie die Ergebnisse des Prüfschritts (jeweils „erfüllt“, „nicht erfüllt“ oder „nicht anwendbar“) für jedes getestete Feature aufgelistet. Wurde das Erfolgskriterium nicht erfüllt, gibt es eine Beschreibung der gefundenen Barrieren bzw. Verstöße samt Verlinkung der konkreten Unterseite und, wenn es nicht offensichtlich ist, eine Beschreibung, wie die erforderliche Umsetzung aussehen würde.
2. Wenn die Textbeschreibung nicht ausreichend ist, um das Problem zu reproduzieren, fertige ich zusätzlich einen Screenshot oder ein Video an, das das Problem illustriert, z.B. wie ich eine entsprechende Funktion mit einer Screen Reader-Software oder allein mit der Tastatur bediene. Schließlich ist für die meisten Firmen nicht ausreichend zu wissen, dass sie eine Barriere in ihrer Software haben, sie müssen auch wissen, wie sie diese beheben und testen können, dass sie nicht wieder auftritt.
3. Bei Bedarf können die gefundenen Probleme auch direkt als Tickets im entsprechenden Projektmanangement-Tool (z.B. Jira) angelegt werden.
4. Schließlich gibt es noch einen Termin (in der Regel ein bis zwei Stunden lang), in dem die Ergebnisse vorgestellt und besprochen werden und Rückfragen gestellt werden können.

Bei anderen Anbietern können sich die Liefergegenstände unterscheiden. Fragen Sie am besten vorher nach, wie das Ergebnis des Audits dokumentiert wird oder überlegen Sie bereits vor der Beauftragung, in welcher Form das Ergebnis für Sie am hilfreichsten wäre und äußern Sie dies gegenüber dem Anbieter.

Wie funktioniert ein Audit bei mobilen Apps?

Bei mobilen Apps funktioniert der Audit ganz ähnlich. Die Norm EN 301 549 hat außer dem Bereich „Web“ auch einen Bereich „Software“, wozu auch mobile Apps zählen. Die Kriterien sind im Wesentlichen die gleichen, auch wenn manche davon bei mobilen Apps nicht anwendbar sind und einige auf eine andere Art getestet werden müssen als bei Webseiten. Die WCAG hat zusätzlich noch ein Dokument namens WCAG2ICT, das beschreibt, wie die WCAG-Prüfkriterien auf nicht-Web-Angebote angewandt werden können.

Im Gegensatz zu Webseiten ist der Quellcode bei nativen Apps für externe Testing-Tools nicht zugänglich, daher können hier Testschritte kaum mit Software automatisiert werden und müssen händisch getestet werden. Dafür ist hingegen die Varianz der möglichen Testumgebungen deutlich geringer, da man einen fest definierten Formfaktor (Smartphone oder Tablet), nur eine Variante der App statt unterschiedlicher Browser und jeweils nur ein Betriebssystem (iOS oder Android) mit dessen Standard-Screen Reader (VoiceOver oder TalkBack) testen muss.

Reicht die Durchführung eines Audits aus?

Ob die Durchführung eines Audits ihren Testbedarf deckt, hängt davon ab, was Sie mit dem Audit erreichen wollen und wie das Ergebnis ausfällt. Durch einen WCAG Level AA-Test können bereits viele Barrieren gefunden werden. Zudem stellt er auch eine gute Grundlage dar, um eine Erklärung zur Barrierefreiheit für das eigene Angebot zu erstellen, die im Rahmen des BFSG ebenfalls zur Pflicht wird.

Die Norm EN 301 549 enthält jenseits der WCAG aber noch weitere Kriterien, die auf Ihre Software zutreffen könnten. Dies ist insbesondere der Fall bei interaktiven (Web-)Anwendungen, die über das reine Anzeigen von Informationen hinausgehen, z.B. für Chat-Funktionen, Nutzer-Authentifizierung, (Video-)Telefonie oder Hilfe-Funktionen und Dokumentation. Diese müssten dann ebenfalls geprüft werden.

Darüber hinaus besteht bei Angeboten, bei denen Barrierefreiheit eine hohe Relevanz hat, die Möglichkeit, noch die Kriterien der WCAG Stufe AAA zu prüfen. Hierin enthalten sind unter anderem die Prüfung auf Versionen in Gebärdensprache, strengere Kriterien zur Lesbarkeit von Text und Verständlichkeit der Sprache und Navigation, sowie der Abwesenheit von Zeitbegrenzungen.

Eine oftmals sinnvolle Ergänzung zu einem Audit ist die externe Beratung zum weiteren Vorgehen. Es werden beim Audit wahrscheinlich einige Barrieren zu Tage treten. Diese gilt es dann zu bewerten, zu priorisieren und zu beheben. Die Schwere der Barriere korreliert dabei nicht unbedingt mit dem Aufwand, diese zu beheben. Manche Barrieren, die einige Personen von der Nutzung kompletter Funktionen ausschließen, können in wenigen Minuten behebbar sein, andere wiederum können einen tiefergehenden Umbau oder gar eine Neukonzipierung eines Features notwendig machen. Ein Expert:innenblick kann dabei helfen, dies zu bewerten.

Ebenso ist eine beratende Begleitung und Schulung des Teams sinnvoll, wenn dieses noch wenig Erfahrung mit der Entwicklung von barrierefreien digitalen Produkten hat und somit nicht weiß, wie genau bestimmte Barrieren behoben werden können. Insbesondere bei unerfahrenen Teams kann meiner Erfahrung nach eine gut gemeinte, aber fehlerbehaftete Neuimplementierung sogar zu einer Verschlimmbesserung der Barrierefreiheit führen.

Zu guter Letzt muss das Team auch befähigt werden, ihr eigenes Produkt selbst auf Barrieren testen zu können, es sei denn, sie möchten in Zukunft regelmäßig externe Dienstleiter für einen (Re-)Audit beauftragen.

---

Stufe 4: User Tests

Menschen sind einzigartige Individuen und passen daher selten perfekt in ein Raster, dass sich vollumfänglich mit einem formalen Kriterienkatalog abbilden lässt. Wenn Sie bereits einen formellen Audit durchgeführt und die dort gefundenen Barrieren beseitigt haben, ist daher der nächste sinnvolle Schritt, ihr Produkt mit verschiedensten echten Nutzer:innen zu testen, und eben auch mit solchen, die eine Behinderung haben.

Bei einem derartigen Test werden Personen in der Regel Aufgaben gestellt, die Sie mit ihrer Software durchführen müssen wie z.B. „Buchen Sie den nächsten Flug nach Rom“ oder „Finden Sie den günstigsten schwarzen Esszimmerstuhl im Shop und bestellen Sie vier Stück davon“. Die Personen werden dann bei der Lösung der Aufgabe beobachtet und werden in der Regel gebeten, dabei laut auszusprechen, was sie gerade denken und tun wollen.

Solch ein Test liefert in der Regel völlig andere Ergebnisse als ein Test in einer Laborumgebung, da Sie viel realitätsnähere Szenarien mit echten Menschen und ihrer eigenen Hardware in ihrer gewohnten Umgebung testen können. Ich verspreche Ihnen, dass Sie dabei ganz neue Perspektiven erhalten werden, wie Menschen ihr Produkt in der Realität bedienen und was ihnen dabei wichtig ist. Allein schon die existierende Vielzahl an assistiven Technologien wie Ein- und Ausgabegeräten können sie weder selbst anschaffen noch deren Bedienung annähernd so gut erlernen, wie eine Person, die diese jeden Tag nutzt.

Auch fällt es beim Entwickeln und Testen des eigenes Produkts leicht, Barrieren in ihrer Auswirkung zu unterschätzen, von denen man nicht persönlich betroffen ist. So werden z.B. die wenigsten Webentwickler:innen, wenn sie ihre Seite mit einer Screen Reader-Software testen, sich komplett in die Lage versetzen, über keinen funktionierenden Sehsinn zu verfügen, indem sie beim Test die Augen verdecken oder den Bildschirm ausschalten. Bei einem User Test bekommt man hingegen die Auswirkungen der Barriere direkt gespiegelt, wenn man etwa sieht, wie eine Person mehrere Minuten erfolglos versucht, auf der eigenen Webseite ein Produkt in den Warenkorb zu legen.

Darüber hinaus sollte man auch zwischen der bloßen Abwesenheit von Barrieren und eine guten User Experience für bestimmte Zielgruppen differenzieren. Dass man grundsätzlich trotz einer bestimmten körperlichen Einschränkung an eine Information gelangen oder etwa ein Formular abschicken kann, heißt noch nicht, dass dies auch ausreichend schnell und komfortabel möglich ist. In dem Sinne sollten Personen mit verschiedenen Behinderungen z.B. auch in Zielgruppen und Personas reflektiert sein, für die man die Benutzung des eigenen Produkts optimiert und dann auch testet.

---

Wann ist welche Art des Testens sinnvoll?

Generell kann man sagen, dass die Reihenfolge, in der die vier oben genannten Methoden aufgelistet wurden, auch der Reihenfolge entspricht, in der sie am sinnvollsten angewendet werden sollten: Je weniger ein Produkt bislang auf Barrierefreiheit getestet und optimiert wurde, umso mehr Barrieren sind wahrscheinlich vorhanden und desto weniger tiefgehend muss der Test sein, da zwangsläufig weitere folgen werden.

So ist bei einer Software, die bisher nicht bewusst auf Barrierefreiheit optimiert wurde, ein vergleichsweise kurzer, informeller Test oft deutlicher effizienter, als gleich einen kompletten Audit vorzunehmen: Angenommen, eine Webseite oder App nutzt eine nicht barrierefreie Farbpalette mit zu geringen Kontrasten und hat viele Buttons, die nur aus einem Icon ohne Alternativtext bestehen, welche aber auf fast allen Seiten vorkommen. In einem formellen Audit mit 20 Unterseiten müssten nun jeder betroffene Button auf jeder Unterseite getestet und erneut aufgeführt werden, was entsprechend lange dauert und einen deutlich längeren Report produziert. Das Learning ist jedoch das gleiche: Farbpalette optimieren und Alternativtexte vergeben.

Wenn ein Design System samt Komponentenbibliothek zum Einsatz kommt, können eventuell beide Barrieren, die sich durch alle Seiten ziehen, einmal zentral behoben werden. Demnach ist der Mehrwert, dass man alle 50 Buttons, die dieses Problem aufweisen, genau dokumentiert bekommt, relativ gering. Daher kann man diesen Zeit- und somit auch Budgetaufwand einsparen.

Hier ist es effizienter, erst einmal etwas oberflächlicher zu testen, was bereits genug Verbesserungspotentiale offenbaren dürfte, und die gesparten Aufwände in die begleitende Schulung des Teams und die gemeinsame Behebung der Probleme zu investieren. So kann man in kürzerer Zeit deutlich mehr Barrieren finden und beseitigen.

Wenn man sich dann sicher ist, bereits die gröbsten und offensichtlichsten Barrieren behoben zu haben, kann man immer noch den kompletten Audit durchführen. Zur Erinnerung: Ein Audit ist immer nur eine Momentaufnahme und sagt nur aus, wie konform das Produkt zu einem bestimmten Zeitpunkt war. Es können aber jederzeit wieder neue Barrieren hinzukommen, wenn das Entwicklungsteam auf dem Gebiet nicht erfahren genug ist.

Das übergreifende Ziel sollte somit stets bei jeder Art des Testens sein, Wissen in das interne Team zu tragen und es zu befähigen, das eigene Produkt dauerhaft eigenständig barrierefrei planen, designen, entwickeln und testen zu können, so dass ein externer Audit, wenn überhaupt, nur noch selten nötig ist.

---

Fazit

Für Firmen, die sich erstmals mit dem Thema der digitalen Barrierefreiheit beschäftigen, ist es wichtig, schnellstmöglich zu prüfen, wie es um die Barrierefreiheit des eigenes Produkts steht. Nur so können sie abzuschätzen, welche Aufwände auf sie zukommen, um konform mit dem Barriere­freiheits­stärkung­sgesetz zu werden. Im Artikel haben wir vier Methoden betrachtet, die dabei helfen, dieses Verständnis zu erlangen. Außerdem haben wir gelernt, welche der Methoden unter welchen Voraussetzungen am sinnvollsten anzuwenden ist.

Mindestens genauso wichtig wie die Prüfung der Barrierefreiheit ist es jedoch, Wissen über die Entwicklung barrierefreier Produkte im eigenen Team aufzubauen, um die gefundenen Probleme auch beheben zu können und sicherzustellen, dass sie nicht wieder auftreten. Gerne kann ich Sie dabei unterstützen und auch gemeinsam mit Ihnen herausfinden, welche Art der Prüfung für Sie die passende ist und welche konkreten Schritte Sie unternehmen müssen, um zu einem dauerhaft barrierefreien Angebot zu kommen.

Auch werde ich hier in nächster Zeit ein paar hilfreiche Ressourcen und Artikel mit konkreten Tipps zur Entwicklung barrierefreier Webseiten und -Anwendungen veröffentlichen.