Dies ist das Transkript von dem Gespräch mit Stefan Farnetani zum Thema automatisiertes Testen von PDF und Websites mit CAAT. Alle Ungenauigkeiten gehen auf mein Konto.
Domingos: So, herzlich willkommen zu einem neuen Podcast zur digitalen Barrierefreiheit. Heute habe ich wieder einen Gast dabei: Stefan Farnetani von der Agentur Mindscreen. Also, vielen Dank, Stefan, dass du dir die Zeit für den Podcast nimmst.
Stefan: Ja, danke, Domingos, für die Einladung. Ich freue mich sehr, heute hier zu sein.
Domingos: Ja, sehr gerne. Wir werden heute vor allem über das Thema Automatisierung sprechen, weil Mindscreen dort eine Lösung anbietet. Und wir werden auch über das Thema Barrierefreiheit bei PDFs sprechen, weil Mindscreen dort eine Studie zusammen mit axes4 automatisiert durchgeführt hat – und wir wollen natürlich wissen, was dabei rausgekommen ist. Wir fangen aber einfach wie immer damit an, dass du dich gerne den Zuhörenden vorstellst, Stefan, und vielleicht auch direkt die Firma Mindscreen und was sie im Bereich Barrierefreiheit macht.
Über Stefan und mindscreen
Stefan: Mein Name ist Stefan Farnetani, ich komme aus München, bin Ende der 40er und ich habe mit meinem Kumpel damals, zwischen Schule und Studienbeginn im Jahr 1999, die Firma Mindscreen gegründet. Also, ich beschäftige mich jetzt seit über 20 Jahren professionell mit dem Thema digitale Barrierefreiheit. Zuerst aus der Richtung Frontend-Entwicklung, Gestaltung, UX und dann eben über die Jahre mehr aus der Perspektive Testen oder aus der Perspektive, wie bekomme ich Barrierefreiheit in der Organisation verankert. Was muss ich noch erwähnen? Vielleicht der Vollständigkeit halber: Ich habe ursprünglich Architektur studiert, habe nur ein paar Jahre als Architekt gearbeitet, aber das erklärt manchmal meine Marotten und meine Wortwahl.
Domingos: Ja, vielen Dank. Mindscreen ist ja eine Größe in der Barrierefreiheit. Du hast schon erwähnt, dass ihr schon ganz lange dabei seid, aber wie seid ihr eigentlich zum Thema Barrierefreiheit überhaupt gekommen?
Stefan: Ja, da muss ich vielleicht zweigeteilt antworten. Also, es gibt einmal eine private Ebene und einmal eine berufliche Ebene. Privat hatte ich sehr früh Berührungspunkte. Zum einen bin ich selbst betroffen: Ich hatte im Alter von zwei Jahren einen Unfall und habe die rechte Hand verloren. Und ja, ich kann jetzt aus erster Hand sozusagen erzählen, wie man einhändig einen Rechner bedient oder halt ein Architekturmodell bauen muss. Es ist nicht nur bloße Theorie. Und zum anderen hatte ich einen Onkel, der das Down-Syndrom hatte. Meine Mutter hatte sehr viele Geschwister, es waren insgesamt neun Geschwister, und mein Onkel war da voll integriert. Es war selbstverständlich, dass er Teil der Familie war, und er ist da gemeinsam mit uns aufgewachsen. Das heißt, ich bin sehr früh geprägt worden, dass Teilhabe keine Sonderbehandlung ist, sondern selbstverständlich – vorausgesetzt natürlich, das Umfeld ermöglicht es. Das ist so meine private Perspektive, deswegen habe ich recht wenig Berührungsängste mit dem Thema.
Und dann habe ich die berufliche Ebene. Da hatte ich erstmal nichts mit Barrierefreiheit am Hut. 1999 haben wir angefangen zu programmieren: HTML, CSS, JavaScript, die alte Schule halt. Und da haben wir damals sehr stark SelfHTML als Plattform genutzt, um HTML zu lernen. Ich denke, dass viele meiner Generation über SelfHTML und ähnliche Plattformen das HTML-Programmieren gelernt haben. An dieser Stelle vielleicht ein ganz großes Danke an Stefan Münz, der das damals aufgezogen hat, der das wirklich toll geschrieben hat. Und ihm ist auch zu danken, dass er am Schluss ein Kapitel Barrierefreiheit hatte. Also so früh war da schon das Thema, wie mache ich das richtig. Und nachdem wir das irgendwann gelesen hatten – am Anfang ist man ja so bei den ersten Kapiteln und irgendwann kommt man hinten an –, haben wir natürlich beschlossen: Das ist ganz selbstverständlich, dass wir das mitmachen. Und seitdem sind wir bei der Barrierefreiheit hängengeblieben.
Es ist ein bisschen wie ein Virus. Wenn man da einmal anfängt… Damals gab es noch nicht so viele Informationen, dann hat man halt auf Konferenzen mal jemanden mit einer Braillezeile gesehen und angesprochen. Heutzutage kommt man viel besser an die ganzen Informationen, aber es bleibt dieses Virushafte, dass man sagt: „Oh Mann, wenn ich das jetzt so und so umstelle, dann kann es besser vorgelesen werden.“ Das ist schon sehr faszinierend und gibt einem unglaubliche Genugtuung. Genau so sind wir dazu gekommen.
Domingos: Ja, vielen Dank. Dann wäre die Frage natürlich, was macht Mindscreen heute generell? Also, welche Leistungen bietet ihr an?
Stefan: Ja, Mindscreen grob zusammengefasst: Man kann sagen, wir begleiten Organisationen auf dem Weg zur digitalen Barrierefreiheit. Die Begleitung kann recht unterschiedlich ausfallen – mal ist es nur ein einzelner Auftrag, mal ist das eine Begleitung über mehrere Jahre. Gerade Letzteres ist natürlich unser Liebling, dass wir wirklich die Möglichkeit haben, etwas breiter im Unternehmen zu schauen, wie man das Thema verankern kann. Zu unserer Leistung gehören unterschiedliche Beratungen, Schulungen nach Rollen oder nach Themen, Workshops und Reifegradbewertungen eines ganzen Unternehmens. Ein paar Leistungen holen wir uns durch befreundete Agenturen mit rein, und dann natürlich ganz viel Testen. Also, wir testen Webanwendungen, Applikationen oder auch Geldautomaten und Ähnliches.
Das Testen ist immer so eine gewisse Hassliebe – kannst du bestimmt auch ein Lied davon singen. Als Spezialisten denken wir uns immer: Oh mein Gott, jetzt werde ich dazu gerufen und muss das testen. Aber das Kind ist ja eigentlich schon in den Brunnen gefallen, ne? Oft werden wir dazu gerufen, wenn schon alles zu spät ist und alles schon gemacht worden ist. Eigentlich wollen wir weiter nach vorne. Gleichzeitig ist Testen aber unser Handwerkszeug; es ist eines der wichtigsten Werkzeuge, das wir haben, um mit den Teams zu kommunizieren. Und so, glaube ich, muss man das Testen auch ein bisschen sehen. Man darf es nicht so sehen, dass wir die „Accessibility Cops“ sind, sondern wir versuchen, eine andere Form von Kommunikation zu etablieren. Neben Eins-zu-eins-Gesprächen, Schulungen und Vorträgen, wo wir Wissen vermitteln, vermitteln wir das hier halt in Ticket-gegossenes Wissen, das dann asynchron im Unternehmen verteilt werden kann.
Ja, wenn man das mal so herum denkt, was Testen bedeutet, dann wird es auch nicht mehr so als Pflichtaufgabe gesehen. Jetzt bin ich vielleicht ein bisschen abgeschweift – du siehst, Testen ist so ein Thema, mit dem ich mich viel beschäftige, was wir viel intern besprechen: Was hilft wirklich, was hilft nicht? Ich sage immer scherzhaft: Kein Bericht auf der Welt macht irgendein Produkt barrierefrei. Erst wenn Teams sich hinsetzen und das, was da drinsteht, annehmen und umsetzen, wird daraus ein Schuh, wenn man so will. Und da ist immer die Frage: Wie bereite ich es auf, dass die Teams möglichst wenig Friction – also so eine Bremswirkung, sozusagen – haben und gut ins Doing kommen? Das ist immer eine unserer Hauptaufgaben: Teams befähigen, Einzelpersonen befähigen, das Richtige zu tun.
CAAT und automatisches Testen
Domingos: Ja, vielen Dank. Genau, Testen ist ja auch eine gute Überleitung zum nächsten Thema, nämlich CAAT. Was genau ist CAAT?
Stefan: Ja, also CAAT… Genau, fangen wir vielleicht vorne an. CAAT steht für Computer aided Accessibility Testing, also unsere Software, unsere Testplattform für Barrierefreiheit. Es gibt eine gewisse Ähnlichkeit zum englischen Wort für Katze, „Cat“, und damit spielen wir auch – und auch unser Maskottchen ist natürlich eine Katze. Mit der Testsoftware haben wir praktisch unsere beiden Expertisen verknüpft: Dass wir einerseits wissen, wie man mit Unternehmen kommuniziert und wie man gute Tests macht, und auf der anderen Seite wissen, wie man Webapplikationen barrierefreier aufzieht. Da war es irgendwie naheliegend, dass wir die Sachen kombinieren.
Ursprünglich haben wir CAAT entwickelt, weil wir selbst kein vernünftiges Werkzeug gefunden haben, mit dem wir unsere Berichte professioneller und schneller umsetzen können. Wir haben uns ein bisschen umgeschaut, waren bei den großen Firmen. Das waren natürlich tolle Produkte, aber sie haben uns nicht die richtige Flexibilität gegeben, wie sie für den europäischen Raum benötigt wird – sie waren sehr fixiert auf die Section 508 und auf den amerikanischen Prozess. Und da haben wir halt beschlossen, dass wir ein eigenes Tool machen, erst mal für uns selbst. Dann haben wir gemerkt, aufgrund der Rückmeldungen von anderen Experten, dass wir wirklich einen Bedarf decken, und haben beschlossen, das Tool professionell aufzuziehen.
Das ist bis heute das Wichtigste für uns: dass wir stark von erfahrenen Spezialisten genutzt werden und von Organisationen, die wirklich ernsthaft Barrierefreiheit umsetzen wollen. Also wirklich von Spezialisten, die im Doing drin sind, die wissen, wie man ordentliche Sachen macht und was man dafür braucht. Auch offizielle Überwachungsstellen nutzen uns, zum Beispiel in Deutschland und in Österreich, und selbst blinde Kollegen nutzen CAAT. Es war uns auch von Anfang an wichtig, ein wirklich professionelles Tool für alle zu schaffen. „Alle“ bedeutet natürlich unterschiedliche Beeinträchtigungen, aber „alle“ bedeutet natürlich auch unterschiedliche Unternehmensgrößen. Also, wir wollten kein Tool, das jetzt nur für große Unternehmen erschwinglich ist, sondern halt auch schon ein professionelles Tool, das ab einem kleinen Geldbeutel möglich ist. Wenn du dann ein großes Unternehmen bist und halt 400 Tests im Monat machst, dann zahlst du halt ein bisschen mehr für die Software. Aber auch ein kleines Unternehmen kann sich das leisten. Das war uns sehr wichtig, und so ist immer mehr drumherum entstanden.
Domingos: Genau, aber das ist auch eine gute Überleitung zum Thema Automatisierung. Das ist ja, glaube ich, auch relativ neu. Wie genau funktioniert das Thema des automatischen Prüfens von Websites und PDFs über CAAT?
Stefan: Ja, also ohne jetzt technisch zu weit reinzugehen – ich glaube, die Grundidee ist jedem verständlich: Ich möchte gerne eine Domain eingeben und dann sage ich dem System: „Bitte lauf los.“ Und dann gibt es verschiedene Typen, wie man über die ganze Webseite, die ganze Domain laufen kann. Ob man jetzt freies Crawling hat, ob man die Sitemap-XML ausliest, ob man URLs eingibt, ob man Einschränkungen macht und so weiter. Aber die Grundidee ist halt immer: Ich gebe einfach nur die Domain ein, dann läuft das System drüber, und ich kann auf einen Schlag 5 Seiten, 50 Seiten, 500 oder 1000 Seiten testen. Das ist an sich kein Problem. Das dauert dann vielleicht mal drei Stunden länger, wenn ich viele Seiten habe.
Ja, und das ist im Grunde genommen die Idee, die jetzt komplementär steht – also als Gegensatzpaar zum manuellen Testen. Da gibt es verschiedene Anwendungsfälle. Im Wesentlichen kann man sagen, man kann damit den Ist-Zustand ermitteln. Zum Beispiel, dass ich sage: Wo stehe ich mit meinem Projekt? Ich lasse einmal das System drüber laufen, dann sehe ich: Ah, okay, da sind die häufigsten Fehler. Ich kann die Fehler vielleicht in Bereiche unterteilen und feststellen: Oh, ist für diesen Bereich vielleicht jemand anderes zuständig, weil der schlechter abschneidet? Ich kann aufgrund der Fehlerarten feststellen: Okay, wo kommt dieser Fehler her? Ist das vielleicht technisch bedingt oder ist das redaktionell bedingt? Und ich kann dann daraufhin reagieren. Oder halt, Teams können kleinere Fehler selbst lösen, weil sie sagen: Okay, Alternativtext – hier ist die Erklärung, was ich machen muss. Und sie müssen dann damit nicht gleich zum Spezialisten rennen. Das befähigt Teams sozusagen auch, vieles selbst zu machen.
Genau, und dann haben wir die zweite Schiene, das ist das kontinuierliche Monitoring. Das heißt, wir können Tests mit denselben Parametern wiederholen, können feststellen, ob sich was ändert, können es dokumentieren und natürlich auch als Frühwarnsystem nutzen. Wenn ich sehe: „Oh, da sind irgendwo plötzlich 300 Fehler dazugekommen letzte Woche“, kann ich natürlich recherchieren, was passiert ist. Wenn ich vielleicht eine große Organisation wie eine Universität bin: Gibt es neue Teams? Haben die eine neue Software eingeführt oder ein neues Plugin in WordPress installiert – und schwupps, sackt die Barrierefreiheit ab, zum Beispiel. Also insofern gibt es viele Möglichkeiten. Das sind jetzt erst mal nur die grundsätzlichen automatischen Vorteile. Und dann kann man das natürlich mit manuellen Tests kombinieren. Das ist natürlich das weitaus Spannendere, dass ich sagen kann: Ich kann jetzt automatische Tests mit manuellen Tests kombinieren und damit halt auch neue Dienstleistungen hervorbringen.
Domingos: Und diese Fehler kann man dann vor allen Dingen auch automatisch nach Ticketsystemen wie Jira rüberschieben.
Stefan: Genau. Man kann die dann exportieren, hat ein Dashboard, das man teilen kann – ob passwortgeschützt oder nicht. Die PDF-Sachen kann man dann auch als CSV oder Excel runterladen, weil man bei Web meistens Sachen in ein Ticketsystem einträgt, während man bei PDFs eher den einzelnen Abteilungen hinterherläuft, sage ich jetzt mal. Ich kann jetzt nicht sagen, ich mache aus jedem PDF ein Ticket, das sind halt unterschiedliche Herangehensweisen.
Und wir haben natürlich jetzt verschiedene Metriken, die einfach helfen sollen, dass man sich die Sachen gut anschauen kann. Also, ich kann mir die Fehlertypen anschauen und ich kann mir die Seiten anschauen – auch die Seiten mit den häufigsten Fehlern. Ich habe bei den PDFs sehr tiefgehende Informationen. Also, ich sehe nicht nur, ob eine PDF Fehler hat, sondern ich kann mir, wie im PAC – dem PDF Accessibility Checker –, möglichst alle Informationen anzeigen lassen, bis hin zu den Fehlern, und mir diese highlighten lassen. Wir nutzen ja axesCheck, das ist die Online-Version vom PAC, der bisher nur auf dem Desktop funktioniert. Wir sind eines der ersten Softwareprodukte, die das nutzen, und haben da unglaublich tiefgehende Informationen zu den PDFs. Das geht bis hin zur Autorensoftware, die verwendet worden ist. Also welcher Ersteller und welcher Erzeuger – ich glaube, darin wird das unterteilt. Dann weiß ich zum Beispiel: Ah, das ist jetzt mit Word erstellt worden und mit Word auch als PDF abgespeichert worden. Oder es wurde Word und axesWord verwendet, oder Word und dann Acrobat. Das kann ich mir anzeigen lassen, und das kann ein guter Ausgangspunkt für eine Beratung sein, dass ich sage: Okay, ich habe jetzt hier eine Inventarisierung und ich weiß: Okay, die meisten Dokumente kommen aus InDesign. Dann lass uns mal nachforschen, wie InDesign-Dokumente in der Organisation zustande kommen. Werden die hauptsächlich extern eingekauft oder gibt es Abteilungen, für die wir Schulungen anberaumen oder Verträge ändern müssen? Also genau, da kann man das sehr gut als Beratungsinstrument nutzen. Früher hat man das manuell selbst gemacht, das war sehr aufwendig. Und jetzt geht es halt einfach in Minuten, im Endeffekt, dass man so eine Übersicht bekommt.
Relevanz automatisierter Tests
Domingos: Auf jeden Fall! Du hast es im Prinzip schon gesagt, aber vielleicht müssen wir es noch mal herausstellen: Warum ist es überhaupt wichtig, dass man automatisiert PDFs und Websites prüft?
Stefan: Also ja, „wichtig“ ist vielleicht ein bisschen die falsche Frage. Ich kann vielleicht eher den Nutzen beschreiben: Der große Vorteil von automatischen Tests ist die Skalierung. Das heißt, die Tests können zwar nicht ganz so viel prüfen wie ein manueller Test. Ich sage immer: Ein manueller Test geht in die Tiefe und ein automatischer Test geht in die Breite. Aber diese Breite, diese Skalierung… Wenn ich jetzt zum Beispiel sagen würde, ich mache einen reduzierten Test manuell, dann schaffe ich als Mensch vielleicht 20 Seiten. Der automatische Test kann in derselben Zeit – was weiß ich – 10.000, 100.000 Seiten prüfen; es gibt eigentlich gar keine wirkliche Grenze. Es ist ja nur Serverleistung, die du raufpumpen musst.
Und ja, das ist natürlich schon ein Riesenvorteil, weil dadurch meine Kapazitäten wieder frei werden. Wir haben ja das Problem – ich weiß gar nicht, wie viele Tausend Onlineshops in der gesamten Europäischen Union existieren –, dass die Anzahl der wirklichen Spezialisten natürlich begrenzt ist. Das heißt, wir können gar nicht alles manuell durchforsten. Die Idee ist natürlich jetzt, dass das Automatische mir so eine Art Vorsortierung macht, so ein Vorkämmen, sage ich jetzt mal. Ich habe immer das Bild von verschiedenen Filterstufen vor Augen. Das manuelle Testen durch einen Spezialisten ist eine sehr große, feine Filtereinheit. Aber die setze ich eher weiter hinten im Prozess ein. Vorne platziere ich Filter und Siebe, die wie grobe Rechen funktionieren, wo ich Äste und Grobmaterial schon mal rausfiltern kann. Das sind die automatischen Tests. Wenn ich die schon davor schalte, dann ist diese große Filtereinheit – der Spezialist – umso effizienter, weil er sich dann wirklich um die echten Probleme kümmern kann und seine Zeit nicht mit Standardfragen verbringt. Dass ich zum 15. Mal erkläre, wie man Alternativtexte schreibt, mache ich zwar gerne, aber effizient ist das nicht. Das kann mittlerweile tatsächlich eine Maschine, die das auch schon recht gut erklären und die Probleme einigermaßen gut finden kann. Genau das ist, glaube ich, der Nutzen.
Man darf natürlich nie vergessen: Es gibt Grenzen. Ich habe es jetzt schon ein paar Mal erwähnt – automatische Tests können nicht alles. Ich glaube, da kannst du auch ein Liedchen von singen. Je nachdem, wen man fragt, schwankt diese Zahl immer zwischen 35 % und 40 %. Mit KI verbessert sich das ein bisschen, aber ich will jetzt gar nicht auf diese KI-Träume eingehen. Ganz ehrlich: Die Verbesserungen sind wirklich im Prozentbereich zu verorten. Da schaffen wir statt 30 % vielleicht mal 32 %, aber die sind unglaublich teuer erkauft. Wenn ich bedenke, wie viel Server-Rechenleistung ich da draufschmeißen muss, ist das Verhältnis irgendwie noch nicht gut. Am Ende kommt keine Prüfung an einem manuellen Test vorbei. Das ist die einzige Möglichkeit, um wirklich tiefgehende Erkenntnisse zu formulieren.
Man könnte es auch andersherum sagen: Ein automatischer Test kann mir nie sagen, ob eine Seite oder ein Produkt barrierefrei ist. Er kann mir immer nur sagen, dass bestimmte Stellen nicht barrierefrei sind. Das klingt jetzt nach wenig und ist vielleicht auch ein bisschen frustrierend, aber es ist unglaublich spannend, und es ist erstaunlich, wie viel wir allein aus diesen Daten schon ableiten können. Also wie gesagt: Diese Sichtbarmachung von Strukturen, von Fehlerclustern, Fehlertypen und Zusammenhängen ist natürlich wichtig, wenn wir nicht nur dem einzelnen Fehler hinterherrennen, sondern statt der Symptome lieber die Ursache bekämpfen wollen. Dass wir sagen: „Ah, okay, hier ist folgende Software eingesetzt worden, und deswegen kommt dieser Fehler immer wieder rein. Lass uns mal schauen, ob wir diese Software austauschen können.“ Das kann man gerade mit diesen, ich sage jetzt mal, etwas „dumpferen“ Analysen schon sehr gut machen. Also da haben wir noch gar nicht das Ende der Fahnenstange erreicht, was wir da an Mustern und an Problemen in einer Organisation ablesen können.
Domingos: Ich meine, es wäre ja schon viel gewonnen, wenn Entwicklerinnen und Entwickler die Prüftools, die es schon gibt, einfach in der Developer-Pipeline nutzen und die Fehler natürlich beheben würden. Also ARIA korrekt einsetzen, valides HTML nutzen oder sehen, dass ein Label fehlt. Das sind ja diese häufigsten Probleme: Kontraste, das sind alles Dinge, die man relativ gut automatisiert finden kann. Wenn sie die schon vorher beheben würden, wären wir, glaube ich, alle dankbar.
Stefan: Genau, und das ist wieder dieser Punkt der Entlastung. Dann können du und ich uns mit Themen beschäftigen, die jetzt wirklich knifflig sind, und müssen nicht die Standardfragen beantworten. Also wie gesagt, ich habe überhaupt nichts dagegen, ich mache das total gerne. Wir sind diesen Monat ja auch wieder auf dem Barcamp, das sich ja explizit an unerfahrene Leute richtet, und ich mache das total gerne, Neulinge zum Thema Barrierefreiheit zu bringen. Das mache ich gerne, aber manchmal hat man so ein bisschen das Gefühl, dass man seine eigene Schallplatte hört, weil man sagt: „Hey, das habe ich jetzt schon mal erzählt – nicht nur einmal, sondern schon 20-mal.“ Und das macht auch nichts, wenn ich das unter Gleichgesinnten erzähle. Aber wenn man das dann in derselben Organisation beim nächsten Team noch mal wiederholt und dann ständig wiederholt, dann denkt man sich: Ja, okay, dann müsste man vielleicht irgendwann mal ein Tool einführen.
Genau. Also ich bin jetzt kein Verfechter, der sagt, alles nur noch automatisiert. Aber automatisierte Tests haben natürlich einen sehr großen Hebel. Und was halt wichtig ist: Diese Daten, die wir dort herausbekommen, benötigen eine Interpretation. Und ja, klar, natürlich liefert auch CAAT eine gewisse Interpretation, um auch vielleicht Neulingen und Organisationen, die das selbstständig machen, zu helfen. Aber natürlich kann ein Spezialist mit mehrjähriger Erfahrung diese Daten momentan noch viel besser lesen. Deswegen empfehlen wir auch immer, mit Spezialisten zusammenzuarbeiten. Gerne automatisierte Tools, aber halt noch ein Rahmenvertrag für einen Spezialisten, der in vielleicht größeren Abständen beratend dazu kommt, damit man einfach diese Expertise noch mit drin hat, um die Daten zu interpretieren und vielleicht die richtigen Priorisierungen zu setzen. Genau. Ich und das Testen… Jetzt haben wir uns wieder ein bisschen beim Testen verrannt.
Massen-Test von Behörden-PDF
Domingos: Ja, gar kein Problem. Ein Thema, was ich noch ansprechen wollte: Ihr habt ja mit axes4, ich glaube im Frühjahr, auch eine automatisierte Prüfung von barrierefreien PDFs – du hast ja axesCheck schon erwähnt – durchgeführt. Was war die Grunderkenntnis, die ihr daraus gewonnen habt?
Stefan: Die Grunderkenntnis… Ja, vielleicht ganz kurz, damit man die Grunderkenntnis auch richtig einschätzen kann: Wir haben eine relativ groß angelegte Studie durchgeführt und haben fast 70.000 PDF-Dokumente der öffentlichen Hand analysiert. Gefunden und grob analysiert haben wir ungefähr 120.000, aber 70.000 haben wir dann als studienrelevant eingestuft und diese dann alle mit dem PAC bzw. axesCheck getestet. Das Ergebnis war recht ernüchternd: Nur 9,5 Prozent der getesteten Dokumente, die in diesen Analysezeitraum reinfallen, sind PAC-konform. Das heißt, sie erfüllen überhaupt erst die maschinell prüfbaren Anforderungen an ein PDF-Dokument.
So, jetzt formuliere ich das natürlich schon so umständlich. Das heißt, von den 9,5 Prozent müssen wir auch noch einen unbekannten Anteil abziehen, weil maschinell prüfbar konform ja nicht automatisch barrierefrei bedeutet. Das heißt, die tatsächlich barrierefreien Dokumente liegen unter 9,5 Prozent, und das ist wirklich sehr, sehr erschreckend – da die öffentliche Hand das ja schon seit Jahren machen muss und wir auch nur PDFs ausgewertet haben, die nach dem gesetzlichen Stichtag veröffentlicht worden sind. Insofern deckt sich das auch ein bisschen mit den Aussagen der offiziellen BFIT-Bund, die auch um die 9 Prozent ermittelt haben.
Wir haben aber noch unterschiedliche Seiten getestet. Die BFIT-Bund ist ja nur für den Bund zuständig; wir haben vier Cluster gebildet, insgesamt 63 Webseiten getestet und die Cluster „oberste Bundesbehörden“, „Sozialversicherungsträger“, „Krankenkassen“ und „Städte“ gebildet. Die obersten Bundesbehörden, als natürlich wichtigste Organe in Deutschland, haben auch am besten abgeschnitten. Ich glaube, das liegt aber auch daran, dass die auch schon in der Vorgängerstudie von axes4 von 2016 bis 2018 immer wieder getestet worden sind. Damals wurden nur die Bundesbehörden getestet. Also da hat sich schon eine gewisse Sensibilisierung ergeben. Am schlechtesten abgeschnitten haben die Städte, was ich persönlich recht bitter finde, denn die Städte sind für die meisten Menschen die erste Anlaufstelle. Ne, also Hand aufs Herz: Wie oft warst du in letzter Zeit auf der Seite eines Bundesministeriums, wie dem Bundesumweltministerium? Das ist eher ungewöhnlich. Auf der Stadtseite ist man, weil man halt – was weiß ich – den Sperrmüllplan sucht, Events sehen will oder seine Adresse ummelden muss. Man ist auf der Stadtseite, und die wurden bisher recht wenig großflächig analysiert. Und genau das haben wir jetzt mal nachgeholt.
Uns war wichtig, dass wir mit dieser Studie auch einen datengetriebenen Beitrag liefern. Es gibt ja sehr viele Studien, die gerade herausgeschossen werden, und da werden mal zehn Seiten getestet oder nur die erste Seite von 20 Seiten. Das sind alles keine belastbaren Studien. Wir wollten wirklich eine Studie haben, mit der wir auch in unserer Community über den Diskurs weiterkommen und sehen können: Wo sind wirklich die Probleme, was kommt raus? Besonders spannend ist hier, dass wir ja auch die Autorensoftware ausgewertet haben. Wir können also sehen, wie viele Prozent von diesen fast 70.000 Dokumenten aus Word heraus erzeugt worden sind oder aus InDesign – wo der Schwerpunkt in der öffentlichen Hand praktisch besteht. Ja, und dann natürlich auch Kuriositäten wie Fotokopierer, die PDFs erzeugen, oder Dienstleister wie Canva.
Man muss das halt im Blick behalten. Das ist jetzt alles noch so, wo du sagst: „Ja gut, wenn jetzt fünf PDFs bei 70.000 von Konica, fünf von Minolta und drei von Canon erzeugt worden sind, ist alles gut.“ Aber es darf nicht mehr werden. Eigentlich muss auch das wieder bekämpft werden. Der Reflex, einfach schnell was auf den Fotokopierer zu legen und dann im Netz zu veröffentlichen, ist natürlich gefährlich. Und Canva, die ja den Markt groß angreifen: Der Dienst produziert momentan keine barrierefreien PDFs, die sind komplett ungetaggt. Da hoffe ich natürlich, dass der Dienstleister noch nachlegt und dass sich das nicht weiter verbreitet, völlig ungetaggte PDFs zu veröffentlichen.
Genau. Was haben wir noch herausgekriegt? Also wie gesagt, das ist sehr spannend. Vielleicht noch mal kurz die URL – wir können die dann nachher bestimmt auch veröffentlichen. Es ist alles kostenlos. Wie gesagt, das war uns ein wichtiges Anliegen, dass wir da wirklich eine Studie haben, mit der alle arbeiten können. digital-accessibility.report ist die URL. Und noch eins: Alle Webseiten, die jetzt zugegebenermaßen etwas unfreiwillig an dieser Studie teilgenommen haben, bekommen kostenlos ihre Daten. Also nicht alle Daten der Studie, sondern wirklich gezielt die von ihrer eigenen Webseite. Und genau das ist halt ein unglaublich großer Schatz. Es sind teilweise Tausende von PDFs, und wir hoffen, dass sie mit diesen Daten intern wieder besser argumentieren können, wo sie stehen. Wir haben das jetzt schon von den ersten Organisationen gehört, die gesagt haben: „Das ist fantastisch! Damit kann ich intern wirklich datenbasiert erklären: Nein, wir sind noch nicht so weit, wie wir sein müssten in der Barrierefreiheit, wir müssen da noch eine Schippe drauflegen.“ Und das nutzt man dann als Argumentationskette ganz gut. Also insofern, wenn jetzt hier ein Zuhörer oder eine Zuhörerin sagt: „Ich bin verantwortlich für die Bundesministeriumseite X oder für die Krankenkassenseite Y“ – auf die Seite gehen, sich melden, und wir geben euch die Daten, damit ihr damit intern hausieren gehen könnt.
Domingos: Man muss auch sagen: Viele von diesen Studien – oder ich nenne sie mal in Anführungszeichen „Studien“ – sind ja reines Marketing, ne? Eigentlich kommen sie von den üblichen Verdächtigen, um, weiß ich nicht, in die Zeitung zu kommen und Aufmerksamkeit zu generieren.
Stefan: Genau. Da wird auch oft… Also was mich total geärgert hat: Es werden oft Äpfel mit Birnen verglichen. Sagen wir mal, die Datenbreite ist nicht ausreichend und es wird nirgendwo erwähnt, wie getestet worden ist. Wir haben jetzt extra diese Seite aufgezogen, da wird alles erklärt. Wenn irgendwas unklar ist, schreibt uns an. Aber dort wird genau erklärt, wie wir die Werte gebildet haben, was wir verwendet haben, wie wir dazu gekommen sind und welche Sachen wir ausgeschlossen haben, damit das wirklich eine ernstzunehmende Studie ist und man wirklich damit arbeiten kann.
Und das wiederholen wir jetzt noch mal für Österreich. Das veröffentlichen wir dann Mitte Juli in Linz auf dem IKT-Forum.
Da sind wir auch gespannt – bin ich natürlich auch gespannt –, inwieweit Österreich besser abschneidet als Deutschland. Und ja, wir werden das jetzt nicht nächstes Jahr noch mal wiederholen, aber vielleicht in zwei bis drei Jahren. Dann wiederholen wir die ganze Studie und schauen, wie es sich verändert hat. Dann können wir sie auch noch mal erweitern. Wir haben es diesmal aus Zeitgründen nicht mehr geschafft, bei den Bundesländern noch tiefer reinzugehen. Auch Universitäten waren diesmal in Deutschland nicht dabei, die werden in Österreich dann diesmal dabei sein. Aber gerade Landesregierungen wären natürlich noch mal spannend. Tja, mal schauen. Also das wollen wir jetzt routinierter machen, aber wie gesagt: Jährlich bringt das nichts, es müssen ja auch erst mal Prozesse angestoßen werden.
mindscreen folgen
Domingos: Ja, auf jeden Fal. Die letzte Frage: Wo kann man euch am besten folgen?
Stefan: Das ist eine gute Frage. Also, wir sind auf jeden Fall auf LinkedIn – entweder ich als Stefan Farnetani, die Firma Mindscreen oder auch die Software CAAT. Und dann publizieren wir auf unserer Webseite Mindscreen.de auch immer, auf welchen Veranstaltungen wir sind. Wir sind relativ umtriebig – ich und meine Frau Annett Farnetani. Da kann man uns auch immer gut ansprechen und antreffen. Genau. Und sonst halt über die üblichen verdächtigen Kanäle, aber das sind so die wichtigsten, wo ich mich immer wieder freue.
Wenn ich gerade persönlich noch mal kurz schaue: Was habe ich als Nächstes? Wir haben jetzt das Barcamp in Tübingen, dann haben wir „Stadt, Land, Verwaltung“, glaube ich, heißt das in Berlin, was jetzt noch vor der Sommerpause ist. Dann Linz, das IKT-Forum in Linz. Dann haben wir die Sommerpause, und im Herbst kriege ich es nicht mehr ganz genau zusammen, wo ich demnächst überall bin. Aber auf jeden Fall auf der SightCity in Frankfurt oder der S-CON in Berlin sind wir sicher, da werden wir auch einen Stand haben – gemeinsam mit axes4 und IAAP DACH, so viel ich weiß, und noch ein paar anderen. Da freue ich mich auch schon drauf, das ist auch immer eine sehr tolle Veranstaltung. Genau, also insofern gerne vor Ort und sonst auf LinkedIn. Ja, ich freue mich auf Rückmeldungen!
Domingos: Ja, gut, dann vielen Dank für dieses interessante Gespräch. Ich denke mal, wenn man Interesse an dieser Automatisierung in CAAT oder an CAAT generell hat, dann kann man euch auch einfach ansprechen. Ihr macht ja auch regelmäßig Demos, wenn ich das richtig in Erinnerung habe.
Stefan: Genau, alle zwei Wochen, abwechselnd auf Deutsch und Englisch, und sonst auch einfach anschreiben. Nach der Demo gibt es immer einen kostenlosen Demo-Account. Man kann den Demo-Account auch ohne Präsentation haben. Also für die, die schon erfahrene Tester sind, die kommen dann meist recht schnell rein. Ich empfehle trotzdem noch mal kurz die Demo, aber man kann es auch so haben. Genau, das ist das Übliche. Schaut auf die Seite, da stehen auch die Preise, und sonst schreibt eine E-Mail. Wir antworten da immer recht flott.
Domingos: Genau. Ja, sehr cool, dann vielen Dank für das Gespräch. Ich drücke euch auf jeden Fall die Daumen, dass es weiterhin so gut läuft bei euch.