Udo: 0:09

Herzlich willkommen zu Coffee Code Consult, dem Finanztech-Podcast der Cofin Pro. Bei mir sind heute Viktoria Hendrik wir

Speaker: 0:20

wir wollen uns heute im Groben darüber unterhalten, Wie man die Auflagen, die man aufgrund des Barrierefreiheitsstärkungsgesetzes bei manchen Projekten hat, besten in einem Projekt verankert. Und damit würde ich erstmal den Auftakt machen und euch bitten, euch ganz kurz vorzustellen habt ihr für eine Funktion und was macht ihr in der Kufenprobe.

Victoria: 0:42

Genau, ich bin jetzt seit über zweieinhalb Jahren, fast drei Jahren bei CoFinPro Und bin da als Product Designerin tätig und das heißt Standardisierung von Komponenten mit in Projekte bringen und die Nutzererfahrung in Produkten verbessern Und jetzt kürzlich haben wir uns sehr stark darin spezialisiert, dass wir Nutzererfahrung priorisieren, sodass wir Nutzer wirklich befragen und die Nutzererfahrung einfach sehr viel stärker fokussieren, dass das wirklich im Endprodukt etwas ist, was Nutzer gerne verwenden wollen. Und das machen wir eben in Form von Usability-Tests, sodass wir Endkunden oder je nachdem, für wen dann das Produkt ausgerichtet ist, einladen und über Hypothesen validieren. Genau, das sind so meine aktuellen Tätigkeiten.

Udo: 1:40

Vielen Dank.

Hendrik: 1:42

Ja, dann stelle ich mich mal vor. Ich bin Hendrik und ja, ich bin seit... Jetzt über zehn Jahren in der Softwareentwicklung tätig und habe eigentlich immer so einen Frontend-Schwerpunkt gehabt in irgendeiner Form, auch damals im Studium schon. Und ja, in der Rolle bin ich meistens also derzeit als Architekt unterwegs und das heißt, wenn ich nicht gerade im Elfenbeinturm unterwegs bin, Dann komme ich auch mal ganz viel mit Entwicklern ins Gespräch und auch mit Business-Analysten, mit Product-Designern Designerinnen, wie Viktoria eben eine ist. Und dann merkt man einfach, dass dieses ganze Thema Barrierefreiheit kein so einfaches ist. Also wir haben ganz viel Technik dahinter, aber wir haben eben auch ganz viel Was eben gar nichts mit technologie zu tun hat sondern einfach zum beispiel dieses thema auf dem schirm behalten konstant und ja dieses thema einfach irgendwo nicht nur in einem projekt was er irgendwo abgeschlossenen lebenszyklus eigentlich hat sondern vielleicht auch in der kompletten firma zu verankern so dass es einfach konstant teil des Des bewusstseins ist und einfach konstant weiterentwickelt wird jetzt nicht nur einfach mal die software ich sag mal in den zustand gebracht wird dass es die das ist das bfsg überlebt

Udo: 2:57

sehr schön das ist das bfsg überlebt es dann wirklich eine schöne formulierung und es geht ja auch darum dass es eben bedürfnisse gibt die eben nicht mehr in stream sind und Die man eben gar nicht so ohne weiteres überhaupt erkennen kann also die ganz normalen bedürfnisse der normalen benutzer sage ich jetzt mal die sind leicht zu erfassen die kann man auch relativ schnell abbilden aber bedürfnisse die eben andere benutzer haben die irgendwelche einschränkungen haben oder besonderheiten Genau, und ja, damit wären wir eigentlich schon auch an dem Punkt, warum ist Barrierefreiheit wichtig? Also wieso gibt es überhaupt das BFSG und was hat die Gesetzgeber dazu veranlasst, das jetzt irgendwie auch per Gesetz im Prinzip vorzuschreiben?

Victoria: 3:47

Vielleicht noch ganz kurz ergänzend zu dem, was du eben gesagt hast. Ich finde, das ist immer, also ja, es ist jetzt ein Standard und jetzt kommt es quasi rechtlich mit in Betracht aber grundsätzlich erleichtert es uns allen ja die Anwendungen Also Kontraststärke und die Schriften auszubessern zu verbessern das ist nicht nur für eingeschränkte Personen wichtig, sondern auch Für uns alle macht es das leichter, die Plattform zu verwenden und gute Usability, ja, zu verbessern.

Udo: 4:22

Ja, das ist ein ganz wichtiger Punkt, weil die Informationsdichte wird ja nicht geringer Und je dichter die Informationen auf einen einprasseln, desto wichtiger ist es, dass man den Fokus behalten kann. Und das kann man natürlich mit einer gut strukturierten Anwendung die einem da hilft, irgendwie auch wirklich besser.

Victoria: 4:40

Auf jeden Fall.

Hendrik: 4:43

Aber wenn es jetzt um dieses Gesetz geht, also ich stelle mir das immer so, also für mich ist dann immer die, also eine Softwareanwendung ist dann, wenn es jetzt die Barrierefreiheit angeht dann denke ich immer an das tägliche Leben. Also wenn ich jetzt, nehmen wir mal Treppen, also wenn ich jetzt als normaler Nutzer unterwegs bin, als normaler nicht gehbehinderter Mensch, Durch die Gegend lauft, dann sind Treppen nicht ganz so schlimm. Also die sind da, die behindern mich in dem Sinne, dass mir vielleicht die Oberschenkel wehtun, wenn ich dort irgendwie mal 100 Stück davon laufen muss. Aber ich kann das alles machen, kann das alles ausgleichen weil ich eben Beine habe. Und wenn ich jetzt aber mit einem Rollstuhl unterwegs bin, dann habe ich da Ein ziemliches Problem, wenn ich keine Rampe daneben habe. Und so ist es einfach jetzt in die Softwarewelt übertragen eben auch. Also Kontraststärke ist, also wenn jetzt die Kontraststärke oder die Schwäche in dem Fall die Treppe ist, dann kriege ich das als normaler Normalsehender gut ausgeglichen aber wenn ich eben nicht so gut sehen kann, dann sehe ich am Ende Vielleicht gar nichts mehr und dann, weil ich eben diese Kontrastschwäche nicht ausgleichen kann oder Rot-Grün oder andere Sehschwächen und deswegen, also ich finde es super, dass es jetzt ein Gesetz gibt, was uns im Prinzip dazu zwingt jetzt auch das, ja ich glaube 10% oder 5%, ich weiß gar nicht, habt ihr Zahlen dazu, wie viele? Beeinträchtigte Nutzer in der, ja, was ist das

Udo: 6:10

Ich habe tatsächlich die Zahl 11% im Kopf, ehrlicherweise. Ich habe das nachgelesen und das war auch im Prinzip das Hauptargument warum sollten Unternehmen sowas verfolgen, weil sie sich eben irgendwie eine doch signifikante Anzahl der Benutzer irgendwie einfach ausschließen, wenn sie es nicht tun.

Hendrik: 6:27

Genau, also ist auch aus monetären Gesichtspunkten auch eine interessante Sache und ja, jetzt werden wir dazu gezwungen, das zu tun und jetzt müssen wir irgendwie damit klarkommen.

Udo: 6:40

Genau, und genauso ist es eben, und da hat ja die Barrierefreiheit ganz viele Aspekte die Fähigkeit einer Anwendung ich ärgere mich jedes Mal selber auch drüber beispielsweise in der App oder auf dem Telefon wo man sowieso nicht viel Platz hat, um irgendwas zu sehen, Wenn man die Schrift nicht größer machen kann. Also für mich ist das nur ärgerlich Für manche Leute ist das halt dann einfach das K.O.-Kriterium Die können es dann nicht lesen weil es zu klein ist. Und das sind halt eben diese Aspekte. So, aber wir wollen... Nicht nur heute über Technik sprechen, sondern wir wollen auch darüber sprechen, warum es eben auch ein organisatorischer Wandel ist oder ein, nein, andersrum muss ich anfangen, einen organisatorischen Wandel erfordert damit man die Barrierefreiheit in seinen Projekten wirklich auch verankern kann. Und ja, da wollte ich euch fragen, wie hat das bei euch angefangen im Projekt? Also wie seid ihr da rangegangen?

Hendrik: 7:33

Ja, vom Rangehen im Sinne von, wir haben jetzt das Barrierefreiheitsstärkungsgesetz und wir müssen jetzt gucken, dass unsere Software barrierefrei ist. Ist natürlich so der Zustand wenn man jetzt mal so eine Skala von 1 bis 10 oder so, dann ist die Software vielleicht jetzt auf einer 3 oder so. Da muss man sich natürlich, muss man schauen, okay, was für Regelungen treffen überhaupt für meine Anwendung zu? Gibt da ja auch verschiedene Gütegrate der Barrierefreiheit und dann kann man das erstmal in, also vielleicht jetzt nicht auf einer Skala von 1 bis 10, aber man wertet die in irgendeiner Weise ein und schaut, okay was fehlt mir denn? Bis ich barrierefrei genug bin für die Nutzer, die in der Form relevant sind. Und dieses Delta, was ich dann habe, das muss ich natürlich erstmal schließen. Also das war so der erste Schritt, zumindest in den Projekten die ich bisher so begleitet habe. Und hört sich für mich auch tatsächlich als ein sehr logischer erster Schritt an, erstmal so dieses sich mit dem Delta zu befassen, das fehlt mir denn eigentlich noch. Und danach oder währenddessen sollte man sich natürlich auch überlegen also die zeit steht ja nicht still also gerade in unseren mittlerweile sehr agilen projekten das ist ja so dass wir konstant wert generieren konstant neue features liefern und das ist nicht so dass wir dass dieses delta gleich bleibt Dieses Delta, das verändert sich, es kommt ein neues Feature hinzu, dann habe ich wieder neue Barrierefreiheitsthemen und das bedeutet, ich muss in irgendeiner Form Dinge etablieren die dazu führen, dass mir diese Barrierefreiheit nicht wieder entgleitet und ja, da gibt es verschiedene Möglichkeiten. Was wir damals gemacht haben, ist erstmal sowas wie eine Taskforce ins Leben gerufen. Also gerade um dieses Thema Barrierefreiheit in irgendeiner Form erstmal auszuarbeiten, was trifft auf uns zu und überhaupt eine gewisse sich erstmal einen Überblick zu verschaffen und diese Taskforce, die gibt es tatsächlich auch immer noch und die hat, also da geht es dann, am Anfang geht es Okay, was trifft auf mich zu, wie kann ich das vielleicht technisch in irgendeiner Form abbilden aber wie kann ich auch gerade so das Thema Testing, also wie mache ich denn Qualitätssicherung, also verschiedene Teilbereiche und Die beschäftigt sich dann auch mit den Prozessen bei uns.

Udo: 10:03

Und wenn man jetzt eine Anwendung hat, die schon besteht, die schon am Markt erfolgreich ist und aktiv genutzt wird, dann stelle ich mir vor, gibt es irgendwie einen breiten Fächer von DeltaHata und jetzt muss ich das ja irgendwie auch priorisieren. Also ich muss ja sagen, okay, das ist jetzt irgendwie sozusagen ein besonders schwerwiegendes Delta, das müssen wir auch irgendwann mal machen, aber ist nicht ganz so wichtig. Wie habt ihr das strukturiert Also ich meine, womit habt ihr dann angefangen Und jetzt gerade im Hinblick auf Produktdesign stelle ich mir auch vor, also oder mein Reflex, wenn ich so eine Aufgabe hätte, wäre erstmal zu sagen, okay, je einfacher ich das User Interface gestalte, desto leichter fällt es mir vielleicht auch Barrierefreiheit einzubauen.

Victoria: 10:49

Ja auf jeden Fall. Also wir sind erstmal so hergegangen, dass wir die bestehenden Produkte genommen haben und dann mit den Personen die wir dann rekrutiert hatten, vertestet haben und die sind die kompletten Anwendungen durchgegangen und somit konnten wir sehr viele Auch schwerwiegende Usability-Probleme aufdecken, also zum Beispiel, dass vielleicht manche Buttons gar nicht fokussiert wurden oder auch Thema Fehlerhandling, dass das konsequent gar nicht angezeigt wurde und somit einen Abbruch für die Person bedeuten würde. Ja, so sind wir da vorgegangen und haben Dann nach und nach unsere ganzen Strecken vertestet. Und im Anschluss sind wir hergegangen und haben das priorisiert, also auch anhand der Task Force haben wir geguckt, welche sind die wichtigsten Kriterien also AA-Kriterien und welche müssen umgesetzt werden und welche Kriterien sind eventuell noch gar nicht so schwerwiegend und wäre natürlich gut, wenn sie umgesetzt werden, aber Hätten jetzt auch erstmal noch keine priorität diese

Hendrik: 12:02

kriterien die sind definiert oder da genau ja genau das von also im rahmen dieses bfsg ist es dann auch noch gibt es eine verschiedene güte gerade nur für die da draußen die noch nie was davon gehört haben

Udo: 12:15

stelle ich mir sehr schwierig vor sozusagen die verschiedenen facetten sozusagen von Besonderen Bedürfnissen irgendwie abzudecken, also ich beispielsweise Leute, die aus irgendwelchen Gründen keine Maus benutzen können, sondern sich mit der Tastatur entlanghangeln, ich denke da an sehr stark seh-eingeschränkte Menschen beispielsweise, die dann vielleicht auch so eine breile Zeile haben. Wie habt ihr die Leute gefunden oder wie seid ihr da auf die zugegangen?

Victoria: 12:45

Ganz unterschiedlich also wir haben es zum einen über Kontakte versucht, die dann Kollegen hergestellt haben und zum anderen um eben noch mehr Personen zu rekrutieren, haben wir es dann über Online-Plattformen versucht, die genau das eben als Dienstleistung bereitstellen. Du kannst einen Screener also Anforderungen stellen, was du an Menschen benötigst und dementsprechend werden dir dann Personen für Slots vorgeschlagen.

Udo: 13:21

Und wie viel Zeit hatten die so grob gesagt irgendwie, um diese Anwendung zu testen weil ich stelle mir vor, die kannten vielleicht die Anwendung auch gar nicht und mussten die erst mal kennenlernen

Victoria: 13:31

Wir haben da sehr viel Zeit eingeplant, würden wir im Nachhinein auch anders machen. Also wir haben pro Person vier Stunden die testen lassen, einfach weil wir wussten, dass es einfach alles länger braucht, genau, bis die die Anwendungen verstehen und so. Und dadurch, dass es halt eben so ein Aufwand war und auch schwierig war, Personen zu rekrutieren, haben wir dann halt dementsprechend immer länger mit den Personen getestet Aber es war auch schon anstrengend für die Personen und für uns selber auch tatsächlich, das zu vertesten. Genau aber so sind wir vorgegangen.

Udo: 14:07

Ja, okay, jetzt habt ihr also eine Taskforce, ihr habt Priorisierung, ihr habt geschaut was fehlt der Anwendung noch, ihr habt Leute zum Testen da gehabt, die euch vielleicht diese Defizite, die ihr vorher irgendwo ermittelt habt, nochmal angereichert haben. Was waren da jetzt so die wichtigsten Erkenntnisse aus? Diesen Tests, also was habt ihr jetzt an der Anwendung sozusagen am ehesten verbessern müssen, wo fehlte es am meisten?

Hendrik: 14:35

Also ich kann am Anfang, was ich immer besonders spannend finde, ist, wenn Leute wirklich komplett blind sind und sich dann nur textuell und mit einem Screenreader Beispielsweise sich die Seite erklären lassen müssen und an welchen Stellen ist wirklich einfach an welchen Stellen die einfach verloren waren im Sinne von okay man steckt irgendwo im Nirwana weiß nicht mehr vor und zurück je nachdem muss man ja auch mit also man kann ja nicht mit der Maus auf den Button klicken aber wenn ich dann zum Beispiel so ein Also mit Tab kann ich ja dann zum Beispiel, also wenn man sich normal mit Tab durch so eine Seite bewegt, dann kam ich ja eigentlich von einem Element zum anderen, aber dann gab es Situationen da hatte man so eine Tab-Loop quasi. Das heißt, es ist immer zwischen den Komponenten auf einer Seite hin und her gehüpft und ich kam nicht mehr voran Dann wäre ich als sehbehinderter blinder Mensch komplett nicht in der Lage gewesen, den Workflow oder den Task, den ich dort gerade machen möchte, einfach abzuschließen. Völlig verrückt eigentlich. Das wären dann, also gerade weil wir vorhin noch kurz über Priorisierung gesprochen haben, das sind dann solche Deal-Breaker die geht man natürlich sofort an. Klar,

Udo: 15:54

weil da springen mir dann die Leute ja auch ab, also die können dann irgendwie die Strecke nicht absolvieren Die verliere ich dann auch wirklich.

Hendrik: 16:02

Genau, also das sind dann, das sind auch so Sachen, da muss man dann wirklich auch institutionalisiert, können wir ja später dann auch gleich darüber reden, schauen, dass das nicht wieder irgendwie kaputt geht und das ist dann auch sehr spannend. Was mich noch überrascht hat, beziehungsweise wo ich vorher gar nicht so den Bezug zu hatte, waren barrierefreie Dokumente. Also das hat einfach auch noch meinen Horizont erweitert, weil jemand der blind ist, der kann natürlich auch ein Dokument nicht lesen. Und wenn man jetzt den de facto Standard PDF nimmt, dann muss man da schon ein bisschen was tun, damit das überhaupt Barrierefreiheit ist. Also nicht jedes, nur weil ich ein PDF habe, heißt das nicht, dass ein Nutzer auch wirklich sich vorlesen lassen kann.

Udo: 16:48

Ja, beispielsweise bei einem Scan, da habe ich dann gar keine Chance, weil es ist einfach ein Bild und der Text ist zwar zu sehen, aber der Text ist nirgendwo enthalten in dem eigentlichen Dokument.

Hendrik: 16:58

Ja, und auch da gibt es wieder dann natürlich Möglichkeiten, kann ich jetzt auch wieder mit KI eventuell mittlerweile Dinge tun, aber ob das dann immer so alles, Wasserdicht ist gerade wenn man jetzt also wir sind ja im finanzbereich unterwegs und eine gewisse regulatorik auch dahinter sitzt also dass das alles da hat man muss man einfach auch gucken dass ich nicht also wenn ich jetzt zum beispiel für sagen wir mal 1000 euro irgendwas anlegen möchte und dann die ki sagt mir aber ja 100 euro dann denke ich ja dann wäre es irgendwie merkwürdig Wenn das Dokument dann für 1000 Euro unterschrieben ist, aber ich habe gedacht ich mache es für 100.

Udo: 17:37

Ja, auf jeden Fall. Und die Banken haben ja auch Informationspflichten denen sie nachkommen müssen und wo sie im Prinzip eigentlich nachweisen müssen, dass der Kunde informiert wurde. Auch da ist es natürlich dann ein großes Thema.

Hendrik: 17:49

Weiß nicht, Viktoria, hast du auch noch, ich meine, du bist ja noch viel tiefer drin als ich, aber hast du auch noch Erkenntnisse für dich mitgenommen, die du auch nicht so hattest vorher?

Victoria: 17:59

Erstmal unglaublich beeindruckend wie nicht sehende Personen durch diese Strecken gehen. Also wenn man das mal beobachtet und live dabei ist, das kann man sich gar nicht wirklich vorstellen als sehende Person, weil es für uns alles viel einfacher ist. Wie schnell die das auch alles verstehen und durch die Seiten navigieren, weil die halt ganz genau wissen, was sie tun müssen und wie die Seiten in der Regel aufgebaut sind. Und die verfolgen dann schon einen Standard, den sie halt von anderen Seiten kennen, eigentlich generell wie bei Usability auch. Man hat einen Marktstandard, den man dann eben bestmöglich abbildet und das ist bei Barrierefreiheit eigentlich gar nicht so anders. Und bei uns war ich dann teilweise auch überrascht dass es halt schon an so Basics gescheitert ist von der klaren Hierarchie-Navigation, also dass es von wirklich links oben nach unten gar nicht so einfach war, dann für die zu navigieren und Wie schnell, ja, wie Hendrik eigentlich auch schon gerade gesagt hat, dann irgendwelche Buttons nicht angezeigt wurden und die die Seiten nicht mehr zu Ende durchgehen konnten beziehungsweise nicht weiterkamen, weil wir dann auch immer Aufgaben gestellt haben, so, Bitte schließen Sie jetzt einen Sparplan ab oder so und die haben den Sparplan-Button dann zum Beispiel nicht gefunden. Genau.

Udo: 19:30

Ja, das ist ja, das macht ja nochmal ein neues Thema auf letztendlich. Ich hatte früher einen Kommilitonen, der hat, weil er ja eben blind war, Nur textbasierte Browser verwendet Das ist ja heutzutage eigentlich kaum noch möglich aufgrund des doch sehr präsenten JavaScript oder TypeScript. Kann man die eigentlich kaum noch nutzen so richtig, ne? Da stelle ich mir ohnehin vor, dass das eine Herausforderung ist, Barrierefreiheit mit SPAs so in Einklang zu bringen, ohne dass einem da das dynamische Skript irgendwie einen Strich durch die Rechnung macht. Mir fällt sofort so ein Captcha ein, was ich neulich gefunden habe, wo ich so lange irgendwie auf irgendwelche Bildchen klicken sollte, bis ich... Nichts mehr von dem beschriebenen Objekt da war, zu sehen war. Da habe ich gar keine Vorstellung, wie ich sowas absolvieren sollte, ohne... Sehen zu können.

Hendrik: 20:24

Gibt es meistens so auch für... Also ich kenne das mit den Captures, dann steht da irgendwie ja ich kann nichts sehen oder so, dann kann man da draufklicken und dann kommt irgendwie ein Ton oder beziehungsweise eine Audio-Sequenz, die dann in irgendeiner Form ganz viele Störgeräusche drin hat, sodass eine KI Schwierigkeiten hat zu hören, was da eigentlich gesagt wird und dann tippt man halt ein, was man gehört hat. Also sowas gibt es auf jeden Fall. Aber das ist natürlich nicht berücksichtigt, Dealbreaker, Showstopper, direkt die Conversion ist im Eimer. Ja, genau. Und vor allem muss ich ja dann, ich

Udo: 20:58

muss ja dann auch vor allem wissen, wie viele Alternativen muss ich anbieten. Also ich sage mal jetzt als Sehbehinderte ist das ein Thema, aber es gibt ja auch andere Besonderheiten die ich dann berücksichtigen muss. Also das heißt, ich muss mir immer überlegen... Wie viele Optionen muss ich sozusagen in meiner Anwendung haben, damit das funktioniert für alle?

Hendrik: 21:17

Aber ich denke, wenn man am Ende das Textuell in irgendeiner Form hinbekommt, dann kriegt man, glaube ich, so ziemlich alles erschlagen, oder? Also gerade auch, wenn man keine Maus bedienen kann beispielsweise, dann gibt es ja auch Möglichkeiten mit Voice-Eingabe, also mit Stimmeingabe.

Udo: 21:35

Ja, auf jeden Fall ein spannendes Thema. Habt ihr jetzt sichergestellt, wo ihr das Delta festgestellt hattet wo ihr die Sachen priorisiert hattet die ihr machen wolltet, wo eure User, die ihr die Anwendung testen habt lassen, euch Feedback gegeben habt? Wie habt ihr jetzt sichergestellt, dass dieses Feedback wieder über die Entwicklung in die Anwendung kommt und auch bei neuen Features tatsächlich wieder eben die gleichen Kriterien erfolgt Berücksichtigt werden, weil Barrierefreiheit ist ja wie vieles andere ein Querschnittsthema wie Sicherheit oder andere Sachen. Und insofern muss man es ja bei jeder Anforderung größtenteils berücksichtigen, letztendlich.

Victoria: 22:17

Ja, auf jeden Fall, also grundsätzlich ist es ganz wichtig, dass man das frühzeitig mitdenkt und also wie wir es jetzt auch gemacht haben, dass man wirklich nutzeraktiv immer in den Zyklus auch mit einbezieht und fragt weil wir es letztendlich für die Nutzer machen und nicht für uns selber. Frühzeitig das mit ein kippt in die story erstellung akzeptanz kriterien und daneben stetig weiterverfolgt und da ist es ganz wichtig dass wir das eben in interdisziplinären teams machen so dass wir quasi ständig im austausch sind zwischen product design fachlichen anforderungen also den business analysten und den entwicklern und dass wir das dann eben gemeinsam immer vorantreiben Also

Udo: 23:05

das heißt, noch ein weiterer Reiter im Leben des Product Owners, der sich Gedanken machen muss, wie kriege ich das jetzt in meiner Anwendung unter, auch noch zu allen anderen Sachen, die ich auch noch unterkriegen muss und möchte. Dort fängt es wahrscheinlich an. Der Product Owner und die Business Designer müssen sich da zu Beginn schon mal Gedanken machen und die Entwickler müssen natürlich von unten dann irgendwie Anforderungen hochreichen und sagen, wir müssen das so oder so oder so machen.

Hendrik: 23:37

Ja also definitiv Das ist ein Aufwand der jede Disziplin also jede Rolle in so einem Team betrifft Also gerade diese Cross-Funktionalität gibt aber dann auf jeden Fall die Chance, dass dann weniger Reibungsverluste entstehen. Also wenn ich dann diese... ähm solche Entwicklungspipelines haben, wo dann in irgendeiner Form ein Business Analyst überlegt sich was, äh gibt es dann der Entwicklung, die macht dann irgendeinen, ähm, ja, die, die, die entwickelt das und dann wird es dann Test übergeben, beispielsweise Test, testet das dann auch in irgendeiner Form und dann am Ende Kommt es auf die Prod, dann ist dann zwischen diesen Übergabepunkten ist halt immer so ein bisschen wie stille Post eigentlich, also da muss man natürlich immer gucken, dass dann auch diese Querschnittsthemen nicht irgendwo runterfallen und dann kommen wir dann, ja und das ist also, wenn man die Story halt gemein oder das Thema gemeinsam in irgendeiner Form entwickelt, sind auch alle Abgeholt, ist dann eigentlich auch effizienter. Also das ist ein Kernpunkt, so wie wir das zumindest in der Praxis leben, dass wir das Ganze möglichst cross-funktional aufstellen. Also das ist zum Beispiel eine so eine organisatorische Maßnahme und dazu kommt natürlich, dass Also wenn wir von, das ist natürlich in irgendeiner Form ein Prozessthema, worauf das einzahlt, aber wenn wir von Accessibility sprechen, dann haben wir unheimlich viele Regeln und da wäre es sehr, sehr ineffizient das alles nur beispielsweise durch manuelle Tätigkeiten und Prozesse in irgendeiner Form sicherzustellen, dass die Anwendung barrierefrei ist. Das bedeutet, wir brauchen auch in gewisser Form müssen wir auch unser Tooling, damit müssen wir uns auch beschäftigen und haben wir uns natürlich auch beschäftigt. Das fängt dann von der Entwicklung an, also wie baue ich vielleicht meinen HTML und CSS in irgendeiner Form zusammen, Richtung Linting gedacht. Das bedeutet, ja, ich schaue eben, dass ich möglichst semantisches HTML schreibe, weil dann, das ist das, Viktoria hat ja vorhin schon von Standard gesprochen, von Webseiten, also dass ich eben meine entsprechenden Tags habe, HTML-Tags, wo dann der Screenreader schon genau weiß, okay, das ist die Navigationssektion, das ist hier mein Main-Content und das ist mein Menü und wie auch immer. Und dass es nicht einfach nur Divs und Spans sind, die dann in irgendeiner Form hübsch aussehen, weil sie in irgendeiner Form mit CSS hingebogen wurden. Sondern das, was einem Nichtsehenden nichts bringt. Der braucht eben die Semantik dahinter. Und da kann man schon viel über Tooling und Pipelines regeln. Das

Udo: 26:22

ist aber auch, wenn ich das jetzt so höre im Prinzip ein Paradigmenwechsel. Weil vorher musste ich mir über meine HTML-Struktur in der Form diesbezüglich nicht solche Gedanken machen. Wenn ich jetzt Tatsächlich mit ARIA-Tags arbeite, das ist ja da das Stichwort, dann muss ich jetzt irgendwie und semantischen Beschreibungen, dann muss ich jetzt natürlich irgendwie erst mal meine ganzen Seiten angucken Was haben die momentan für eine HTML-Struktur? Und wie kriege ich das jetzt alles unter? Also wie kann ich das jetzt so umbauen, dass es tatsächlich für einen Screenreader Sinn macht? Also Semantik ist ja tatsächlich dann der Sinn.

Hendrik: 26:54

Ja, und das ist ja auch eine Kunst für sich in Anführungszeichen. Also es gibt ja diverse ARIA-Tags oder Attribute in dem Sinne eigentlich. Und deswegen gehen wir eigentlich eher her und sagen, wir wollen möglichst so wenig wie möglich von dieser Komplexität, die hinter diesen ARIA-Attributen stehen oder überhaupt hinter der technischen Umsetzung von der, vom Thema Accessibility, wollen wir weitergeben. Das heißt, wir wollen das in einer gewissen Form kapseln dass ich mich eben nicht bei jedem, bei jeder Story oder so ent... Damit befassen muss, okay, wie schaffe ich es, dass ich diesen Button, die ich da jetzt einfügen möchte, dass der barrierefrei ist, sondern dass ich in irgendeiner Form ein Framework außenrum habe, was mir das schon mitliefert, sodass ich genau weiß, okay, ich habe jetzt einen Primary Button, zum Beispiel einen Secondary Button und die verhalten sich auf eine gewisse Form. Ich habe bestimmte UI-Elemente zur Hand, wo ich genau weiß, okay, die sind barrierefrei. Und da kommen wir eigentlich dann auch schon zum Thema Designsysteme die wir gut finden bei Govind Pro. Also je nachdem wie groß das Projekt ist, aber gerade da wir auch häufiger größere Projekte machen im skaliert agilen Umfeld mit Dutzenden, Hunderten Personen, die damit involviert sind und da eignen sich Designsysteme beispielsweise besonders gut.

Udo: 28:20

Genau, und dann hat man natürlich auch jetzt die Chance, sich die Komponenten des Designsystems alle im Einzelnen dann anzuschauen und zu sagen, okay, was muss ich jetzt mit denen machen, damit die dann auch tatsächlich per se barrierefrei sind und wahrscheinlich dann auch teilweise im Verbund miteinander funktionieren. Weil es reicht ja auch nicht irgendwie immer nur die einzelne Komponente zu betrachten, sondern ich muss ja auch gucken, dass die im Verbund mit den anderen Komponenten vernünftig funktioniert für denjenigen, der die Seite benutzen möchte.

Hendrik: 28:47

Wunderbares Beispiel. Man klickt auf einen Button und ein Popup geht auf, also oder ein Overlay oder ein Model, je nachdem wie man es bezeichnen möchte, also es wird irgendwas auf die Seite gepackt zum Beispiel eine Hinweismeldung oder wie auch immer und dann klickt man dieses Ding, ist vielleicht oben ein X oder man hat unten einen Button, okay oder abbrechen oder wie auch immer und was passiert danach? Wo ist der Fokus?

Udo: 29:10

Da macht

Hendrik: 29:10

man sich sonst überhaupt keine Gedanken drüber. Aber in dem Zeitpunkt, das wäre wieder so ein Punkt, wo ein nicht sehender Nutzer gerade wieder verloren wäre. Wo bin ich eigentlich gerade? Und wo ist mein Fokus? Vielleicht ist er jetzt einfach verloren, weil das Element, auf dem der Fokus war, das ist jetzt irgendwo aus dem DOM geflogen. Und das sind super interessante Fragestellungen. Und das ist genau dieses Thema, wie funktionieren diese Elemente wirklich miteinander zusammen? Und das kann man dann schon allein durch die API der Komponenten Kann man das dann einfach schon lösen, indem zum Beispiel ich so ein Overlay-Model, you name it, dem ich immer zum Beispiel eine Komponente mitgeben muss, die danach den Fokus enthält. Oder er hält, besser gesagt. Sonst kann ich dieses Model zum Beispiel gar nicht aufrufen. Und ja, deswegen, das sind coole Anwendungsfälle, zum Beispiel für so eine Component Library oder für ein Designsystem.

Victoria: 30:02

Anderes Beispiel, Date Picker. Für uns als sehende Person super praktisch da schnell ein Datum auszuwählen. Für nicht sehende Personen absolut komplex, weil man erstmal jeden Tag und Jede Zahl auswählen muss, durchnavigieren muss und das wäre für die Personen viel einfacher, es schnell einmal einzutippen.

Udo: 30:27

Ja und das ist ja dann, da kommt man ja dann zum nächsten Thema. Also wenn ich dann Daten eingebe, dann komme ich ganz schnell in diesen Punkt irgendwie, welches Format sollen die denn haben und wie kriege ich denn eigentlich die Rückmeldung von der Validierung angezeigt. Also normalerweise ist Das dann irgendwo so ein roter String, der mir anzeigt dass ich irgendwas falsch eingegeben habe. Für einen nicht sehenden Menschen wahrscheinlich dann doch eher schwierig, das rauszufinden, weil der muss jetzt erstmal auf der Seite gucken, wo kriegt er denn jetzt angezeigt was er falsch gemacht hat und wie kann er es richtig machen.

Hendrik: 30:58

Ja also zumal auch gerade so ein, also die rote Farbe die ist Für uns als sehende Person ja ein ziemliches Marker-Element ist, da haben wir von klein auf gelernt, wenn es rot leuchtet siehe Ampel, dann sollte ich aufpassen und das benutzen wir auch viel, gerade bei so Fehlermeldungen und wenn ich alles gut auf eine Seite bekomme, SPA, Single Page Applications hast du ja vorhin schon angerissen, dann ist das für den sehenden Mensch überhaupt kein Problem. Aber da kommt es dann auch wieder darauf an, dass ich dann, wenn so ein Fehler auftritt, dass ich dann den Fokus auch wirklich dann direkt ans Element setze, dass dann, ja, dass dann der Nutzer eben nicht erst noch irgendwie sich mal quer durch die Seite tappen muss, in Anführungszeichen damit er mal sieht, was, oder damit er nochmal die Seite in irgendeiner Form in seinen Kopf reinkriegt um sie da zu interpretieren Also sein mentales Modell dann in dem Sinne anzupassen des Zustands.

Victoria: 31:50

Super spannend war aber auch zu beobachten, dass wenn dieses Fehlerhandling nicht mit bedacht wurde von uns jetzt initial, dann haben die Nutzer also gerade eine Nutzerin in dem Test ganz schnell erkannt, dass dieses Fehlerhandling nicht existiert und sie wusste wenn nichts vorgelesen wurde, dass sie gerade einen Fehler noch auf der Seite hatte. Und dann ist sie nochmal von, also nach ganz oben navigiert und ist alles durchgegangen, einfach nur, weil sie gelernt hat, dass wenn das jetzt erfolgreich weitergegangen wäre, die Strecke, dann... Wäre ihr irgendwie ein Loading-State oder sowas vorgelesen worden und das ist nicht passiert, nun hat sie das ganz schnell gelernt, also auch super hartnäckig dann immer dran geblieben und das war eigentlich ein Fehler in der Implementierung, aber sie hat das trotzdem verstanden

Udo: 32:45

Ja, da kann man wahrscheinlich dann auch schon wieder was von lernen von den Hilfestellungen, die sich diese Menschen dann einfach im Laufe der Zeit auch angewöhnt haben, wie sie mit solchen Anwendungen umgehen. Die erschließen sich einem nicht eingeschränkten Mensch einfach überhaupt nicht. Auch wenn ich manchmal trotzdem ich sehen kann und nicht eingeschränkt bin, manchmal trotzdem orientierungslos in Anwendungen bin, aber das liegt dann an der Anwendung das ist am Rande Das passiert ja nicht nur Menschen mit Einschränkungen, sondern das passiert ja auch uns. Ja, wie habt ihr jetzt versucht sicherzustellen, dass das in eurem Projekt sozusagen in Zukunft immer so weitergehen kann und Barrierefreiheit immer ein fester Bestandteil bleibt? Also was für Kniffe sozusagen musstet ihr da organisatorisch machen

Hendrik: 33:38

Organisatorisch, ja, kann ich gleich nochmal was zu sagen auch. Ich wollte auf jeden Fall nochmal ganz kurz Also wir haben eben viele beispiele auch teilweise absurde die gab eigentlich die sich absurd anhören die aber überhaupt nicht absurd sind haben wir gerade aufgezählt das bedeutet es kann an so vielen stellen kann einfach die barrierefreiheit schief gehen dass es Dass man irgendeine Form von Tooling und Unterstützung braucht, um das in irgendeiner Form handhabbar zu machen, also dass es in irgendeiner Form funktioniert. Und da sind wir dran, diese möglichst viel zu automatisieren. Das bedeutet, wir, also es gibt, Storybook kennen viele beispielsweise, da gibt es Accessibility-Plugins, wo man dann für die Komponenten die man dort entwickelt, sieht man dann zum Beispiel, wo Accessibility-Probleme sind. Da gibt es auch ein Tool, das nennt sich X, das ist halt relativ bekannt, was das dann automatisiert testen kann, also das bedeutet, ich kann das dann auch in meine Pipeline, also gerade Continuous Integration Server, kann ich das entsprechend mit einbinden. Das heißt, dass ich den Code, den ich schreibe, dass ich den gar nicht in irgendeiner Form auf die Produktion bringen kann, wenn dort Accessibility-Probleme in irgendeiner Form auftauchen. Also bedeutet, Automatisierung ist an der Ecke wirklich Ein großer Schlüssel und ein Riesenhebel. Und auf der anderen Seite ist das natürlich nicht das Einzige sondern das hatten wir am Anfang ja auch schon mal kurz, Man muss dieses ganze Thema Accessibility irgendwo in die Köpfe reinkriegen als Querschnittsthema, was einfach immer dazu gedacht gehört, ähnlich wie Security und da können wir auch nochmal drüber reden. Ich weiß nicht, Viktoria, du bist da ja als Product Designerin im agilen Umfeld quasi Ja auch schon einigen Kummer gewöhnt weil gerade so das Thema Product Design und Usability ist ja auch ein Querschnittsthema, was häufig eher so ein Schattendasein führt. Und man eher versucht die, oder weil häufig dann der Fokus auf Features ist und weniger darum, wie der Nutzer da durchgeführt werden kann, außer wenn man dann am Ende merkt okay, die Conversion ist nicht die Erhoffte.

Victoria: 36:00

Ja, ich glaube generell ist es aber ein Zusammenspiel aus mehreren Faktoren um das langfristig sicherzustellen. Also einmal kann man natürlich vieles abdecken auch durch diese Designsysteme Wenn dort Fehlerhandling und Barrierefreiheit mit bedacht wird, sodass es für nicht sehende Personen oder eingeschränkte Personen sehr gut nutzbar ist. Dann ist es automatisch bei der Implementierung gesetzt und es ist verfügbar und dann eben, wie Hendrik schon gesagt hat, durch automatisierte Tests. Jede Person trägt eine Verantwortung, das heißt fortlaufend Schulungen und Weiterbildungen oder Aufklärung zu leisten. Sodass wir alle da quasi gut agieren können und das langfristig nicht mehr in Akzeptanzkriterien mit aufführen müssen, sondern einfach einen Standard abbildet.

Hendrik: 36:55

Also was man da zum Beispiel auch machen kann, was wir jetzt auch gemacht haben, ist so bestimmte, also wir haben das so Accessibility Champions auch mal genannt Das bedeutet einfach, niemand kann alles in irgendeiner Form wissen. Das bedeutet, in einem cross-funktionalen Team hat auch nicht jeder alle Accessibility-Regeln zur Hand und kennt sich da hundertprozentig aus, kennt das komplette Tooling, kennt alle Use Cases und so weiter. Das bedeutet, es gibt dann so ein, zwei Personen in dem Team, die sich dann besonders gut auskennen und die dann in irgendeiner Form... Dann den Hut auf haben, dieses Thema Accessibility in ihrem Team halt irgendwo hochzuhalten und auch immer mal wieder drauf zu schauen, okay, sind die Prozesse noch so, wie sie sein sollten, ist das Thema noch präsent und wenn nicht, dann eben gegenzusteuern. Also das ist eine relativ einfache Möglichkeit, einfach eine Verantwortlichkeit zu verteilen innerhalb eines Teams.

Udo: 37:49

Sozusagen Accessibility Officers wenn man so will, die Sheriffs, genau und die kümmern sich wahrscheinlich dann auch darum, dass eben das Komponentensystem entsprechend angepasst wird, eine Beschreibung dafür gibt, wie ich das benutzen soll, weil ich sag mal, das sind natürlich alles sonst Themen, die für die Entwickler ein bisschen zu vielschichtig werden, als dass sie die alle alleine bearbeiten können. Die brauchen einfach diese Unterstützung, sonst ist so ein Projekt nicht mehr effizient.

Victoria: 38:14

Aber auch ganz wichtig, dass eben Entwickler schon mal in Vorleistung gehen und sagen, Das ist unser aktueller Stand und das könnten wir schon mal ausbessern. Das ist natürlich unglaublich hilfreich.

Hendrik: 38:27

Ich finde auch immer unheimlich hilfreich, einfach einzusehen dass das Thema Geld kostet. Also im Sinne von, das machen wir mal nicht mal eben her mit. Also wenn wir jetzt sagen, also das Tooling außenrum, das ist unheimlich wichtig, aber das musst du einführen, das musst du warten. Je nachdem, auf den Prüfstand stellen, den Baukasten in Anführungszeichen erweitern für die Use Cases, die da so kommen. Und dafür eine Awareness schaffen ist unheimlich wichtig. Und dafür sollte man sich natürlich auch dediziert Kapazitäten Freiräumen, die jetzt nicht an eine Story zum Beispiel auch nur gebunden sind oder an ein Feature. Das heißt, da ist viel Arbeit außenrum auch zu tun und dafür muss einfach auch die Zeit und das Geld einfach da sein. Und das muss man berücksichtigen.

Udo: 39:13

Klar, ich meine gerade das Thema Semantik kann unter Umständen mehr Zeit nehmen, als man denkt. Wir könnten sicherlich über das Thema noch... Eine ganze Weile weiter uns unterhalten. Ich glaube, wir müssen trotzdem so langsam zum Schluss kommen. Gibt es noch etwas, was ihr im Hinblick auf Human-Centered Design und Barrierefreiheit sagen wollt? Fällt euch da noch was ein, wo ihr sagt, das ist eigentlich für mich, es kann nur das eine mit dem anderen Hand in Hand gehen oder keine Ahnung, was sind eure Erfahrungen da? Habt ihr eine Einstufung nach HCD in dem Projekt gehabt?

Victoria: 39:51

Also, dass wir generell getestet haben und so früh mit den Barrierefreiheitstests gestartet sind, glaube ich, war schon auf jeden Fall ein sehr guter Auftakt und sollte auch in Zukunft weiter funktionieren So durchgeführt werden. Deswegen ist das jetzt ein sehr gutes Beispiel, wo ich sage, das war schon sehr nutzerzentriert wenn das so fortgeführt wird. Aber wie gesagt, ich glaube, das ist ein Zusammenspiel aus mehreren Faktoren, damit das eben nachhaltig dann auch so bestehen kann.

Hendrik: 40:25

Ja also ich denke die, also gerade das Thema Accessibility ist so ein Katalysator für das Thema Human Centered oder User Centered Design, also weil es einfach die, also uns als Softwareentwickler und Softwareentwicklerin einfach in den, ja in den, also in dieses Mindset oder einfach dazu zwingt uns mehr mit dem Nutzer zu befassen und nicht nur mit Features. Und das bedeutet, also ich gehe stark davon aus, dass dieses Thema Human-Centered Design in Zukunft noch einen stärkeren Drive erhalten wird. Also da wird man sich mehr mit befassen. Und ja, das ist eine Chance, einfach die Produkte einfach besser zu machen und besser benutzbar zu machen. Und ja, deswegen, ich sehe das BFSG, auch wenn es teilweise... Nervig ist an der einen oder anderen Stelle Dinge schwieriger macht, aber vor allen Dingen als eine große Chance an für uns als Anwender dann am Ende aber auch für die Unternehmen, für die Kunden, also für die Software entwickelnden Unternehmen Ja, bin gespannt, was da noch alles kommt.

Udo: 41:40

Und ist vielleicht auch keine schlechte Idee für einen einsteigenden Entwickler der in das Projekt neu dazukommt, wenn der schon mal Semantik vor sich hat, dann versteht vielleicht die Anwendung auch etwas besser. Es hat also viele Nebeneffekte die man sich da auch wünschen würde. Finde, das ist ein super Schlusswort. Works for me ist ja auch schon sowieso lange vorbei. Ich danke euch sehr für das Gespräch und die Einblicke Vielen Dank auch. Und wünsche euch noch viel Erfolg beim barrierefreien Gestalten.

Hendrik: 42:06

Danke danke.

Udo: 42:08

Macht's gut. Tschüss.

Hendrik: 42:09

Tschüss