Hallo und herzlich willkommen zu einer neuen Folge vom Podcast Software Testing. Ich bin euer Host Ritschi und ich freue mich wieder eine Folge vom QS-Tag 2023 mitbringen zu dürfen. Diesmal im Gespräch Dirk Haas und Thorsten Schröder mit dem Thema Barrierefreiheit. Dirk und Thorsten beschäftigen sich mit Barrierefreiheit im Kontext der deutschen Rentenversicherung,
im Besonderen was die mobile App Entwicklung angeht. Auf welche Probleme sie dabei stoßen, wie Assistenzsysteme funktionieren und wie man sich dem Ganzen annähern kann, darauf gehen sie jetzt im Podcast mit mir ein. Wenn Dir dieser Podcast Spaß macht, wenn Du Freude daran hast ihn zu hören und es gar nicht erwarten kannst, bis der nächste Dienstag da ist, dann freue ich mich natürlich sehr über eine Bewertung und ein Like auf den üblichen
Portalen und jederzeit natürlich über Feedback am [email protected]. Und jetzt viel Spaß bei der Folge. Hallo, schön dass ihr da seid. Danke für die Einladung. Ja, sehr schön, das freut mich. QS-Tag 2023 Frankfurt, zweiter Tag, es geht so langsam in die Zielgerade rein. Ihr habt euren Vortrag auch schon gehabt, schon euer Thema präsentiert und jetzt noch hier so
den Podcast zum Abrunden. Unser Premieren-Podcast. Der Premieren-Podcast noch dazu. Genau, es soll ja um das Thema Barrierefreiheit auch gehen, das ist euer Vortragsthema gewesen und da wollen wir noch ein bisschen unterhalten, gerade von den Schwierigkeiten, vom Test her. Da würde ich euch einfach mal den Ball auch rübergeben und sagen, was hat euch denn da bewogen dazu, auch so ein bisschen von den Rahmenbedingungen das Thema auch intensiver anzugehen? Tatsächlich
war es so, dass wir einen Testauftrag hatten. Wir sollten eine App auf einem iPad testen, dann mit Tastatursteuerung und dann festgestellt, dass es plötzlich ganz was anderes ist. Das heißt, davor alle Tests am normalen PC gemacht, mit Tastatur, mit Maus, eventuell noch einer Kamera dran. Dann ging es darum, was sollen wir denn jetzt testen? Die assistive Software, die auf
dem PC läuft, ist auf den Mobile Devices schon drauf. Das heißt, ich mache jetzt plötzlich dann mal das Voice-Over an oder Talkback auf den beiden Systemen, dass ich eine Vorlesefunktion habe und mache dann mit der Tastatur und merke, sie verhält sich plötzlich ganz ungewöhnlich, weil ich das Standardverhalten, was die Anwendung eigentlich hat, nämlich mit Wischen und Tippen und ähnlichen Dingen, plötzlich jetzt mit einer Tastatur durchführen soll. Dann haben wir dann
gemerkt, da gibt es unendlich viele Schaltermöglichkeiten, die man einstellen kann. Dann verhält sich aber die Anwendung plötzlich ganz anders. Wir müssen ja den Zustand, wie wir getestet haben, genauestens dokumentieren. Dann musst du dir überlegen, welchen Schalter schaltest du denn jetzt ein? Was ist denn noch wichtig? Und wenn ich den Schalter einschalte, was bedeutet das für Menschen mit anderen Behinderungen? Wenn ich jetzt diese Talkback-Funktion einschalte, ist das sehr
gut für Blinde. Aber der motorisch Eingeschränkte kann dann plötzlich nicht mehr vernünftig mit seiner Tastatur arbeiten. Das ist so dieses Problemfeld, in dem wir uns bewegt haben. Das haben wir gedacht, das ist ja gerade auf so einer Veranstaltung, wo es ums Testen geht, vielleicht interessant, da mal einen Blick drauf zu werfen. Wir haben keine Lösungen, wir haben nur ganz viele Probleme. Es ist ja auch immer gut, dass man die immer wieder sichtbar hat.
In welchem Kontext ist denn diese App? Könnt ihr da ein bisschen sagen, worum es da geht? Da ging es tatsächlich um so eine mobile Patientenakte. Das heißt also, die Ärzte nehmen dieses iPad, auf dem sich diese App dann nun befindet und wollten mit dieser App klar ihre Berichte tatsächlich erstellen bzw. dokumentieren. In der Regel sind die Ärzte nicht davon betroffen, aber dennoch gibt es ja die Vorgabe für uns tatsächlich nur barrierefreie Software
einzusetzen. Dementsprechend kam es zu uns zum Testen und wir haben dann festgestellt, wenn wir schon alleine das iPad in dem Fall nur drehen, hat es sich schon anders verhaltet, weil es eben vom Portrait-Modus zum Landscape-Modus auch einen Unterschied gibt. Und so könnten einige Sachen nicht erreicht werden, wenn wir zum Beispiel auf eine Tastatursteuerung oder über VoiceOver gegangen sind, weil diese Elemente halt beim Wischen nicht mit fokussiert wurden,
zum Beispiel. Und dann haben wir mit unserem Team in Berlin beraten, wie macht ihr das, was habt ihr für Erfahrungen, weil da auch jemand ist, der schon mehr Erfahrung tatsächlich mit der App-Testerei hatte als wir. Und ja, dann sind wir zu dem Entschluss gekommen, dass wir uns nicht einig sind, wie man es testet, weil wir haben dann einfach gesagt, wir müssen das probieren,
wir müssen das probieren. Und wie der Dirk gerade sagte, wir stellten dann fest, dass sich teilweise die Einstellungen für motorisch eingeschränkte Blinde oder vielleicht
auch sogar stark Sehbehinderte gegenseitig behinderten. Und dann eben tatsächlich das rauszufinden, da so eine Testmatrix zu entwickeln, war für uns eine Herausforderung, wo wir auch immer noch tatsächlich, ja immer noch so ein bisschen spielen und auch tatsächlich nicht wissen, wann bitte schön ist diese Anwendung dann nicht mehr barrierefrei, weil ich ja extrem viele Sachen tatsächlich kombinieren kann. Ja, ja. Habt ihr so ein Beispiel für so ein Trade-Off,
also wo man so quasi, wo sich die Dinge gegenseitig übergeben? Ja, es gibt für motorisch eingeschränkte Menschen gibt es die Möglichkeit der Schaltersteuerung, das heißt, die Elemente auf der Seite werden entweder manuell gesteuert, in dem Falle, wir haben es eingestellt durch Kopfbewegung, also die Kamera von dem iPhone reagiert auf mich, indem ich meinen Kopf bewege, navigiert zum nächsten Element und ich kann dann zum Beispiel mit einem Geräusch auslösen, dass dieses Element gestartet
werden soll. Das kann ich aber nicht gleichzeitig machen mit Voice-Over, also wenn ich blind bin, habe ich so keine Chance damit zu arbeiten. Es wäre natürlich auch eine ziemlich heftige Kombination von Behinderungsarten. Nichtsdestotrotz, wir fertigen ja einen Prüfbericht an und die Kriterien stehen alle nebeneinander und es gibt jetzt kein Kriterium, was sagt, das musst du jetzt aber nur für blinde Benutzer testen und das musst du nur für motorisch eingeschränkte benutzen. Es
ist immer der gleiche Satz. Ja. Und das muss man halt einschränken. Ein sehr schönes Beispiel, was wir an Problemen noch haben, ist, dass diese Mobile Devices extrem viele Möglichkeiten bieten mittlerweile alternative Eingaben zu tätigen. Das Klassische ist, was jeder schon mal gesehen hat, man schüttelt das Handy und die Daten werden alle verworfen. So, jetzt gibt es ein Prüfkriterium in der WCAG, steht als Prüfkriterium drin, Gestensteuerung, Bewegungssteuerung müssen
alternativ auch mit einem Finger gemacht werden können. So, jetzt müsste die Software das ja eigentlich anbieten. Nehme ich aber ein iOS-Gerät, habe ich die Möglichkeit assistiven Touch einzuschalten, habe ich diese Funktion, habe ich da. Ich kann den Finger drauflegen und dann simuliert das Handy dieses Schütteln. Ist die Software jetzt barrierefrei oder ist die Software nicht barrierefrei? Also, liefert es es eigentlich selber nicht, wird sie aber für dieses Umfeld nur angeboten,
funktioniert es ja trotzdem. Und dem Menschen, der es benutzen muss, ist es egal, ob der es tut oder der es tut. Das ist so dieses Spannungsfeld, in dem wir uns bewegen. Das ist äußerst spannend. Mit jedem Release kommen neue Bedienhilfen und jedes Mal müssen wir neu gucken. Weil das ist etwas, wo es wirklich sehr viel Neues gibt, immer wieder. Zumal auch tatsächlich diese Hilfsmittel zugelassen sind. Also, man darf mit Hilfsmitteln arbeiten. Trotz alledem ist die
Kombination eben immer noch sehr, sehr schwierig. Wie habt ihr euch denn dann begonnen, dem Ganzen zu nähern? Also, ihr habt festgestellt, so einfach ist es nicht. Wie seid ihr denn da so dann vorgegangen? Wir haben uns tatsächlich mehrfach hingesetzt, haben Tasten oder Schalterkombinationen ausprobiert, haben geguckt, welche Konsequenzen das hat. Und wenn ich diesen Schalter nicht setze, kann ich dann in der einen Behinderungsart, also jetzt von mir als Mensch, der nicht sehen kann,
alles bedienen. Dann ist das für uns, für diese Arten der Behinderungen tatsächlich auch bestanden. Aber das müssen wir alles explizit vermerken, weil der Nächste macht diese Schaltersteuerung nicht und sagt, ja, ich versuche mit dem Ding zu arbeiten. Er hat gesagt, das ist barrierefrei, ich komme nicht einen Schritt weiter. Deshalb haben wir es versucht, haben es dann wieder niedergeschrieben und gesagt, in der Konstellation funktioniert es. Das macht aber den Prüfbericht,
den wir abgeben, extrem eng vom Geltungsbereich her. Es geht ja nur unter den Konstellationen. Und wir können nicht alle Schalter abbilden. Das sind hunderte mittlerweile an Kombinationen von Schaltermöglichkeiten, die wir da haben. Wir machen es im Moment so, dass wir das, was wir geschaltet haben, auch wirklich auflisten und auch was wir explizit nicht einschalten, was zu Fehlern führt. Mehr können wir im Moment einfach nicht leisten.
Zumal wir dann von dem Auftraggeber in dem Fall, der gesagt hat, ihr müsst es testen, wir wollen es einsetzen, dann bekommen, als wir was abgelehnt haben, gesagt haben, das funktioniert nicht. Wo es dann kam, ja, bei Apple, das war tatsächlich ein iPad, aber Apple hat genau so eine Funktion integriert, da funktioniert es auch nicht. Dann sind wir so in der Rechtfertigung, ja, okay, bei Apple funktioniert es auch nicht.
Apple schreibt sich auf die Fahne, barrierefrei zu sein. Kann man auch tatsächlich so grob unterstreichen. In dem Fall ging es aber tatsächlich um eine Steuerung von Bildbearbeitung und ein Blinder macht in der Regel keine Bildbearbeitung. Und damit konnten wir uns dann so ein bisschen rechtfertigen. Akzeptiert haben sie es trotzdem nicht. Das muss man ganz klar sagen. Wie gesagt, das kommt dann auch so ein bisschen auf die Akzeptanz an.
Was wird akzeptiert? Und vor allen Dingen bei uns in dem Fall, was Dirk ja auch schon gesagt hat, wir müssen sehr, sehr viel probieren und es dementsprechend auch dokumentieren. Habt ihr euch dann da so eine Testfallmatrix auch irgendwie gebaut oder so Szenarienmatrix? Wie habt ihr das dann für euch dokumentiert auch?
Wir haben die entsprechenden Use Cases dokumentiert. Das heißt, wir sind, weil wir nur für unsere Firma arbeiten, aktuell für die internen Produkte oder die externen Produkte, die bei uns eingesetzt werden, fordern wir vom Auftraggeber die relevanten Testfälle an. Und für diese Testfälle haben wir dann jeweils dokumentiert, in welcher Konstellation wir auf
welche Hindernisse gestoßen sind. Mehr können wir da an der Stelle auch nicht. Wir haben aber das Glück, dass wir einfordern können, relevante Fälle uns zu nennen, die wir bearbeiten müssen. Wenn wir uns das selber noch erarbeiten müssten, müssten wir ja die Vorgabe geben, was ist denn jetzt relevant? Trägt der jetzt bei der App zum Beispiel jeden Tag fünfmal den Blutdruck ein oder nicht? Hat der eine ganz andere Relevanz als irgendeine Zahl, die nur einmal erfasst wird am Anfang des
Krankenhausaufenthalts oder ähnliche Dinge? Das können wir gar nicht beurteilen. Wir haben so eine Vielzahl von Produkten, die wir begutachten. Wir können uns nicht überall in jede Software so tief einarbeiten, dass wir vorgeben könnten, was ist relevant daran und was nicht. Das sind so komplexe Dinge dazwischen. Und auf dieser Basis machen wir dann halt die Dokumentation.
Genau, Learning by Doing ist oft tatsächlich der einzige Weg. Was wir vermeiden ist, dass wir innerhalb eines Use Cases für eine Behinderungsgruppe anfangen, dann unterschiedlich zu experimentieren. Das heißt, dass wir innerhalb eines Use Cases sagen, wenn er an der Stelle ist, muss er halt einfach die Bedienung umstellen, um dann weiterzumachen. Das machen wir nicht. Also entweder es klappt mit dem tatsächlich mit der Einstellung oder wenn wir eine andere Einstellung machen,
es klappt mit der. Aber der erste Teil mit der Einstellung, der zweite Teil mit der Einstellung, dass man umstellen muss, das ist nicht zumutbar. Das funktioniert nicht. Habt ihr in dem Bereich irgendwie eine Möglichkeit auch zu automatisieren bei diesen Dingen oder ist das eigentlich nicht relevant? Wir sind im Moment in dem Zustand, dass wir rein manuell testen. Nicht explorativ, aber doch rein manuell nach unseren Vorgaben. Wir haben festgestellt, dass was wir testen ist ja tatsächlich,
ob die Technologie Zugang zu den Inhalten bekommt, um sie darstellen zu können. Also ein Screenreader muss Zugang zum Element haben, zu den Eigenschaften, zum Status oder ähnlichen Dingen, um den vortragen zu können. Die Software, die das testet, müsste ja den gleichen Zugang haben. Das ist so, wenn wir einen automatischen Testfall haben und das Feld kann ich nicht ansteuern, dann kann ich auch keinen automatischen Test schreiben. Wenn ich das nicht eineindeutig
einsteuern kann, wie soll ich das dann mit einem Wert füllen und testen? Und die Mängel, die wir beanschreiten, sind ja genau diese, dass die Software nicht darauf zugreifen kann. Wir testen ja eigentlich, ob eine Technik Möglichkeiten hat, dran zu kommen. Wenn die nicht gegeben sind, wie soll ich das dann automatisch testen? Es gibt immer mal wieder Testtools, die gab es jetzt immer wieder, sind auch heute auch mal welche vorgestellt
worden, die zum Beispiel so etwas wie Validität oder Parsing von HTML testet. Das hat aber für einen Menschen, der eine Behinderung hat und damit arbeiten muss, überhaupt keine Relevanz. Wir sind eher bei dem Ansatz, wenn es jemand erledigen kann die Aufgabe, dann ist für uns das Kriterium erfüllt. Das zeigt sich jetzt auch daran, dass dieses Kriterium des validen HTML oder das Parsen des HTML ist mit der aktuellsten Version der Vorschriften,
mit der WCAG 2.2 aus dem Prüfregister gelöscht worden. Das ist das erste Mal, dass überhaupt ein Prüfkriterium rausgenommen worden ist. Das stammt noch aus den Zeiten, als Browser dann in dem Falle nicht valides HTML nicht vernünftig interpretieren konnten. Stand dann schief oder ähnliche Dinge, es wurden Sachen nicht richtig dargestellt oder es wurden Sachen nicht richtig interpretiert. Die Sachen sind mittlerweile so robust, das stört die
nicht mehr. Das ist jetzt aber das Problem. Wir haben ganz viele Testtools, die gerade diese Sachen testen und finden. Die würden jetzt, wenn man dieses Testkriterium rausnimmt, plötzlich nicht mehr 60% der Fälle abtesten, sondern vom Finding her dann vielleicht noch 30% oder ähnliches. Das wird wirklich spannend werden, wenn sich das jetzt durchsetzt. Ist im Moment noch nicht so, weil WCAG ist WCAG, das W3C-Konsortium, sehr schön, aber die
geltenden Rechte, Gesetze und Normen, die verweisen nur auf die WCAG. Und wenn da irgendwas drinsteht in der WCAG, wo ich nicht darauf verweise, aus der Norm, ist es ja für die Norm erstmal nicht geltend. Das heißt, wir müssen jetzt warten, bis die europäische Norm 301549 angepasst wird, dass zum Beispiel der Punkt 411 gelöscht wird. Das ist das
mit dem Parsen. Bis dahin kann sich jeder noch hinsagen, hier, geltendes Recht. Ist ja schön, dass das irgendwann wegfällt, aber es ist halt noch nicht durchgesetzt. Das wird lange dauern. Normungsgremien auf europäischer Ebene sind nicht wirklich schnell. Ihr habt jetzt von Apple gesprochen, aber auch Android betrachtet, ist quasi beide Welten. Wie ist denn das oder der Unterschied, was diese Assistenzsysteme angeht? War da ein
großer Gap oder andere Umsetzungen? Es ist halt so, dass, ich sage das immer so gerne, Steven Jobs damals sicherlich nicht nur im Kopf hatte, die Behinderten mitzunehmen, weil er von vornherein hat Apple von vornherein auf alles gesetzt. Also gleich Screenreader überall installiert und auch diverse assistive Systeme, sondern dass er auch da sicherlich ein Business Case oder beziehungsweise auch eine Möglichkeit gesehen hat, Geld zu generieren.
Aber ich sage mal, mittlerweile ist der Vorsprung von Apple nicht mehr so groß, weil man es auf Android natürlich ganz klar alles auch dementsprechend nachgezogen hat, beziehungsweise nachziehen kann, auch immer noch manuell. Was aber da natürlich einen großen Punkt oder einen führenden großen Vorteil von Apple spricht, ist, wenn ich einmal ein Handy gehabt habe, wechsle ich nicht so schnell. In der Regel gewöhnen wir uns nicht schnell
um. Jemand, der auf diese Assistenzsysteme angewiesen ist, tatsächlich auch nicht so schnell. Und mit jeder Version von der neuen iOS-Version bringt Apple wieder ein neues Feature. Zum Beispiel haben sie jetzt bei der Lupe mitgebracht, dass sie eine Türerkennung haben. Ich erkenne den Menschen. Was ist es? Ich erkenne tatsächlich ein Glas, wenn ich
meine Kamera darauf halte, das kann ich alles machen. Da ist der Vorsprung noch da, was natürlich auch bedeutet, wir haben mehr Möglichkeiten zu testen und das macht natürlich diese Testmatrix nicht kleiner. Das ist halt eher größer, weil ich hätte ja die Möglichkeit, wenn ich den Text nicht erkenne, eventuell tatsächlich mit der Kamera drauf zu gehen, um ihn mir vorlesen zu lassen. Deshalb, bei Android ist das aber tatsächlich, ich würde jetzt nicht
sagen, dass es da einen extremen Vorteil gibt. Ich glaube einfach, dass der Vorsprung von Apple, auch aufgrund dieser Tatsache, dass sie es von vornherein gemacht haben, etwas größer ist. Aber wie gesagt, du bist mehr der Android-Nutzer. Du hast da vielleicht noch einen... Ich kenne aber kaum Menschen. Es wird ja sehr oft an blinden Menschen festgemacht. Ich kenne kaum jemanden, der blind ist und der nicht ein iPhone hat. Ist halt so ohne
Werbung dafür zu machen. Aber weil es vorher da war und man sich einmal eingestellt hat, da geht man nicht mehr von weg. Die Funktionalitäten sind mittlerweile fast eins zu eins in beiden Systemen zu finden. Es macht keinen Unterschied mehr. Ja, kann ich mir auch gut vorstellen. Das passt sich an und ich war auch schon immer erstaunt, dass Apple ja da schon sehr viel auch früh investiert hat. Also schon die ersten Geräte konnten ja so ein bisschen Assistenzsysteme anbieten und manche Sachen
nutzt man ja auch vielleicht auch einfach normal im Alltag. Also ich habe da manchmal zum Beispiel die Farben ausgestellt, damit es nur schwarz-weiß ist, um nicht so überladen zu werden von den Informationen drauf. Da gibt es ja ganz viele Dinge, die manchmal oder dieser künstliche Homebutton irgendwie da noch mal eingebaut wird oder was auch immer. Das ist auch das, was wir immer wieder versuchen zu erklären, dass die Sachen, die da eingebaut worden sind für Menschen mit Behinderung,
sind für alle anderen auch sehr, sehr nützlich. Es gibt diesen Curb-Cut-Effekt, das beschreibt genau dieses, dass Sachen, die für Menschen mit Behinderungen gebaut worden sind, tatsächlich an der Stelle dann von anderen genutzt werden. Das heißt, wenn ich jetzt auf der Wiese draußen unterwegs bin und die Sonne scheint, dann weiß jeder, wie sehr die Oberfläche von dem Handy spiegelt. Wenn ich dann die Möglichkeit habe, den Kontrast auf schwarz-weiß oder
auf einen hohen Kontrast zu stellen, habe ich eine Chance, noch was zu erkennen. Wenn dann rosa auf grün ist oder ähnliche Dinge, dann sehe ich einfach nichts mehr. Das ist tatsächlich eines der Argumente, die wir auch versuchen, zum Thema Barrierefreiheit immer zu transportieren. Das ist nicht für die Behinderten. Das bietet für sehr viele
andere auch einen sehr großen Vorteil. Das macht man dann auch, aber man nimmt es nicht wahr, dass es tatsächlich mal die Intuition war, dass sollen Menschen mit Behinderungen helfen, mit den Systemen zu arbeiten. Jetzt ist es ja so, ihr habt ja jetzt keine Einschränkung, wenn ihr die Tools nutzt. Das funktioniert alles. Arbeitet ihr denn auch wirklich mit Menschen mit Behinderungen, um das dann auch mal zu validieren? Eure Vorstellung, ob ihr da nichts übersehen habt oder so?
Übersehen ist ein schönes Thema, weil tatsächlich gibt es Elemente, das ist jetzt mal unabhängig von der Browser oder beziehungsweise unabhängig von der Technologie, ob es ein Mobile Device ist oder eine Desktop-Anwendung. Ein Blinder, sage ich immer so gut, der sieht nicht, was er nicht sieht. Wenn also ein Element nicht angesteuert wird, dann kann ein Blinder nicht sagen, das ist falsch, das ist richtig. Wenn er es gar nicht erst angesteuert hat, er sieht
es nicht. Deshalb ist es so, dass wir in der Regel sagen, erst mal wäre der Aufwand zu groß. Du müsstest einen hörgeschädigten, du müsstest einen motorisch eingeschränkten haben. Dann gibt es da noch unterschiedliche Ausprägungen. Ein stark sehbehinderten, einen blinden, du müsstest so viele haben, dass der Testaufwand extrem groß wird. Deshalb machen wir es so, wir testen. Wir maßen uns an, ein relativ gutes Portfolio damit abzudecken.
Aber wenn wir mal ein Problem haben, dann hauen wir uns natürlich selbstverständlich auch mal von Menschen, mit denen wir zusammenarbeiten. Wir haben jetzt einen Blinden bei uns bei einer neuen Entwicklung von einem neuen Designsystem tatsächlich mit eingebunden, dass der von vornherein gleich mit drauf guckt, damit die Fehler gleich von vornherein mit ausgemärzt werden. Das machen wir schon, dass wir uns da so mal ein bisschen von deren Expertise
einholen. Aber tatsächlich die reinen Testgeschäfte machen wir. Also wir haben heute uns auch zum Beispiel zu unseren Präsentationen Feedback von den blinden Teilnehmern geholt. Wir haben sehr viel Erfahrung bzw. sehr viel Kontakt mit Menschen, die solche Ansprüche. Wenn wir uns nicht sicher sind, dann rufe ich halt Günther an, dann rufe ich vielleicht auch den Stefan mal an, die beide blind sind und mit dem Screenreader eigentlich noch tiefer arbeiten. Aber das, was wir feststellen, ist
meistens schon auf dem oberflächlichen Level. Also Tabellen, Auswertung oder ähnliche Dinge, da wissen wir schon, wie man damit umgeht. Wir haben uns aber das jetzt nicht angelesen, sondern wir haben sehr viel hospitiert, wir haben sehr viel mit Menschen mit Behinderungen
gearbeitet und haben uns auch immer wieder Feedback geholt. Das, was Thorsten gerade angesprochen hat, das war tatsächlich, die Intention war dahinter, wir haben jetzt einen blinden Mitarbeiter, der das Designsystem berät, weil der halt das Fachwissen hat. Der ist selber Softwareentwickler gewesen für einen Screenreader und ist dann zu uns
gekommen. Der hat da das Fachwissen. Was aber noch viel wichtiger ist, die müssen jetzt mit ihm kommunizieren und sind damit jetzt plötzlich in dem Team schon mal gezwungen, wenn sie sich COP, Barrierefreiheit nennen, dann auch tatsächlich barrierefrei zu kommunizieren. Das heißt mal eben ein Screenshot hinschicken ohne Beschreibung oder jedes CC, wo er drin steht, dann behält er sich auch vor zu sagen, das, was ihr da geschickt habt, ist für mich
nicht da oder es ist einfach nicht zugänglich oder ähnliche Dinge. Da haben wir eigentlich so ein bisschen die Hoffnung, dass sich das so einschleicht, tatsächlich diese barrierefreie Kommunikation. Wir lassen unsere Unterlagen von ihm prüfen, wenn wir Präsentationen rausgeben und ähnliche Dinge, um einfach zu sagen, wenn wir schon über das Thema sprechen, dann sollte doch bitte unser Inhalt auch mindestens schon in dem Maße, in dem wir es können, barrierefrei sein.
Wir arbeiten ja auch alle unterschiedlich und tatsächlich ist es so, dass es auch sehr, sehr viele Blinde gibt, die zum Beispiel gar keinen Breil können. Und wir haben zwei Fälle von blinden Menschen, der eine sagt immer zu dem anderen, ich kann es überhaupt nicht verstehen, dass du nur mit dieser Breilzeile arbeitest und er sagt, ja und ich kann nicht verstehen, dass du dir ja die ganze Zeit da die Ohren vollquatschen lässt. Also weil
auch gerade da gibt es eben dementsprechend sehr, sehr große Unterschiede. Und das dann nochmal in einem Test abzugleichen, das wird, wie gesagt, da wird der Testumfang zu, wirklich zu groß. Und das ist nicht zu leisten. Wir sind ja tatsächlich dann ein bisschen naiv und versuchen das tatsächlich so zu machen, wie es die Software hergibt. Die Menschen, die den ganzen Tag mit so einem Screenreader arbeiten, die haben ja auch eine Vorgehensweise, eine eigene, womit sie sich die ganzen Sachen
erarbeitet haben. Es gibt mehrere Modi in diesem Screenreader, wo ich dann auch wirklich nur den Text pro Zeile analysieren lasse, ohne Strukturen und ähnliche Dinge. Das haben die sich ja alles drauf geschafft und die wissen auch, wo die Probleme sind. Die machen
das schon automatisch dann so. Aber das kann ja nicht das Kriterium sein, weil dann müssten ja alle anderen das so machen, wie gesagt, durch ihre Arbeitsweisen sind die da schon sehr eingeschliffen, sind sehr, sehr firm in ihren Dingen, sind aber auch sehr in eine Richtung orientiert. Und das versuchen wir zu kompensieren durch unsere Naivität. Ihr habt ja gesagt, aktuell gibt es mehr Probleme als Lösungen in dem Bereich. Definitiv.
Wenn ihr jetzt so drauf schaut auf jetzt und quasi die nähere Zukunft, was sind denn so die großen Klopper, wo ihr gerade so dran seid, wo ihr sagt, da haben wir noch keinen, das kann man noch nicht greifen oder da braucht man noch eine Lösung dafür, da sind wir gerade dran. Tatsächlich habe ich, also von meiner Seite her, so mehr das Vergangene, weil bei den zukünftigen Entwicklungsprozessen, in denen wir eingebunden sind, haben wir so viel Möglichkeit
von vornherein einzugreifen. Schon allein bei der Technologieentscheidung haben wir die Möglichkeiten, zumindest beraten zu sagen, mit so einer Technologie kommt ihr besser voran, sodass ich persönlich glaube, auf Dauer wird es eher besser. Tatsächlich habe ich immer noch mit den nativen Anwendungen große Probleme, weil ich eben, ich bin ein Freund von Webtechnologie, Webtechnologie grundsätzlich, behaupte ich, kann man schneller
barrierefrei machen als eine native Anwendung. Leider Gottes ist es halt so, dass bei nativen Anwendungen ich natürlich auch auf die Geräte zugreife, was natürlich bei einem tatsächlich interessant sein kann, wenn ich zum Beispiel ein GPS-Signal im Telefon abgreife. Das habe ich tatsächlich bei Webanwendungen nicht so möglich, die Möglichkeit noch nicht. Das
wäre so ein Wunsch von mir. Deshalb, ehrlich gesagt, ich glaube auch in dem, was gerade passiert mit den neuen Verordnungen, mit den Verpflichtungen, denke ich da, ich gucke eher positiv in die Zukunft. Wir wissen natürlich nicht, wie die weitere Entwicklung ist. Ich glaube auch, dass Chat-GPT eine Möglichkeit sein könnte, für Testen noch besser nach vorne zu kommen, gerade bei den mobilen Anwendungen. Aber wie gesagt, ich kann nicht in die Glaskugel
gucken. Aber tatsächlich, meine Trend geht eher dazu, dass ich sage, ich glaube, es wird eher besser als schlechter. Das, was im Moment alle umtreibt, die das Thema wirklich bewegen müssen, sind barrierefreie Dokumente, die Bereitstellung von barrierefreien Dokumenten, barrierefreien Formularen, um von der Papierwelt wegzukommen, die elektronisch zur Verfügung zu stellen. Man hat es dann getan, hat gesagt, ja, dann lege ich es halt auf einen Scanner, ich mache einen PDF und
das PDF stelle ich dann zur Verfügung. Das kann dann jemand ausdrucken und kann dann was reinschreiben und kann es uns zurückschicken oder wir schicken Papier raus und dann filmt man jemanden aus. PDF barrierefrei oder überhaupt non-Web-Dokumente, also alles, was nicht im Browser interpretiert wird, bereitzustellen, erfordert nicht unendlich viel Aufwand, aber
die Anzahl der Dokumente ist eigentlich fast unendlich. Wenn man mal in sein eigenes Unternehmen schaut und schaut, was ist denn tatsächlich an Dokumenten für die Sachbearbeitung zur Verfügung gestellt, Dienstanweisungen, tatsächlich Formulare, wenn es die noch gibt, Text und alles, die müssten einmal barrierefrei aufbereitet werden. Das ist halt die Menge, die im Moment
die Leute etwas hemmt und schockt. Wir arbeiten aber auch da schon daran, das eventuell teilzuautomatisieren, dass man tatsächlich Tools nutzt, die die entsprechenden Informationen dann aufbereiten. Aber wenn es vom Inhalt her nicht gut ist, dann hilft aber auch die Technik nichts. Genau, das ist das, was viele glauben, dass barrierefreie IT ein Thema der reinen Technik
ist. Stimmt nicht. Wenn meine Anwendung vom Designer schlecht aufgebaut ist, dann werde ich mich als Blinder darauf niemals zurechtfinden, wenn die Strukturen einfach technisch nicht so sind, wie sie optisch abgebildet werden, weil jemand wieder mit irgendwelchen Layout-Tabellen oder ähnlichen Dingen gearbeitet hat oder glaubt, er müsste sich da verwirklichen.
Die Struktur der ganzen Sachen hat so viel Relevanz und das muss man tatsächlich nicht beim Entwickler einsetzen, sondern beim Designer und bei Texten oder bei Dokumenten dann beim Ersteller der jeweiligen Dokumente. Die können jetzt nicht sagen, ich habe hier was geschrieben, geh mal bitte und jetzt mach mal barrierefrei. So war früher die Vorstellung und wir sagen natürlich nicht. Das geht einfach nicht, weil wir können bestimmte Sachen nicht entscheiden.
Mein Lieblingsbeispiel ist, ich kann in so einem PDF Sachen kennzeichnen als Artefakt, dann werden die nicht vom Screenreader interpretiert. So ein Dot-Matrix-Code unten in der Ecke. Was soll der Screenreader da vorlesen? Also geht man hin und versucht, das dann auszublenden. Technisch kann ich jedes Dokument, was ich bekomme, jedes PDF sofort technisch barrierefrei machen. Ich kennzeichne alles als Artefakt, stelle raus, das sagt der Prüftool, das ist
okay, alles schön. Das steht noch nichts mehr drin für den Blinden. Und das versuchen wir auch so ein bisschen in die Köpfe reinzukriegen. Das ist nichts, das, was die IT da unten machen kann. Das müssen alle mitdenken von ganz oben runter bei der Programmgestaltung, beim Einräumen von Zeiten und Ressourcen bereitstellen, um dieses Thema zu bewegen. Da sind wir bei uns eigentlich auf einem guten Weg. Wir haben da viel Rückhalt aus der oberen Etage. Ja, und das kriegt ja auch, wie ihr am Anfang
gesagt habt, jetzt mehr Awareness, weil es jetzt auch notwendig ist. Die nächsten Jahre bringen einfach die Regulatoren, dass da jetzt auch mehr passieren muss. Das bringt mehr für den freien Markt. Wir in der Rentenversicherung als Träger der Öffentlichen Hand müssen das sowieso schon tun. Wir haben den gesetzlichen Druck schon.
Aber nur die Firmen, die fangen jetzt an, wenn sie einen Webshop aufsetzen wollen und sie wollen den in Europa etablieren und wollen keine Strafen von der Marktaufsichtbehörde bekommen, dann müssen sie jetzt anfangen, das mal langsam umzusetzen. Weil sonst wird es teuer. Ja, sehr schön. Thorsten, Dirk, vielen Dank für das Gespräch, für das Interview. Es hat mir viel Spaß gemacht. Ich habe wieder
ein paar neue Einsichten auch gewonnen. Das ist ein ganz spannendes Thema, wo ich selber wenig Einblick hatte und wieder was gelernt und gleich überlegt, ob ich jetzt mal bei meinem iPhone, bei meinem iPad mal schaue, was es da eigentlich so alles noch gibt. Ich bin in diesem Menü so selten drinnen, weil ich es ja auch eher natürlich nicht brauche, aber da mal ein bisschen auch reinzuforschen. Danke euch für diese Insights. Wenn wir dich neugierig gemacht haben, sehr, sehr gerne.
Ja, genau. Also vielen Dank für die Einladung. Genau, ich danke auch für die Einladung und vor allen Dingen, alles ist gut, um das Thema nach vorne zu bringen. Auf jeden Fall. Deshalb können wir uns auch nur bedanken, dass wir hier die Möglichkeit haben, das auch mal so ein bisschen kundzutun. Auf jeden Fall. Sehr schön. Dann noch schönen Nachmittag, schönen Abend, gute Heimreise. Danke schön. Danke schön. Noch viele weitere spannende Interviews für dich. [Musik]