Warum wir eine eigene Software zum professionellen Testen auf Barrierefreiheit programmieren?

Wie beinahe alle Kolleg*innen haben auch wir zunächst ein Tabellenkalkulationsprogramm (in unserem Fall LibreOffice) für unsere Barrierefreiheitstests verwendet. Mit jedem Test kamen neue Erfahrungen und Anforderungen hinzu und wir haben Zeit in die Verbesserung der Datei investiert. Schnell kombinierten wir Tabellen- und Textdokumente, um die jeweiligen Nachteile auszugleichen. Zusätzlich integrierten wir immer mehr Automatisierungsfunktionen, um uns wiederkehrende Arbeiten abzunehmen und potenzielle Fehlerquellen auszuschalten.

Je größer die Barrierefreiheitstests und je höher die Anforderungen an unsere Prüfberichte wurden, desto mehr Zeit verwendeten wir in das Management der Tabellen- und Textdokumente. Wir konnten das ermöglichen, da wir ein Team von unterschiedlichen Expert*innen sind und somit immer jemand technisch versiertes da war, um die neuen Anforderungen einzubauen. Jedoch hatten wir die gesamte Zeit bei der Verwendung des Tabellenkalkulationsprogramms als Testwerkzeug ein maues Gefühl bei der Arbeit. Vor allem beim Aufsetzen und Abschließen eines Tests dachten wir immer wieder, dass die Arbeit doch einfacher und intuitiver sein muss. Vor ca. drei Jahren haben wir endgültig eingesehen, dass der Aufwand nicht im Verhältnis zum Nutzen steht und fassten den Beschluss, dass wir etwas Grundlegendes ändern müssen.

Wir begaben uns auf die Suche nach einer Alternative. Wir haben zunächst unsere wichtigsten Anforderungen zusammengestellt, um eine passende Lösung zu finden.

Eines der wichtigsten Ziele war und ist, weniger Zeit mit dem Management und der Anpassung des Testwerkzeugs zu verbringen und mehr Zeit zum Testen zu haben: vom Anlegen eines neuen Tests über das Testen selbst bis hin zum Abschließen des Prüfberichts.

Unsere Erfahrung hat gezeigt, dass wir neben den vorgegebenen Richtlinien und Normen (z.B. Web Content Accessibility Guideline (WCAG) 2.1 AA oder EN 301 549 - web) auch angepasste oder eigene Prüfkataloge benötigen.

Wir arbeiten im Team kollaborativ und gleichzeitig an Projekten und das muss auch bei Barrierefreiheitstests möglich sein – selbstverständlich auch in einem Team von Personen mit und ohne Behinderung.

Klingt seltsam, aber viele Prüfberichte auf Barrierefreiheit sind wenig hilfreich. Der Aufbau und die gewählten Metriken sind häufig nicht aus Sicht der Kund*innen gewählt. Kein Prüfbericht allein, kein Test allein, macht etwas barrierefrei, somit brauchen wir die Möglichkeit optimale, nutzungszentrierte Prüfberichte zu erstellen, die die Arbeit an der Barrierefreiheit erleichtern.

Es muss möglich sein, einen strukturierten Test nach WCAG-EM (Website Accessibility Conformance Evaluation Methodology) durchzuführen. Zwei wichtige Funktionen dafür sind die Möglichkeit, Stichproben zusammenzustellen und das strukturierte Abarbeiten des Prüfkataloges.

Die issue-orientierte Notation ist ein unmittelbares Ergebnis unserer langjährigen Arbeit mit umsetzenden Teams (externe sowie inhouse). Bei jedem Team, das einen Prüfbericht erhält und daraufhin Verbesserungen machen möchte, ist die erste Handlung den Bericht in Aufgaben (Issues) aufzuteilen und im Team zu verteilen bzw. ins Ticketsystem zu pflegen. Mit der issue-orientierten Notation sind die Aufgaben bereits aufgeteilt. So wird das ausführende Team unterstützt und Nachfragen reduziert.

Das neue Testwerkzeug muss einen reibungslosen Ablauf garantieren. Testen ist weiterhin eine anspruchsvolle Arbeit und soll gleichzeitig Spaß machen, dafür muss das Werkzeug die Testarbeit sowie die testende Person unterstützen und nicht das Gefühl geben, gegen sie zu arbeiten.

Mit diesen sieben Kriterien im Kopf haben wir vor drei Jahren die folgenden Alternativen bewertet:

Mit dieser Software haben wir bereits jahrelang gearbeitet. Mit Abstand die flexibelste Lösung, wenn die technischen Fähigkeiten vorhanden sind. Die Lösung kann jedoch schnell wackelig werden und benötigt regelmäßige technische Pflege. Im Aufbau des Berichts ist man frei. Die Zusammenarbeit im Team ist schwierig.

In beiden Systemen besteht das Problem, dass die Software nicht für Barrierefreiheit und barrierefrei konzipiert ist. Verschiedene Richtlinien und das Bilden von Stichproben werden nicht voll unterstützt. Beim Ticketsystem ist ein zusätzliches Problem, dass es keine Berichterstellungsfunktion gibt.

Eigentlich sind wir davon ausgegangen, dass wir diese Option wählen werden und uns nur noch zwischen der begrenzten Anzahl an Anbietenden entscheiden müssen. Angeschaut haben wir uns verschiedene kommerzielle Test-Softwares wie von Deque Systems, TPGi aber auch Accessibility Insights von Microsoft. Diese Softwares erfüllen die meisten unserer Anforderungen. Einzig die Flexibilität in der Testart und den Katalogen war in allen nicht gegeben. Man lässt sich zwangsläufig auf “the way of testing” des jeweiligen Produktes ein. Eigene Prüfkataloge oder Anpassungen sind nicht möglich. Außerdem waren viele Firmen zum damaligen Zeitpunkt ausschließlich auf die WCAG und die Section 508 ausgelegt. Die EN 301 549 war kein Thema.
Die Arbeit mit dem WCAG-EM Report Tool, welches eine eigene Position einnimmt, haben wir auch geprüft. Positiv ist, dass es Open Source ist. Da das Tool speziell darauf ausgelegt ist, einen Konformitätsbericht zu erstellen, erfüllt das Tool ansonsten nur wenige unserer Anforderungen für ein effektives Testen im Team. Getestet werden kann nur nach der WCAG, andere Richtlinien sind nicht wählbar.

Diese Option bietet die größte Freiheit und die größte Arbeit. Alle gewünschten Funktionen können realisiert werden. Dem gegenüber steht der große Aufwand, eine eigene Software zu programmieren.

Die Entscheidung für eine eigene Software war so schwierig wie einfach. Alle anderen Lösungen haben nicht annähernd unsere Anforderungen erfüllt. Der Weg zu einer eigenen Software stand nur offen, weil wir als Barrierefreiheitsspezialist*innen und Digitalagentur entsprechende Expertisen verbinden. 

Und so machten wir uns an die Entwicklung von CAAT - Computer Aided Accessibility Testing. Wir wussten, dass wir verhältnismäßig wenig Ressourcen zur Verfügung stellen konnten und deshalb schlank und agil bleiben müssen. Um das zu erreichen, mussten wir die wichtigsten Funktionen ermitteln und eine simple und effektive Benutzungsoberfläche schaffen. Auf Basis einer längeren Konzeptionsarbeit wurde eine erste einsetzbare Version dann tatsächlich in nur zwei Wochen erstellt. Viele getroffene Entscheidungen erwiesen sich als belastbar und finden sich in ähnlicher Form weiterhin in CAAT. 

CAAT erfüllt alle von uns aufgestellten Kriterien und bietet mittlerweile eine Reihe weiterer Funktionen an. Dabei ist und bleibt eines der wichtigen Grundprinzipien von CAAT die unabhängige Entwicklung einer Testplattform ohne feste Kopplung an die Verwendung eines Prüfkatalogs. Wir wollen die größte Flexibilität bieten.

Seit 2021 bieten wir CAAT als kommerzielle Software an. CAAT ist von Tester*innen für Tester*innen entwickelt. Wir nutzen CAAT jeden Tag und sind kritische Nutzende – was uns aber besonders überrascht hat, wie viel Interesse bei unseren Kund*innen und Partner*innen besteht, dass sich CAAT immer weiterentwickelt und wir viele Einblicke erhalten, was Sie sich von einer professionellen Software zum Testen auf Barrierefreiheit wünschen. 

Unsere Wunschliste für neue Funktionen ist mittlerweile sehr lang und geht auch schon weit über die gesammelten Kriterien hinaus. Vieles konnten wir bereits umsetzen und noch viel mehr wollen wir angehen. 

Mit jeder neuen Kundschaft erhalten wir die Möglichkeit, mehr Zeit in CAAT zu investieren und damit die Arbeit für professionelle Tester*innen zu vereinfachen und etwas ganz Besonderes zu bieten:

Viel Spaß beim Testen.