Hallo und herzlich willkommen zu einer neuen Folge vom Podcast Software Testing. Ich bin euer Host Ritschi und habe heute im Gepäck wieder eine Folge vom German Testing Day 2024 in Frankfurt. Bei mir geradezu Gast René Matthei und Serdal Bilir, die sich um das Thema Barrierefreiheit kümmern. Das Besondere, Serdal ist selbst Betroffener, welche Herausforderungen er beim Testen hat, durch seine eingeschränkte Sehfähigkeit, wie er damit umgeht und wie er Entwicklern hilft,
bessere Software zu schreiben. Das erzählt er uns heute in der Podcast Folge. Viel Spaß beim Hören. Hallo Serdal, hallo René, schön, dass ihr da seid. Hallo Richard. Ja, wir sind ja hier am German Testing Day 2024 in Frankfurt. Tag zwei, also der große Tag beginnt heute. Gestern war so der Anlauf genommen, das Abendprogramm und heute starten wir hier in den neuen Tag hinein. Seit heute die erste Podcastaufnahme und ja, freue mich sehr auf das Thema. Ganz spontan reingerutscht, gar nicht
geplant gewesen ursprünglich, finde ich aber umso schöner. Und zwar geht es ja um Barrierefreiheit im weitesten Sinne. Genau, wir haben heute ja auch einen eigenen Slot, von daher ist der Tag für uns auch der entscheidende. Bist du schon aufgeregt, Serdal? Geht, aktuell noch nicht so richtig, aber schauen wir mal, wenn es soweit ist, wird es bestimmt schon, ja, die Aufregung wird ja bestimmt noch kommen. Ja, jetzt müssen wir natürlich dazu sagen, gerade für die Hörer,
Serdal ist ja in einer ganz besonderen Rolle hier. Genau, ich bin selber Betroffener, ich bin selber blind, also gesetzlich blind, habe noch einen ganz ganz kleinen Sehriss tatsächlich, kann noch Umrisse erkennen und hell und dunkel, aber bin gesetzlich blind, ja. Ja, und deine Aufgabe ist, also du testest oder was machst du Anforderungen für, was ist so dein Job in den Projekten, wo du bist? Also ich bin Barrierefreiheitstester und Berater, also Accessibility Expert
und Consultant. Ich berate die Entwicklung hingehend, wie die Barrierefreiheit hergestellt werden kann, was besser gemacht werden muss, um das zu erreichen, welche Fehler entstanden sind in der Umsetzung und genau. Das ist natürlich ganz spannend, denke ich, wenn du mit Entwicklern redest, weil die müssen sich ja reinversetzen in eine Bindung, eine Sehschwäche oder sonst was und du bringst die mit und gibst quasi dein Feedback. Ist das manchmal so, dass du dir denkst,
ja, das ist doch total klar, dass das nicht funktionieren kann so? Ja, also es gibt natürlich Fälle, wie du gerade gesagt hast, die Entwickler müssen sie erstmal reinfühlen, wenn sie damit keine Berührungspunkte hatten. Da mache ich das natürlich immer so, ich lade die in mein Büro ein, wo ich mein ganzes Equipment stehen habe, also die Braillezeile, wo ich mit den Fingern lesen kann. Ich habe nämlich eine Hardware, wo die Braille-Schrift entwickelt wird, also was du im Bildschirm sehen
kannst, kann ich mit den Fingern lesen. Erstens mal das stelle ich vor und zusätzlich schalte ich in meinem Screenreader den Sprach- und Braille-Betrachter an, das ist so ein Onboard-Mittel. Da kannst du als Sehender in der Leiste sehen, was ich ins Ohr bekomme und in den Fingern habe. So können die das dann eher nachvollziehen und kriegen ein besseres Gefühl dafür. Wenn es gar nicht geht, dass sie zu mir vorbeikommen können, dann teile ich meinen Sound in einem Online-Meeting, dann
hören sie auch den Screenreader. Dann sagen sie "Ah, okay, jetzt verstehe ich das Problem". Das Ganze geht auch nicht nur mit der kostenpflichtigen Software, die wir da verwenden, JAWS, sondern das geht auch mit NVDA. Also wer das selber mal ausprobieren möchte, das ist ein Open-Source-Programm, das auch offiziell genutzt werden kann für Screenreadertests. NVDA steht für Non-Visual Desktop Access und das kann man sich runterladen und mal probieren.
Ja, ja. Was sind denn gerade so die größten Herausforderungen bei euch in den Projekten? Ja, zwei Dinge. Das eine ist, frühzeitig eingebunden werden und irgendwie, sag ich mal, einen Arbeitsmodus vereinbaren, wie man sich dann auch wieder trifft. Nicht erst am Ende des Projekts. Und das zweite ist die Grundkenntnisse, das Verständnis, von dem du gesprochen hast. Welche Testschritte führen wir durch, welche Tools verwenden wir dafür und was heißt das konkret für
HTML-Code, wie muss der beschaffen sein. Da sind natürlich schon die ein oder andere Ahnung ist da schon vorhanden, aber wenn man dann durch die Applikation geht, tauchen doch dann etliche AHA-Erlebnisse auf. Ja und vor allem ist es immer, also die Herausforderung ist immer die, wir haben einen eigenen Style-Guide, ein eigenes Repository, wo eigentlich die Components dabei sind. Also sprich, ja, Eingabefelder, Tabellen, Buttons und so weiter, wo das unser Style-Guide-Team schon alles
entwickelt und definiert hat und dann wird es verwendet in der Entwicklung. Und dann ist ja auch die Erwartung der Projektleiter oder der Entwickler, es muss barrierefrei sein, weil die Komponente barrierefrei kommen. Ja, mag vielleicht sich in der Theorie so anhören, aber ist in der Praxis nicht so, weil wenn das nicht eins zu eins so umgesetzt wird oder halt die Zusammenkunft von mehreren
Komponenten kann dann wiederum die Barrierefreiheit stören. Wir haben ganz groß das Thema Wiederverwendung. Wir führen, wenn du so willst, die gleichen Gespräche immer wieder und immer wieder auf allen Ebenen, auf einer technischen Ebene, aber auch auf einer UI-Design-Ebene zum Thema Barrierefreiheit. Und da wünscht man sich schon, und das kriegen wir auch manchmal gespiegelt von den Projektleitern, dass da wiederverwendet wird, dass Austausch stattfindet. Wir stellen dann Fragen
und sagen, wir haben das in andere gemacht. Dann müssen wir schmunzeln und sagen, ja, in dem Fall weiß ich zufällig, wie es andere gemacht haben, an ein, zwei Beispielen, aber die Frage ist eigentlich falsch adressiert. Das ist eine Frage des UI-Designs und ich weiß es nur zufällig. Es ist spannend und auch immer herausfordernd tatsächlich. Wie ist denn das bei euch in den Projekten? Also es ist ja quasi verpflichtend, in eurem Umfeld
ja eh schon auch länger, glaube ich, Barrierefreiheit. Jetzt kommt das für normale Unternehmen ja auch ab nächstem Jahr ganz stark das Thema. Wie ist denn das bei euch so über die Jahre gekommen, wird das aktiv jetzt auch angenommen? Also wollen die Projekte das oder ist das so ein bisschen notwendiges Übel? Sie müssen das. Ja, ja, genau. Also müssen, wollen, müssen. Wir haben eine Projektcheckliste und da steht die Barrierefreiheit mit drin, dass wir von Anfang an mit einbezogen werden sollen.
Nicht immer passiert das. Es kommt meistens dann zum Go-Live, ja, wie die Barrierefreiheit bei uns abgenommen werden. Eins muss ich sagen, ich bin auch selber in der Schwerinvertretung aktiv, in den Gremien und verantworte da, also ich bin stellvertretendes Mitglied in der Schwerinvertretung und verantworte da auch die Barrierefreiheit und habe das dann auch aus der Gremiensicht im Blick und da, also ich merke jetzt, dass seitdem ich da aktiv bin, dass da, also ist mein Bauchgefühl,
dass da jetzt mehr Augenmerk drauf gelegt wird. Also wir wollen ja eigentlich gar nicht diese gesetzliche Keule rausholen, die Gremien beteiligen, aber tatsächlich ist das, soll ich sagen, eine der Säulen unserer Strategie, die hilft auch, leider. Das ist sehr unmodern, sehr retro eigentlich, aber die, ja. Also was ich noch sagen kann, weil du gefragt hast, wie es so von der Vergangenheit und bis heute lief, also wir haben eine Desktop-Anwendung, eine lokale Desktop-Anwendung,
die unser Hauptgeschäft im Amt abbildet. Die läuft schon seit knapp über 20 Jahre und wurde halt immer bei Windows-Wechsel, also von 2000 auf 7 und so immer mit hochgezogen und die Anwendung ist halt von Grund an nicht barrierefrei, also man kann gar nicht mal mit der Tastatur navigieren. Da haben wir das so gemacht, dass wir, also man kann unseren Screenreader JAWS auf eine bestimmte
Anwendung adaptieren. Also man da schreibt da Skripte und legt ihm, dem Screenreader, eine Schablone drauf, also eine Schablone kannst du dir vorstellen auf die Anwendung und sagen, hier liegt dieser, dieser Button auf dem und mit dem Pixel. Und so machen wir dann wiederum nicht barrierefreie Anwendungen, also nutzbar. Das muss natürlich dann auch immer in der Größe sein oder in Fenstergröße oder Vollbild oder so was und Auflösung, das ist natürlich,
das ist. Da rufen mich dann die Kollegen, die betroffenen Kollegen an, ja das funktioniert nicht mehr. Hast du denn dann mal deine Bildschirm maximiert? Oh ja, warte mal, ja dann, jetzt geht es wieder, weil da dann die Pixel natürlich nicht passen oder wenn man die Pixelangabe nicht machen kann, dann sagt man dem Screenreader, suche mal den blauen schattierten
Button mit dem und dem Inhalt. Also die Screenreader bieten dir so viele Möglichkeiten, dass du das halt auch machen kannst, dass du etwas nutzen kannst, was sehr alt ist und das nicht hergibt. Wie machst du das mit den Tests, also wie fängst du denn eigentlich so an, wenn du da, ich kann mir das total schwer vorstellen, wie näherst du dich zu dem? Ich demonstriere das gerne, heute mal zum Start, wenn du vorbeikommst. Aber ich leite eine andere Aufnahme, würde ich gerne sehen.
Also ich begleite auch die Entwicklung, also ich mache ja die Entwicklungsbegleitendentests mit und bei jedem Sprint werde ich kontaktiert und ich habe das tatsächlich über die ganzen Jahre oder auch weil ich selber ja betroffen bin, weiß ich ja, was ich möchte und was ich brauche. Bei den Entwicklungsbegleitendentests nehme ich gar nicht mehr die BTV-Testfälle, sondern ich gehe sie halt nach dem Bauchgefühl oder auch nach bestem Gewissen durch und decke
da somit auch alles ab eigentlich. Ich habe, wie gesagt, in meinem Screenreader Onboardmittel, wo ich die HTML-Schnittstelle abrufen kann, wenn ich zum Beispiel einen Button habe, wo er mir sagt "Schalter" und nicht den Inhalt des Schalters vorliest, fokussiere ich den, mache eine Tastenkombination, einfüge Shift+F1, das ist eine Tastenkombination von dem Screenreader und habe dann die HTML-Schnittstelle,
was er sich gerade abgreift. Und da kann ich dann die Role, den Tag sehen und ob auch das gelabelt ist oder nicht. Dann sage ich "Hey, schau mal, hier fällt das Tag Label". "Ah, ok, das machen wir nach." Also ich muss gar nicht in die Developer Tools gehen und mir den ganzen Quellcode anschauen, ich kann direkt das Element untersuchen. Und wie reportest du diese Dinge? Ist jetzt dann quasi schon ein Entwickler mit dabei und arbeitet mit dir zusammen?
Für 90 Prozent ja. Das hat auch lange gedauert, bis wir die Leute überzeugen konnten, dass ein Entwickler mit dabei sein muss, weil nur er kann ja verstehen, was ich technisch brauche. Er ist mit dabei, notiert er sich das für sich oder ich notiere das und schicke es ihm dann zu. Ich habe es ja vorhin schon gesagt, am liebsten hätten wir auch jemanden, der kompetent im UI-Design ist.
Ich habe das gerade letzt in einem Projekt erlebt, wo im Prinzip sehr hart und sehr fokussiert mit uns zusammengearbeitet wurde. Und dann hat aber der andere Tester in mir, der nicht nur die Szenen-Testschritte macht, mitbekommen, dass da Dinge verschlimmbessert wurden, die aber gar nicht im Fokus standen und deswegen überhaupt noch aufgefallen sind.
Und da habe ich dann gemerkt, es ist halt nicht nur eine Sache von Tester oder Entwickler, sondern du brauchst auch jemanden, der sich überlegt, so wie ein Business-Analyst UI-Design, das ist ja quasi eine Business-Analyse für Frontends, wie soll das jetzt sein und wie ist es an anderen Stellen der Anwendung? Weil das lief dann auf einmal auseinander und ich habe dann gemerkt, okay, dieser direkte Kontakt ist super, aber eigentlich brauchen wir noch jemanden drin.
Was der René gerade gesagt hat, also zum Beispiel UI-Design ist natürlich sehr, sehr, sehr wichtig. Auch, welche Komponente verwende ich für was? Also wir hatten letztens eine Anwendung, das ist so ein Abfrageformular für eine Schnittstelle, da hat die Entwicklung Registerkarten für Sprungmarken benutzt. Und eine Registerkarte sagt das ja aus, du wechselst den Inhalt eigentlich. Und wenn ich als Screenreader-User eine Registerkarte höre oder gleich sehe, erwarte ich, dass der Inhalt sich ändert.
Aber obwohl das eigentlich ein Skip-Link wäre, der bloß als Registerkarte ausgegeben wurde im HTML. Das ist sehr wichtig, man muss halt semantische Elemente verwenden, was das tun soll, nicht Fake-Elemente. Das ist spannend, also wenn man es jetzt mal generalisiert auf Human-Machine-Interfaces sozusagen, dann ist die selbstauszeichnende Deklaration der Bedienelemente eigentlich das A und O, was uns auch in der Testautomatisierung und generell in jeglicher Automatisierung dann helfen würde.
Wenn die Elemente sich zu erkennen geben, was bin ich, was kann ich, was habe ich für Bedienstchnittstellen, damit können dann alle arbeiten und das ist auch, ich glaube, sowas ist auch ein Gespräch für zukünftige Versionen von der WCAG und anderen Themen, das quasi einzufordern, dass Bedienelemente sich zu erkennen geben. Also weil wir vorhin von Pixeln gesprochen haben und es war mir gar nicht so bewusst, dass wir da über Pixelauflösung und Grafik vorgehen bei den JavaScripten.
Ich war der Meinung, weil es ja .NET 5 basiert ist, dass wir da ein bisschen besser rangehen können, aber tatsächlich gehen wir... Nein, wir greifen tatsächlich die Grafikkartentreiber ab. Ja, ja, Wahnsinn. Wir greifen wirklich die Grafikkartentreiber ab, was die Grafikkarte uns gerade liefert. Es ist spannend, weil ich merke so jetzt auch im Gespräch, da ist ja echt eine große Parallele auch zu der Entwicklung der Testautomatisierung.
Also da haben wir ja auch früher ganz viel auf Koordinaten gearbeitet, dann gab es irgendwann mal die ersten Objekterkennung und diese ganzen Sachen und das geht ja hier Hand in Hand auch mit den Dingen, also die Anforderungen sind die gleichen. Das heißt, wenn ich in Barrierefreiheit auch investiere, das besser mache, dann habe ich auch die Chance, bessere Testautomatisierung zu machen und umgekehrt. Das ist ja mein Lieblingsthema, dieses Thema in Barrierefreiheit investieren.
Im Prinzip korreliert eine gute Architektur, eine gute Umsetzung und eine gute Barrierefreiheit ganz stark. Das fing vor vielen Jahren an mit dem Thema Trennung von Inhalt und Form, CSS, HTML und das zieht sich aber durch. In dem Moment, wo du gut entwickelst, gute Pattern verwendest, hast du eine sehr gute Chance, dass du schon barrierefrei bist.
Umgekehrt, wenn eine Anwendung extrem schlecht barrierefrei ist, dann ist das definitiv ein Indikator dafür, wie halt in der Frontendentwicklung vorgegangen wurde. Auch die Gruppierung von Elementen, also die nicht sichtbare Strukturierung der Oberfläche ist ja ein ganz starkes Architekturmuster oder ein Architekturbestandteil. Davon profitieren oder leiden halt die Leute, die das als plain in Content bekommen und da gar nicht mit umgehen können, wenn das einfach nur so abgebildet wird.
Was ich immer sage, ist, Testautomatisierung ist schön. Die Entwickler oder auch die Tester können sich dann testen, aber das löst trotzdem keinen manuellen Test, vor allem auch durch uns. Weil die Testautomatisierung kann gucken, ob die Role von dem Ding gesetzt ist und so. Das macht es, ja, aber ist das denn immer logisch? Und wie ich gerade gesagt habe, die Registerkarte, ist die überhaupt logisch für diesen Zweck? Das kann ich als Testautomatisierung natürlich dir nicht sagen.
Wenn du dich jetzt so beschäftigst mit den Systemen, also wenn du so mal global drauf schaust, wo funktioniert es denn besser, in den Web-Anwendungen oder so bei diesen Desktop-Anwendungen? Wo ist denn der Zugang einfacher? Definitiv bei den Web-Anwendungen. Also Desktop-Anwendungen sind immer sehr, sehr schwierig, auch sogar bei Office. Outlook haben wir tatsächlich auch Skripte eingekauft, damit wir den Kalender effektiver und schneller nutzen können.
Also Office ist auch nicht eigentlich barrierefrei, bloß der Screenreader-Lieferant oder der Hersteller schreibt eigenste Skripte, Adaptationen, damit Office funktioniert. Und das liefert damit, das merkst du als User gar nicht, ja, das kann ich ja nutzen, aber da läuft ein Skript dahinter. Damit ist es aber funktioniert. Das würde doch etliche Podcasts füllen.
Die eine Frage geht in die Richtung, wenn wir täglich zusammenarbeiten, du merkst das in meinem Referat, wo ich auch mehrere Kollegen habe, die eingeschränkt sind, nutzen wir jetzt da die gut funktionierenden Office-Produkte oder das schlecht funktionierende Confluence? Ja. Also das ist echt eine spannende Frage. Wie arbeiten wir optimal zusammen und bezieht sowas ein? Und die andere Frage geht in die Richtung, in der Internetwelt gibt es gerade eine Diskussion zum Overlay.
Im Endeffekt meint man damit, dass man davor geschaltete Assistenzfunktionen hat, die dann etwas Existierendes besser benutzbar machen, so wie auch ein Screenreader im Endeffekt. Eigentlich musst du parallel vorgehen. Du musst auf der einen Seite schauen, dass es wirklich funktioniert, nutzungsorientiert und dann musst du aber auch, shift left, schauen, dass die Web-Anwendung an sich schon viel mitbringt.
Dann hat a) der Screenreader nicht mehr so Probleme, b) hat nicht jeder auf der Welt immer einen Screenreader parat. Es gibt auch Leute, die sich das vielleicht nicht leisten können. Genau, ja. Sehr spannend. Wenn du so generell unterwegs bist am Rechner, im Internet surfst oder sowas, kommst du denn da gut durch? Also haben die meisten Seiten, wenn du jetzt abseits von euren Projekten im Internet surfst, klappt das gut? Im Alltag. Im Alltag? Ist das gut? Eckst du dann jede Stunde mal an?
Nicht immer natürlich, aber in den meisten Fällen schon. Aber es gibt auch viele Fälle, wo es dann natürlich nicht klappt. Gestern Abend hatten wir es zum Beispiel mit einem Herrn hier, Elster. Wenn ich meine Steuererklärung über Elster machen möchte, benutze ich gar nicht tatsächlich. Ich benutze was anderes. Ja, also man muss auch viel improvisieren, auch viel versuchen, was anders zu machen und sich wissen, wie man sich selber hilft.
Es gibt manchmal auf Webseiten, egal wo, manchmal Buttons, die du mit Enter oder mit dem Space nicht auslösen kannst. Was mache ich da? Ich versuche halt, das umzugehen, aber wenn es gar nicht geht, kann ich dem Screenreader sagen, ziehe mal die Maus zu dem Tastaturfokus hin. Dann zieht er wirklich die Maus, die du siehst, kommt dann auf den Punkt, wo der Tastaturfokus gerade steht und dann kann ich einen Mausklick simulieren und kann dann den Button auslösen.
Das kannst du natürlich nur machen, wenn du das weißt, wie es geht. Wie ist denn das zum Beispiel jetzt bei einer Plattform wie LinkedIn? Wir haben uns ja gestern über LinkedIn connectet. Das ist ja Social Media, das ist ja auch für einen normalen Anwender schon overwhelming, was da so alles möglich ist und sowas. Kannst du dich da gut bewegen? Also ich benutze es ja hauptsächlich auf dem iPhone.
Tatsächlich muss ich ehrlich zugeben, ich habe es am PC, auf dem Browser noch nicht versucht, aber am iPhone klappt das super. Zum Beispiel Facebook war damals, also Facebook ist auch bedienbar. Es gibt manchmal Updates, dann kannst du nichts mehr liken, weil es geht einfach nicht. War auch schon nicht schlimm. Und damit es wieder was verbessert. Also es ist immer so ein Auf und Ab tatsächlich. Ja, verstehe.
Wenn ihr jetzt so schaut in den nächsten Jahre, Monate, was sind denn so die Sachen, wo ihr sagt, das muss im Projektgeschäft bei euch noch besser werden, noch flüssiger, das sind Herausforderungen, die ihr noch knacken müsst? Also ja, vielleicht sage ich etwas dazu und dann kann René noch etwas ergänzen. Also die Wiederverwendbarkeit hat ja René vorhin schon erwähnt. Das ist sehr wichtig.
Einheitliches Look and Feel ist sehr wichtig, weil jeder baut die Anwendung anders oder Anwendungen anders vom Aufbau her. Und ja, die Wiederverwendbarkeit tatsächlich. Was meinst du noch? Naja, was du schon erwähnt hast, die Beratungstätigkeit, die Zusammenarbeit mit uns, damit man den TÜV am Ende sozusagen gar nicht mehr fürchten muss. Das ist und bleibt eine Herausforderung.
Es läuft in letzter Zeit besser, ist sehr arbeitsaufwendig, weil durch eine engere Zusammenarbeit in virtuellen Teams, wo die Projekte mit reingehen, kostet es natürlich Zeit an der Stelle. Dem müssen wir eigentlich begegnen, indem wir mehr Schulungen machen und mehr Self-Service noch anbieten. Wobei man sagen muss, es gibt unglaublich viele und gute Quellen im Internet. Ich habe selten so gut ein Thema präsentiert, dokumentiert und angeboten gesehen wie zum Thema Barrierefreiheit.
Also die Web-Content-Accessibility-Guidelines, die sind für Entwickler sehr prägnant. Muss man nur lesen, man muss eigentlich nur surfen können. Das ist das, was wir wahrscheinlich demnächst tun, dass wir gemeinsam mal surfen. Es ist ja auch ein Thema, bei euch ist es ja schon verpflichtend, seit längerer Zeit, jetzt trifft es ja auch quasi die Wirtschaft, die Unternehmen, die jetzt auch viel machen müssen.
Das kriegt ja gerade auch deutlich mehr Awareness, das merke ich ja auch hier über den Podcast und über die Kanäle. Sehr schön. Vielen lieben Dank für dieses Interview. Das hat mir total Spaß gemacht, dass wir das jetzt so spontan noch gemacht haben. Danke, dass du uns die Gelegenheit gegeben hast, Richard. Auf jeden Fall gerne. Wir können auch den Linktree, den wir für den Slotherd vorbereitet haben, den können wir dir auch noch hinterlassen, dann kannst du den mit reinpacken.
Da sind die wichtigsten Informationen gesammelt. Perfekt, das ist schön, das packen wir mit rein. Ich wünsche euch noch einen schönen Konferenztag. Vielen Dank. Und ganz viel Spaß heute noch. Bis zum nächsten Mal. Bis zum nächsten Mal. Tschüss. [Musik]