Hallo und herzlich Willkommen zu einer neuen Folge vom Podcast Software Testing. Ich bin euer Host Richie und hier live auf der OUP 2024 in München. Bei mir zu Gast gerade Andrea Nuzzi und Franziska Kroneck zum Thema Barrierefreiheit, das ja für viele Unternehmen ab 2025 extrem relevant wird. Zeit, sich also damit zu beschäftigen. Und in Barrierefreiheit steckt ganz schön viel drinnen, wie uns die zwei gleich erzählen werden. Viel Spaß bei der Folge.
Hallo Andrea, hallo Franzi, schön, dass ihr da seid. Schön, dass wir hier sein dürfen. Ja, hier ist die OUP 2024 in München und Tag drei jetzt schon. Man merkt schon, dass langsam bei mir schon mit der Energie, ich muss jetzt schon echt ein bisschen haushalten auch. Aber ich freue mich, dass wir diese Folge hier noch machen können. Ihr habt nämlich ein ganz besonderes Thema, was gerade ja eh auch in aller Munde ist, weil man jetzt da ganz viel
machen muss, nämlich Barrierefreiheit. Genau. Ja, was sind denn da so eure Erfahrungen? Womit beschäftigt ihr euch denn da in dem Kontext? Also das erste, womit wir uns beschäftigt haben jetzt in letzter Zeit ist das BFSG. Das ist ein neues Gesetz, das kommt ab 2025. Ab 28. Juli 25 müssen nämlich ganz viele private Unternehmen erstmals auch in Deutschland Barrierefreiheitsstandards
einhalten. Das war vorher nicht so und deswegen ist jetzt ein bisschen Eile geboten, weil viele Unternehmen das auch noch nicht auf dem Schirm haben und dann noch nicht gut darauf vorbereitet sind, dass sie jetzt diese Standards dann einhalten müssen ab 25. Die Konsequenzen haben es auch in sich. Das sind Strafzahlungen bis 100.000 Euro, Vertriebsverbote oder auch der Rückruf von Produkten und von Dienstleistungen. Deswegen genau das war so die Motivation, dass wir da uns mal
mehr damit beschäftigt haben, mit Barrierefreiheit. Da wird ja gerade bei vielen wahrscheinlich dann auch ganz schön Aufruhr sein, die das jetzt so mitbekommen, die Webseiten haben oder trifft das nur Webseiten oder auch Produkte? Ich bin kein Jurist, deswegen so juristische Texte, das müsste man glaube ich wirklich jemanden fragen, der Jura studiert hat, aber ja es sind auch andere
Sachen außer Webseiten. Vor allem elektronischer Geschäftsverkehr, immer wo Geld fließt und immer, wenn es Endkunden betrifft, also nicht B2B, sondern vor allem B2C, da sind sehr, sehr viele Produkte und Dienstleistungen betroffen. Zum Beispiel auch E-Books, Fahrkartenautomaten, alle Automaten, die so rumstehen, Parkautomaten, die Software davon, genau solche Sachen. Und was heißt denn in dem Kontext dann barrierefrei? Was muss ich denn machen, wenn ich mir meine
Webseite anschaue? Muss ich echt mal machen. Was heißt denn da barrierefrei? Barrierefreiheit heißt ganz einfach, dass so eine Website oder auch ein digitales Produkt, eine digitale Anwendung einfach und unkompliziert zu benutzen sein muss, egal welche Einschränkungen oder welche Behinderungen ein Benutzer hat. Das ist eigentlich das Grundprinzip, so kann man das ganz leicht
erklären. So eine Barriere, das ist ein Beispiel dafür, super kleiner Text auf einer Website. Wenn ich dann Sehschwierigkeiten habe, dann kann ich das nicht gut lesen und dann ist es nicht mehr barrierefrei, genau. Ja gut, das ist aber jetzt natürlich ganz schön viel Aufwand auch für die Unternehmen da ran zu gehen. Was sind denn so die größten Hürden so im Team? Wie gehen Entwickler und Tester so jetzt damit um? Genau das haben wir auch untersucht in unserer Arbeit.
Wir haben wirklich mal gesagt, wir nehmen uns die Perspektive ein von den Leuten, die es umsetzen müssen. Das sind vor allem die UX-Designer, die UI-Designer und die Softwareentwickler. Die sind meistens verantwortlich, das umzusetzen. Da haben wir gesagt, okay, wo drückt denn der Schuh? Was bräuchtet ihr denn? Was sind eure Herausforderungen, wenn es darum geht? Genau und da haben wir super
viele gefunden. Das reicht die halbe Stunde gar nicht, um die alle aufzuzählen. Aber wenn man das mal vielleicht ganz kurz zusammenfasst, dann ist es bei Designern vor allem, dass sie eine Möglichkeit brauchen, Barrierefreiheit von Beginn an irgendwie mit einzubeziehen in ihre Designs. Das Problem ist, dass die ganzen Standards und Normen darauf nicht ausgelegt sind. Das sind nämlich Erfolgskriterien oder Prüfkriterien. Die helfen Testern super toll weiter und Designern
aber nicht. Die müssen wissen, was jetzt wirklich von ihnen erwartet wird, welche Aufgaben sie zu erledigen haben und das erfahren sie nicht aus den Prüfkriterien. Bei Entwicklern ist es oft so, die fühlen sich oft, als wären sie komplett alleine gelassen mit Barrierefreiheit. Das heißt, sie sind oft die alleinigen Verantwortlichen und müssen das jetzt alleine umsetzen und sie fühlen sich auch oft handlungsunfähig, ein bisschen abhängig von den anderen Teammitgliedern,
weil sie nun mal ganz am Ende von dem Gesamtprozess sind. Das heißt, wenn am Anfang Barrierefreiheit vernachlässigt wird, dann sagt man am Ende, der Entwickler muss es jetzt noch rausreißen oder so. Das ist halt ganz oft nicht möglich. Das sind so die Hauptprobleme. Wir haben uns dann gesagt, wir brauchen irgendwie einen Ansatz. Wir müssen es irgendwie hinbekommen, dass das einfacher wird.
Dass Entwickler und Designer dann einen tollen Leitfaden haben, dass sie irgendwie rangeführt werden und zwar in einer Art und Weise, dass sie compliant sind mit den Gesetzesvorgaben und auch,
dass sie es gut einbeziehen können in ihren Entwicklungsprozess. Das heißt, wir wollen keinen neuen Prozess schaffen, das bringt nur mehr Probleme, als es löst, sondern die Arbeitsschritte, die müssen sich gut integrieren lassen in den Prozess, den die Leute eh schon benutzen, während sie eine Software entwickeln. Ja, ich glaube, das ist ein total wichtiges Thema. Ich hatte das jetzt im Podcast, kommt das die Tage immer wieder. Die Teams sind ja sehr häufig einfach featuregetrieben. Hier
und noch ein Feature, noch ein Feature. Und dann muss man dann so Sachen machen wie Security, das muss jetzt auch noch da mit rein. Oder jetzt halt eben Barrierefreiheit, das muss jetzt auch noch mal mit rein. Und das wird sehr häufig dann irgendwo so mal eine User Story gemacht. Und dann wird da kurz ein bisschen rumgebastelt und dann liegt das wieder und es
geht wieder nur auf Features. Das heißt, es kann ja nur funktionieren, das auch wirklich in den Prozess zu integrieren, dass man das auch wirklich dann auch immer wieder mit betrachtet. Genau, ja. Und was wir jetzt dann gemacht haben, ist, wir haben uns diese ganzen Normen und Standards mal angeguckt. Die wichtigsten davon, das sind vor allem die WCAG-Kriterien. Dann gibt es noch eine europäische Norm, die EN 301549 ist es. Und noch eine ISO-Norm, die ist gar nicht
gesetzesrelevant in Deutschland, aber in UK zum Beispiel. Und die hilft auch ein bisschen, das von Beginn an mit einzubeziehen, also Barrierefreiheit ins Projekt. Und wir haben die durchgeguckt, die ganzen Prüfkriterien und Erfolgskriterien sind es vor allem, und haben davon Aufgaben abgeleitet. Also tatsächlich To-Dos für Entwickler und Designer und auch Product Owner von Beginn an. Was sind das beispielsweise für Aufgaben, die ihr da rausgearbeitet habt?
Also wir sind noch dabei. Das ist ein sehr langer Prozess, sich da durchzuarbeiten, diese ganzen hunderte Seiten von Normen. Aber eine Sache ist zum Beispiel, es gibt ein Prüfkriterium oder ein Erfolgskriterium. Die Tastatur oder eine Website, die muss auch mit der Tastatur zu bedienen sein. Und jetzt hast du aber das Problem, Designer und Entwickler,
die wissen jetzt vielleicht nicht, wie das funktioniert. Das baut aufeinander auf. Das heißt zuerst muss man dem Product Owner oder dem Projektmanager sagen, wir müssen hier ein bisschen Budget und Zeit bereitstellen. Vor allem damit die Leute sich auch ein bisschen einarbeiten können in das Thema Barrierefreiheit. Als nächstes ist der UX-Designer dran. Der muss dann die Navigation bestimmen, wie ich oder in welcher Art und Weise ich durchklicke mit der
Tastatur durch die Seite. Und dann braucht man am Ende den Entwickler, der sagt, er nimmt jetzt diese Tab-Reihenfolge, die der Designer schon entwickelt hat und implementiert die noch in den Code. Und so baut das aufeinander auf. Und das sind praktisch drei Aufgaben für drei verschiedene Rollen. Die stehen aber alle in einem Erfolgskriterium. Also ich denke jetzt gerade an den Tester. Der hat es ja dann am einfachsten. Der nimmt sich einfach den Normen her und guckt
sich diese Erfolgskriterien dann durch. Der hat dann gar nicht so viel Aufwand. Ja, genau. Diese Standards und Normen, die sind auch aus Testersicht gemacht. Und das ist halt auch das Problem in den Projekten. Wir müssen das ein bisschen umformulieren, dass es auch für die Designer und für die Entwickler leichter anzuwenden ist. Konntet ihr denn das schon ein bisschen verproben auch? Also diese Aufgaben auch mal mit Entwicklern dann auch durchzusprechen,
wie die das... Wir sind dabei. Also mit Entwicklern haben wir es noch nicht verprobt. Wir haben es schon mit UX-Designern verprobt. Und die sind ganz angetan. Also die waren ganz begeistert, weil sie jetzt endlich mal eine To-Do-Liste haben und wirklich sagen, okay, jetzt weiß ich, was von mir erwartet wird. Jetzt ist es übertragbar in meinen Arbeitsablauf, in meinen Arbeitsalltag. Und das hatten sie vorher nicht und das fanden sie ganz toll.
Ja. Mit den Entwicklern müssen wir es noch testen. Was schätzt du denn, also wenn ihr so begonnen damit und ich meine, die Normen sind auch sehr umfangreich. Wie viele Aufgaben werden denn da rausputzen? Sind die alle dann auch relevant oder sind die irgendwie gewichtet? Also sie sind schon alle relevant. Es sind momentan 29 Aufgaben. Da werden sicher noch ein paar dazukommen. Meine Einschätzung ist momentan, dass es auf gar keinen Fall über 50
werden. Es wird wahrscheinlich in dem Bereich 30 bis 40 bleiben. Also es ist gar nicht jetzt so, ich sag mal, ein Mörderumfang. Und im Vergleich zu den Kriterien, zu den Erfolgskriterien, da haben wir ja hunderte, hunderte Kriterien. Und der Grund, warum es weniger Aufgaben sind, ist, weil viele Guidelines sich in den Aufgaben überschneiden. Das heißt, ich kann zum Beispiel bestimmte Guidelines aus den WCAG nehmen und zusätzlich bestimmte Guidelines
aus der europäischen Norm. Und das ergibt dann am Ende alles eine Aufgabe für einen Designer. Ja, das ist ja nachvollziehbar. Es ist natürlich trotzdem die Frage, wie groß ist dann der Aufwand, diese Dinge umzusetzen. Das kann natürlich schon viel sein, auch bei 29 oder 30 oder 40. Da ist immer die Frage, wie viel Aufwand steckt denn dann dahinter? Das haben wir uns auch angeguckt. Wir haben momentan so eine Einschätzung. Also wir versuchen
zu jeder Aufgabe einen geschätzten Aufwand mit dazu zu geben. Die Aufgaben, die am allermeisten Aufwand brauchen, da kann man schon mal mit zwei Wochen rechnen. Aber andere Aufgaben sind auch wirklich in ein bis drei Tagen erledigt. Hast du da so Beispiele für, was schnell geht und was lange braucht? Natürlich ist es immer vom Kontext anzudringen, aber...
Ja, zum Beispiel Alternativtexte formulieren. Das ist die Aufgabe vom UX-Designer. Die Alternativtexte für zum Beispiel Grafiken, die müssen ja nicht nur implementiert werden, sondern da müssen auch die richtigen Informationen drin sein. Und diesen Informationsgehalt, was denn da drin sein muss, das ist relativ schnell gelernt. So ein bis drei Tage sollten da reichen, dass man sich durchliest, für welche Bilder brauche ich Alternativtexte,
was ist der Informationsgehalt und das Ganze dann zu formulieren. Wenn ich jetzt sage, ganz am Anfang vom Prozess, ich möchte meine Benutzer besser verstehen, vor allem die mit Einschränkungen, dann muss ich da Research durchführen. Dann muss ich die zum Beispiel interviewen. Und um mal fünf, zehn Benutzer zu interviewen mit unterschiedlichen Einschränkungen und daraus die Bedürfnisse abzuleiten, da brauche ich dann schon mal zwei Wochen,
weil ich das Ganze vorbereiten muss. Ich muss vor allem Leute finden, das heißt, ich muss die recruten und das Ganze dann auch noch auswerten. Das ist eine Aufgabe, die würde zwei, drei Wochen dauern. Was sind denn jetzt so, wenn ich jetzt, also im Primärfall, viele wird es halt bei der Website irgendwo wahrscheinlich treffen, weil das ja oft nach außen auch das ist, was so sichtbar ist und wo man so viel Kundenkontakt
hat. Tastatursteuerung hast du gesagt, was gibt es denn da noch für Kriterien, die dann da so drin sind? Das müssen ja eigentlich alle durchgehen, aber so ein Gefühl dafür bekommen, was muss ich denn da so beachten? Ah, da gibt es einen Haufen. Also die einfachsten, die gängigsten Sachen, das sind vor allem die Tastatursteuerung, dass Leute mit der Tastatur, aber auch mit dem Screenreader,
also für blinde Menschen durch die Website sich navigieren können. Farbkontraste sind ganz wichtig, das heißt, ich brauche Kontraste, die hoch genug sind für Menschen, die Farbfehlsichtigkeiten haben, für Menschen, die Sehschwächen haben. Das sind so zwei der allergängigsten Dinge. Textgröße ist auch eine Sache, die super einfach umzusetzen ist. Ich muss den Text groß genug anbieten,
es reicht nicht, wenn der so winzig klein auf der Seite ist. Ich meine, das kann natürlich, solche Sachen können natürlich auch im Widerspruch stehen dann zu einem Corporate Identity oder so was. Also gerade wenn ich eine blasse Pastellfarbe irgendwo habe in meinem CI, da kriege ich die Kontraste vielleicht gar nicht so hin. Also ich muss ja da wahrscheinlich aus der ganzen Softwarethematik auch noch mal weiter rausgehen. Ja, das ist eine große Herausforderung von den
Designern, dass die oft zwei Probleme haben. Das eine ist, sie fühlen sich oft ein bisschen verunsichert, weil sie denken, wenn sie diese Standards einhalten, vor allem im gestalterischen Bereich, dann vermindert das so die Ästhetik von der Website. Und das andere ist genau diese Corporate Identity. Wenn sie Komponenten bekommen, das betrifft übrigens Entwickler ganz genauso, wenn diese Komponenten vordefiniert sind, alles, was sie dann noch tun können, ist darüber zu
informieren. Also zu sagen, das ist nicht barrierefrei, aber da habe ich jetzt keinen Einfluss drauf. Genau. Das ist so, da müssen die Standards verändert werden. Da hat man keinen Einfluss drauf. Jetzt ist ja gerade so, auch mit diesen ganzen, wenn man jetzt natürlich in jeder Folge, müssen wir auch ein bisschen über KI sprechen. Habt ihr denn da auch mal so drauf geschaut, was das helfen kann oder wie man damit rangeht? Ja, ob es Tools gibt, die helfen bei der
Umsetzung von Barrierefreiheit, das weiß ich nicht. Aber KI lässt sich zum Beispiel gut einsetzen auf Webseiten, Large Language Models, um zu sagen, ich möchte eine vereinfachte Version von dem Text. Gerade wenn es um Behörden geht, wir wissen alle Behördenwebseiten, wie kompliziert die Texte da sind. Ein Kriterium für Barrierefreiheit ist auch die leichte Sprache, verständliche Sprache für
Menschen, die Konzentrationsschwierigkeiten haben. Und da muss das, wäre zum Beispiel so ein Large Language Model super easy, wenn man da sagen würde, gib mir mal diesen Absatz da, so raus, dass ich den auch verstehen kann, ohne Fachbegriffe, ohne englische Wörter. Ich habe letztens ausprobiert, fällt mir gerade ein auf meiner Website, für diese alternativen Texte habe ich so einen KI-Generator, der sich das Bild anschaut und daraus alternative Texte formuliert. Und die ersten zwei, das war
super, was da rausgekommen ist. Und man dachte, ach klasse. Und dann kam aber auch ganz viel Grütze raus. Da habe ich aber gedacht, das ist doch nicht so, dass es nur damit geht. Also ich kenne persönlich auch kein Tool, das schon etabliert ist oder so von KI. Also wir haben jetzt diese ganzen Kontrastgeschichten auf der Website. Wie ist das so mit Audio, mit solchen Sachen? Oder Videos, gibt es da auch irgendwie Vorgaben in die Richtung? Ja klar, also Videos müssen auch, zum Beispiel muss
es immer möglich sein, sie anzuhalten. Das ist tatsächlich eine Vorgabe von Barrierefreiheit. Stop and Go. Ich muss Untertitel haben für meine Videos, für die Audioausgabe. Also das heißt, alles was nicht Text ist, das sind Videos, Grafiken und auch alles andere, die müssen Alternativtexte haben. Das heißt, ich muss irgendwie eine textuelle Form anbieten. Da gibt es Ausnahmen, die müssen aber dann auch extra deklariert werden, damit so ein Screenreader weiß,
wie er damit umgehen kann. Ich sehe gerade einen Haufen Arbeit auf mich zu. Aber ich kann ja dann vielleicht auch noch eure Checkliste nutzen, eure Aufgabenliste. Du seid jetzt da gerade mittendrin in dem Prozess. Was schätzt du, wann wird es, also was habt ihr euch für eine Zeit genommen, da abzuschließen? Und vor allem dann auch mit den Ergebnissen, sind die dann öffentlich oder ist das dann quasi nur den Kunden vorbehalten oder den Projekten? Wie geht ihr damit
um? Also erstmal, das wird bestimmt noch eine Weile dauern, bis wir da durch sind, weil wir erstmal diese ganzen Aufgaben ableiten müssen. Das ist eine große, super viel Arbeit. Und dann möchten wir das Ganze erstmal verproben. Das heißt, auch mal testen, ob es denn tatsächlich was bringt mit Designern und Entwicklern. Und dann nochmal iterieren. Das heißt, das Feedback mit einarbeiten. Da werden wir vorm Sommer definitiv nicht damit fertig mit dem Ganzen.
Und wie wir das Ganze dann veröffentlichen, das wissen wir noch nicht ganz genau. Da müssen wir mal gucken, wie wir das zur Verfügung stellen können. Ja gut, ihr werdet in den Show Notes ja auch eure Kontaktdaten haben. Alle, die jetzt Panik haben, die sagen, wir brauchen eure Unterstützung, ihr müsst mir helfen. Und das ist ja dann ab Sommer noch ein Jahr Zeit. Also Sommer 2025 ist
es dann ein Ding. Und es hat natürlich schon ein Gewicht, auch wie eine DSGVO, wie diese ganzen Cookie-Geschichten und so was, die ganzen Security-Sachen, schon viel, was da auch gemacht werden muss. Genau, deswegen haben wir auch geguckt, dass unsere Aufgaben super einfach und
verständlich zu verstehen sind. Also da wird niemals was super Kompliziertes drinstehen. Dass der Aufwand sich relativ gering hält und dass wir die Informationen dazu, die sind immer so gegeben, dass es der richtigen Person zum richtigen Zeitpunkt im richtigen Umfang zur Verfügung steht. Das heißt, wir werden hier niemanden durch Leitfäden oder Kriterien durchleiten,
der diese Informationen in dem Moment nicht benötigt. Und eine Sache ist vielleicht auch noch wichtig, vielleicht off-topic ein bisschen, je später ich Barrierefreiheit integriere, desto teurer wird es. Das ist vielleicht auch noch wichtig zu wissen, wenn ich das von Anfang
an mit einplanen und mit einbeziehe, dann spare ich mir am Ende einen Haufen Geld. Weil wenn ich eine Website fertig mache und dann mir so einen Test mal hole, so einen Bit-Vau-Test und dann sagt er das und das und das hast du alles falsch gemacht und musst du ändern, dann kann das durchaus teuer werden. Und oft ist es so, dass es gar nicht mehr so einfach ist, es im Nachhinein barrierefrei zu bekommen und man muss es neu aufsetzen. Das heißt... Ja, das Leid kennen wir aus dem Test mit
all diesen nicht-funktionalen Dingen. Man testet am Schluss die Performance, kommt darauf, die Architektur ist gar nicht so darauf ausgelegt und dann kann man so richtig nochmal rein und das kostet richtig Geld als Security. Es sind ja oft diese Dinge, die dann einfach am besten von vorhinein schon mit betrachtet werden. Ja, da kommt viel zu auf die Entwickler. Noch eine Sache, die sie zusätzlich beachten müssen. Ja, super. Ich danke euch herzlich hier für diesen Einblick.
Sehr spannend. Ich glaube, da kommt auf einige auch noch was zu. Ich hoffe, das rüttelt jetzt auch noch mal das eine oder andere Team auf. Da denkt man sich, oh ja, da sollte man vielleicht auch mal was machen. Vielen Dank, dass ihr hier wart im Podcast. Ich wünsche euch noch ganz viel Spaß auf der OOP. Dankeschön. Den Resttag. Bis bald. Mach's gut. Danke, dass wir hier sein durften und das mit dir aufnehmen durften. Gerne.