KLARTEXT Der Podcast für IT ohne Barrieren. Interessante Informationen und wertvolles Wissen zur digitalen Barrierefreiheit in der Arbeitswelt. Ein Podcast zum Forschungsprojekt iDESkmu, gefördert vom Bundesministerium für Arbeit und Soziales unter der Federführung des Blinden- und Sehbehindertenverein Hamburg e.V. . Hallo und herzlich willkommen zur Episode #01. Mein Name ist Nadia David. Hören Sie heute den Expertentalk mit Sarah Matthies, Frontend Entwicklerin bei dem Unternehmen zeb applied zur Definition der Begriffe von Accessibility, Usability und User Experience. Im Anschluss ein Interview mit Christoph Gesting der Quinscape GmbH zum Thema Design4All. Dabei erhalten wir einen Einblick in bewährte Vorgehensweisen für den Einstieg in das Thema für Entwicklerinnen und Entwickler. In den Shownotes finden Sie die Timecodes zu den Beiträgen und Hintergrundinformationen zu unseren Gesprächspartnern und Gästen. Zum Einstieg in die Episode hören Sie einen kurzen Auszug aus einem bekannten Märchen. Der süße Brei. Es war einmal ein armes, frommes Mädchen, das lebte mit seiner Mutter allein, und sie hatten nichts mehr zu essen. Da ging das Kind hinaus in den Wald. Dort begegnete ihm eine alte Frau, die kannte seinen Jammer schon und schenkte ihm ein Töpfchen. Zu dem sollt es sagen: Töpfchen koche. So kochte es guten, süßen Hirsebrei, und wenn es sagte, Töpfchen steh!, so hörte es wieder auf zu kochen. Das Mädchen brachte den Topf seiner Mutter heim, und nun waren sie ihrer Armut und ihres Hungers ledig und aßen süßen Brei, so oft sie wollten. Das war der süße Brei, gelesen von Anna aus der Mac internen Screenreader Software Voice-Over in der Geschwindigkeit 60 von 100. Jetzt zu unserem Expertentalk. So, ja. Sarah, Sarah Matthies ist mit dabei heute und Detlef Girke. Und heute soll es um das Thema Accessibility, Usability und Auswirkungen auf die Unternehmenskultur gehen. Und jetzt im Vorfeld natürlich erst mal eine kleine Vorstellung. Was machen wir überhaupt? Was ist unser beruflicher Alltag? Sarah, magst du loslegen? Danke, Detlef! Genau. Mein Name ist Sarah und ich arbeite bei zeb applied. Und wir sind eine Tochtergesellschaft von zeb, einer Unternehmensberatung für Banken und Versicherungen oder Finanzdienstleister allgemein. Und ich bin da als Frontend Entwicklerin angestellt. Ich kümmere mich um alles, was so Oberflächen angeht und habe vorher Human Computer Interaction studiert und habe dadurch so ein bisschen den Fokus Usability und vor allem auch Accessablity - also Barrierefreiheit - bei uns mit ins Unternehmen gebracht. Ah, okay, gut. Und jetzt noch ein bisschen zu meinem Hintergrund. Ich bin selber sehbehindert und bin darüber tatsächlich auch an die Thematik barrierefreie IT gekommen. Ich arbeite seit fast 20 Jahren selbstständig als Barrierefreiheitsberater, also Berater für Barrierefreiheit genauer gesagt. Ja, ich bin momentan im Projekt iDESkmu als technische Leitung beschäftigt. Ja, mich interessiert jetzt erstmal, Du hast schon so ein bisschen beschrieben wie Du zu Barrierefreiheit gekommen bist. Wie siehst du das? Für wen ist barrierefreie IT eigentlich wichtig? Das ist eine gute Frage. Also die Frage ist eher, für wen ist es nicht wichtig? Ich glaube schon, also wenn ich das ganz klassisch sehe, ist für mich Barrierefreiheit oder Accessibility die Grundlage auch für die ganzen anderen Themen. Also, du hast gerade schon kurz gesagt Usability und auch User Experience war glaube ich auch schon gefallen. Das sind für mich alles Sachen, die nur auf einer barrierefreien Anwendung aufbauen können, weil nur, wenn der Nutzer am Ende des Tages die Anwendung auch benutzen kann, kann ich sie usable gestalten, also so, dass er sie effizient und effektiv benutzen kann und auch dann im Sinne der User Experience, dass sie ein positives Nutzergefühl auslöst. Also ich würde schon sagen, dass barrierefreie IT für jeden wichtig ist. Also es gibt natürlich Nutzergruppen, du sagst ja selbst, dass du eine eingeschränkte Sicht hast, da sind die Anforderungen natürlich noch mal stärker und anders, aber auch für den normalen Benutzer. Wenn die Schrift zu klein ist, dann bringt mir das überhaupt nichts, wenn die Anwendung besonders schön zu benutzen ist, wenn ich sie einfach nicht benutzen kann. Ja, das stimmt auch. Also wenn man schon die ganze Accessibility berücksichtigt hat, dann hat man ja schon die möglichst breite Palette an potenziellen Nutzerinnen und Nutzern mit abgedeckt, dass dann für alle anderen die Usability verbessert ist und auch die Benutzererfahrung, die UX, das liegt eigentlich auf der Hand, oder? Ja genau. Natürlich musst du dafür nochmal Schritte ergreifen, aber erst mal muss die Anwendung ja wirklich benutzbar sein im Sinne von sie ist zugänglich: ich sehe, ich kann alle Texte lesen. Ich weiß, wie die Anwendung zu benutzen ist, was die Status mir vermitteln. Also da gibt es ja ganz viele Sachen, die man beachten muss und ja, auch glücklicherweise Standards. Also es gibt ja den WCAG Standard, der ja schon eine ganz gute Grundlage dafür bildet, worauf man achten muss: dass man zum Beispiel bestimmte Kontraste beachtet, dass man darauf achtet, dass zum Beispiel Hinweise oder Hierarchien nicht nur über Farben dargestellt werden. Also es ist ja nicht, dass man da das Rad neu erfinden muss, sondern es gibt Standards, an die man sich halten kann und dann kann zumindest jeder die Anwendung benutzen. Und dann kann man ja die Usability, also die tatsächliche Nutzung der Anwendung, dann an seine Zielgruppe anpassen. Ja, super. Also du machst jetzt ja Frontendentwicklung und hast früher aber auch mehr im Backend gearbeitet. Hat dich da die Accessibility schon von vornherein besonders gereizt oder was hat dich dahin geführt? Ja, nicht ganz. Also ich habe tatsächlich im Bachelor Wirtschaftsinformatik studiert und habe dann als Entwicklerin in der Firma angefangen und da bin ich einfach in die Backendentwicklung reingerutscht. Und ich habe dann nach einem Jahr gemerkt, dass das irgendwie noch nicht ganz das ist, was ich möchte. Und ich wollte auch unbedingt noch einen Master machen, das stand für mich fest. Und dann bin ich in Siegen gelandet und habe da Human Computer Interaction studiert. Ich habe meine Masterarbeit damals in einem Altenheim geschrieben. Also ich habe eine Projektarbeit gemacht und habe mich mit Robotik in der Pflege auseinandergesetzt. Also gar nicht in der klassischen Pflege Pflege, sondern eher im sozialen Dienst und in der sozialen Interaktion. Und bin dadurch so ein bisschen das erste Mal mit Zielgruppen mit besonderen Bedürfnissen in Kontakt gekommen. Ich meine, sind ja viele Bedürfnisse, die da überlappen, also Menschen mit Behinderung und auch ältere Leute. Also gerade was so visuelle Einschränkungen angeht, zum Beispiel. Und habe da das erste Mal Berührung mit WCAG gehabt und habe dann auch nach dem Studium für mich entschieden, ich möchte weiterhin als Entwicklerin arbeiten, aber halt auch ein bisschen mehr an die Front. Und mich ein bisschen mehr mit den tatsächlichen Benutzeroberflächen auseinandersetzen, um da auch das Wissen aus dem Studium einfließen zu lassen. Und dann hat sich das auch eher zufällig ergeben, weil ich hatte dann so ein bisschen das Wissen aus der Masterarbeit, noch was das Thema Barrierefreiheit angeht und habe dann festgestellt, dass das in vielen Banken oder generell bei vielen Entwicklern noch gar nicht so angekommen ist das Thema, obwohl es ja wirklich Wichtigkeit hat und auch gar nicht so kompliziert ist umzusetzen an vielen Stellen. Und habe das deswegen einfach so ein bisschen zu meinem Steckenpferd gemacht und nimm das immer so ein bisschen meinem Alltag mit. Toller Weg dahin. Fällt dir das auch auf? Du sagst gerade "irgendwie nicht so kompliziert umzusetzen." Wenn ich aber an diese Fülle an, sagen wir mal historischen Anwendung denke, die ursprünglich mit Tabellen-Layouts aufgebaut waren und dann mit der Zeit erstmal zu sogenannten DIV-Wüsten wurden, wo dann die ganzen Tabellen durch DIVs ersetzt wurden. Und ich bekomme es ganz häufig mit, dass heutzutage diese ganzen uralt Anwendungen mit ARIA vollgeknallt werden, damit sie einigermaßen barrierefrei sind. Kennst du das auch? Ja, fürchterlich, du hast tatsächlich recht, ARIA ist ein sehr spezielles Thema. Ich weiß tatsächlich selbst von mir auch, als ich mit der Webentwicklung selbst angefangen habe, war das an vielen Layouts oder in vielen Bibliotheken, die ich benutzt habe, war das ARIA-Label war quasi schon an den Komponenten dran, damit man bloß daran denkt, auch ein Label auszufüllen. Und ich glaube, das wird gerne benutzt, um dann so "smelly code" auszugleichen. Also eigentlich, wenn man barrierefreie Anwendungen bauen will oder Anwendungen, die auch für Screenreader optimiert sind, dann würde man ja semantisches HTML benutzen, also nicht ein DIV, das man dann Button nennt, sondern eben dann wirklich das Button-Tag auch benutzen. Und ARIA wird dann gerne benutzt, wenn man eben nicht von Anfang an sauber programmiert hat, um genau das auszugleichen. Ich habe sogar mal eine Studie gelesen, dass häufig, also je mehr ARIA auf einer Seite eingesetzt wird, desto weniger barrierefrei ist sie häufig, weil es eben genau dafür benutzt wird, um Fehler auszugleichen. Ich glaube, das Grundmissverständnis liegt schon im Namen. ARIA steht ja für "Accessible Rich Internet Applications", also zugängliche komplexe Internet- Anwendung würde ich es mal frei übersetzen und dann denken natürlich alle: okay, ich muss ARIA verwenden, um komplett zugänglich zu werden und das ist mitnichten der Fall. Also ein gutes, semantisches HTML ist immer noch wesentlich besser als ARIA. Und was viele nicht wissen, ARIA überschreibt einfach alles, was mit HTML gebaut wurde und damit kann es eben auch wirklich guten semantischen Code komplett zerstören. Ja, das stimmt. Also, deine Button-Link Problematik, die du gerade angesprochen hast, also Buttons, die dann mit der Leertaste ausgelöst werden können. Links, die wie Buttons aussehen, dann aber nicht ausgelöst werden können. Sowas meintest du zum Beispiel? Genau! Ich glaube, da müssen wir fast noch ein bisschen ausholen, weil das Beispiel ist eigentlich ganz gut, weil was ARIA macht ist ARIA gewinnt. Also überall, auch über das semantische HTML. Immer! Und das heißt, wenn ich jetzt in meiner Anwendung zum Beispiel einen Link habe, und der sieht aus wie ein Button und ich möchte, dass der Screenreader da auch Button vorliest, dann kann ich da einfach dran schreiben Role = Button und was passiert ist, der Screenreader wird dann sagen "Button mit dem Inhalt xyz." Aber was er halt eben nicht macht, er überschreibt halt nur die Rolle und nicht, wie sich der Button verhält. Das heißt, ein normaler Button, wenn ich jetzt den über die Tastatur ansteuern würde, dann kann ich ihn auslösen, indem ich die Leertaste drücke. Wenn ich aber einfach nur einem Link die Rolle = Button gebe, dann wird zwar Button vorgelesen, ich kann aber die Leertaste gar nicht benutzen. Das führt dann dazu, dass es gar nicht mehr zusammenpasst, also das, was der Screenreader sagt und wie sich die Komponente dann tatsächlich verhält. Das ist ja eigentlich das Schlimme daran. Genau, das Nutzungsgewohnheiten sozusagen durchbrochen werden und Nutzer vor einem Missverständnis stehen, also nicht mehr die üblichen Tasten drücken können, um eine Anwendung zu nutzen. Und das sollte natürlich möglichst vermieden werden. Andersherum man muss auch sagen, man darf ARIA natürlich auch nicht verteufeln. Also auch viele von den ARIA Rollen zum Beispiel. Es gab mal ganz früher die ARIA Rolle "Dialog" und die hat es tatsächlich in dem neuen HTML Standard auch als eigenes Tag geschafft, weil sie so gut angenommen wurde. Also, Aria bietet sich dann da an zu nutzen, wo HTML eben noch keine passenden Sachen anbietet. Ohne ARIA gäbe es HTML5 in der heutigen Form nicht, das ist tatsächlich war. ARIA hat einen ganz, ganz wichtigen Prozess angestoßen, aber man muss eben wirklich ein gewisses Feingefühl entwickeln, wo ARIA zu verwenden sinnvoll ist und wo nicht. Also ich finde zum Beispiel bei Landmarks, da ist ARIA super. Die ganzen Landmarkrollen sind im Grunde auch ARIA oder rühren ursprünglich daher und wenn ich mir überlege, wie grafische Oberflächen erfasst werden können über diese Landmarks, dazu noch mit den richtigen Labels teilweise versehen, um wirklich genau zu deklarieren für blinde Menschen zum Beispiel, wie ein Bereich heißt und was dort möglich ist. Das finde ich absolut super, weil dann können sich wirklich sehende und nicht sehende Menschen über das Gleiche unterhalten. ARIA-Labels sind natürlich nicht immer super. Wenn sie Title-Attribute ersetzen, dann können Sehbehinderte wiederum nichts damit anfangen oder sehende Menschen. Aber ansonsten finde ich ARIA-Labels in vielen Bereichen, gerade wenn es darum geht, wirklich für blinde Menschen den Informationsgehalt zu steigern, gut. Sarah Matthies, zeb applied>Ja, definitiv. Wobei auch da gibt es ... Also bei den Landmarks teile ich das absolut. Gerade, auch wenn dann eben das nav-Tag oder so nicht ausreichend ist und ich das noch mal ein bisschen genauer betiteln möchte, was dieser Bereich für eine Rolle hat. Bei z. B. Labels von Inputs gibt es ja auch noch andere Wege. Ich kann ja auch über CSS zum Beispiel ein richtiges Label anlegen und das dann einfach visuell verstecken, dass die sehenden Nutzer es nicht sehen. Der Screenreader ist aber wahrnimmt. Das ist ja auch nur eine Möglichkeit. Und ich glaube, das ist auch sicherer, weil soweit ich das weiß, aber da bist du wahrscheinlich mehr der Experte, ARIA ist ja auch nicht in den verschiedenen Screenreader, also da gibt es ja keinen STANDARD und die Verhaltensweisen ändern sich da. Und da ist man mit einem semantischen HTML, das man einfach für sehende Benutzer versteckt, einfach besser unterwegs, weil das standardisiert ist, ARIA eben nicht. Viel, viel sicherer. Also man kann zum Beispiel eine Fehlermeldung über einen Role = Alert ausgeben - wird von allen Screenreadern vorgelesen. Aber was man auch machen kann ist, wenn ein Fehler bei der Eingabe bei einem Formular passiert, dass man eben den Fehler in das Label mit reinschreibt, dann per Stylesheet versteckt oder eben für Sehende über dem jeweiligen Formular Feld platziert, aber Teil des Labels macht, das es auf jeden Fall immer vorgelesen wird und so ist es wesentlich sicherer, weil jedes Mal, wenn ich dann zu dem betreffenden Formularfeld komme, weiß ich genau, welchen Fehler ich gemacht habe und was ich zur Korrektur des Fehlers tun kann. Das ist eine viel eindeutigere Information, die man dann erhält. Das stimmt. Und: Das Verhalten ist für Sehende und nicht sehende Nutzer gleich. Das finde ich halt auch immer wichtig, dass man nicht in so Verhaltensweisen reinkommt, wo sich die Anwendungen unterschiedlich verhalten für die jeweiligen Nutzergruppen, weil das sollte nie der Fall sein. Ja, wie ist das bei den verschiedenen Screenreader? Wie unterschiedlich sind die tatsächlich bei der Ausgabe? Auch jetzt zum Beispiel bei ARIA? Mittlerweile nähern die sich natürlich miteinander aneinander an, aber Jaws zum Beispiel, der älteste Screenreader, den ich so kenne - JAWS steht für "Job Access With Speech" und den kenne ich seit über 20 Jahren im Grunde als Screenreader - der hat sich natürlich auch historisch entwickelt und bietet eine unglaubliche Fülle an Funktionen und ist natürlich unglaublich gut über Scripting und so weiter auch konfigurierbar. Der hat aber teilweise, das bemerke ich immer wieder neu: der zeigt manchmal Mängel bei der Nutzung zum Beispiel von Firefox, obwohl er früher eigentlich für Firefox mehr oder minder optimiert war. Da funktioniert mittlerweile NVDA viel besser und NVDA steht für "Non Visual Desktop Access", das ist ein OpenSource Screenreader. Sowohl JAWS als auch NVDA können mittlerweile wirklich professionell eingesetzt werden. Aber der riesige Vorteil von NVDA ist, NVDA liest PDF-Dokumente perfekt vor. Das kriegt JAWS bis heute nicht so toll hin wie NVDA. Und Narrator. Das ist ein anderer Screenreader, der ist wirklich in Windows mit implementiert. Kleiner Tipp für unsere Hörerinnen und Hörer: Drücken Sie einfach die Windows-Taste, die Steuerungs-Taste und dann die Enter-Taste gleichzeitig und schon wird der Narrator angeschmissen und Sie können sich mal anhören, wie so ein Screenreader funktioniert und dann liefert Windows dazu automatisch auch direkt eine Anleitung für die ersten Schritte. Und schon kannst du mal ein bisschen rumspielen mit einem Screenreader. Ja und Narrator ist natürlich auf das Windowssystem ausgerichtet und Java-Anwendungen zum Beispiel kann man mit Narrator im Grunde gar nicht nutzen. Das funktioniert nie. Der schweigt dann einfach. Das heißt, es wird dann wirklich einfach nicht ausgelesen? Nein, es passiert gar nichts. Man denkt, man hätte jetzt keinen Screen mehr an. Du hattest gerade Screenreader-Skripting so kurz mit eingeworfen. Ist das dann was, was man dann benutzen würde, wenn Anwendungen nicht zugänglich sind? Oder würde das da dann auch nicht helfen? Also ich finde, Screenreader-Scripting ist gut, dass es das gibt. Es sollte aber immer nur eine Übergangslösung sein, weil man muss immer wissen, Scripting setzt man dort ein, wo Anwendungen nicht zugänglich sind. Und unser Ziel ist es ja, zugängliche Anwendung zu erhalten. Das ist wie ein Regenmantel, den ich anziehe. Also, wenn ich nicht nass werden will, dann ziehe ich einen Regenmantel an, aber es regnet immer noch und ich könnte immer noch potenziell nass werden. Und genauso ist es mit dem Scripting auch. Die Barrieren sind damit nicht beseitigt. Aber wie gesagt, positiv finde ich es doch, dass es das gibt. Ja, ich finde tatsächlich den Vergleich mit dem Regenmantel sehr, sehr schön, weil das trifft es sehr gut. Ich meine, das ist ja auch... Also, natürlich hat ARIA einen anderen Hintergrund, aber ein bisschen passt es dazu ja auch. Es hilft da aus, wo semantisches HTML und die Standards an ihre Grenzen kommen. Genau, genau. Aber die Unsicherheit ist natürlich genau dort auch ein bisschen da: wenn ich dann Updates habe, zum Beispiel wenn ich eine Framework basierte Webanwendung habe, ich halte ein Update, dann kann es passieren, dass die Scripte nicht mehr funktionieren und dass die dann nebenbei auch noch mal upgedatet werden müssen. Schafft dann auch wiederum Lücken bei der Arbeitsfähigkeit. Und ja, und natürlich Frustration am Ende. Sarah Matthies, zeb applied>Ja, das stimmt. Aber gerade für Legacy-Systeme, die eben nicht mehr upgedated werden und wo vielleicht auch nicht ersichtlich ist, dass da noch mal was kommt in Richtung Barrierefreiheit, ist es ja zumindest erstmal eine ganz gute Option. Dafür ist es eine gute Option. Genau. Aber wie ist das denn beim Screenreader-Scripting? Wer würde das machen? Gibt es extra Entwickler, die sich nur darauf spezialisieren? Oder ist das etwas, was man anfragen kann, wo man Unterstützung erhält? Nein, es gibt tatsächlich Firmen, die sich darauf spezialisiert haben. Also häufig sind das traditionelle Hilfsmittel-Anbieter, die in der Vergangenheit wirklich physische Hilfen für Menschen mit Behinderungen hergestellt haben. Lupen, Lese/Sprech-Geräte, Bildschirm-Lesegeräte, eben auch Screenreader dann mit der Zeit oder auch alles Mögliche an anderen Hilfen für Menschen mit Behinderung. Und die haben sich dann, nachdem sie dann auch anfingen, Screenreader zu vertreiben, darauf spezialisiert, auch entsprechende Skripte zu schreiben. Und da gibt es einige, die sind richtige Koryphäen darin geworden, die auch immer wieder dann übers Integrationsamt angeheuert werden, sozusagen, um dann einen Arbeitsplatz flott zu machen. Erstmal. Also mich interessieren jetzt gerade noch mal Unternehmen. Gerade auch Unternehmen, denen barrierefreie IT noch fremd ist. Das erlebst du wahrscheinlich in deinem Alltag auch häufiger, oder? Ja, total. Ich glaube, das Problem ist an vielen Stellen auch einfach noch das Thema kommt ja immer mehr. Wir haben ja jetzt auch mit dem ... Oh, jetzt will ich nichts Falsches sagen. Der European Accessibility - ist das der Act? Ja richtig. Genau. Zum einen das, aber auch das WCAG bzw. jetzt generell Barrierefreiheit bei öffentlichen Stellen auch schon verpflichtend ist. Dadurch ist das Thema schon mehr im Fokus, zumindest bei Finanzdienstleistern. Also viele Banken sind zwar keine öffentlichen Stellen, aber versuchen sich schon an solche Standards auch zu halten. Ich glaube, woran es oft scheitert oder zumindest ist das das, was ich viel mitkriege, wenn ich mich mit anderen Entwicklern unterhalte oder auch mit anderen Designern (ich bin hier ja ganz ganz gut in der Mitte) ist, dass es oft so ein Verantwortungsthema ist. Also, Accessibility hängt halt auf vielen Ebenen. Natürlich hast du so was wie semantisches HTML, was in der Entwicklung beachtet werden muss, aber das Design der Anwendung muss ja auch schon barrierefrei sein. Was wir gerade schon kurz hatten, das eben die Kontraste zum Beispiel passen. Ich glaube, da fehlt einfach noch so ein bisschen vielleicht eine übergeordnete Rolle oder das generelle Bewusstsein für dieses Thema, dass das eben auf allen Ebenen mit Bedacht wird und eben nicht eins von vielen Features ist, sondern dass das Bestandteil von allen Neuentwicklungen ist und eben nicht mal hinten dran gehängt wird. Am Ende muss die Anwendung noch barrierefrei sein, sondern das muss halt in allen Schritten mit Bedacht werden und auch auf allen Ebenen. Ja, ich finde auch irgendwie, die Barrierefreiheit gehört einfach in den gesamten Entwicklungsprozess und muss wirklich bei allen Beteiligten ankommen. Also wenn ich allein schon bedenke, wie häufig es passiert, das was du gerade eben meintest, dass Kontraste nicht stimmen bei der User Interface-Entwicklung. Das hängt ja ganz oft damit zusammen, dass es vor dem Start der Entwicklung ein großes Gremium gab an Leuten, die sich überlegt haben: "Ah, da muss ein Button in der Farbe hin, da einer in der Farbe... Ach nein, da mag ich doch lieber Gelb auf Grau lieber..." und so weiter und so fort. Und schon hat man einen kontrastarmes Layout. Und das ist wirklich von oberster Stelle dann sozusagen beschlossen und darf dann auch nicht mehr geändert werden. Und am Ende hat man dann eine Anwendung, die nicht barrierefrei ist, weil ganz von Anfang an etwas beschlossen wurde, was schon in sich nicht barrierefrei war. Sowas habe ich auch schon oft erlebt. Matthies, zeb applied>Ja, ganz genau. Also ich glaube schon, dass da die Prozesse auch angepasst werden müssen, dass alle Richtlinien brauchen, an denen sie sich auch orientieren können. Ich hatte auch kürzlich einen Kunden- termin und habe ein Design vorgestellt. Und dann sagte der eine Vorstand, der in dieser Vorstellung mit dabei war, dass er (das war nur eine kleine Grafik), aber trotzdem, da waren Sterne zu sehen und die waren orange auf - ich weiß gar nicht mehr was für eine Hintergrundfarbe. Und dann sagte er, er sei farbenblind und er würde die Sterne gerade gar nicht sehen. Ob wir daran noch mal arbeiten können? Und das, obwohl ich wirklich darauf achte. Aber es passiert halt, dass man halt eben nicht bei allen Sachen unbedingt nochmal darauf achtet. Aber das muss sich ändern. Es muss ein Prozess her, der Barrierefreiheit als ganz normalen Bestandteil des Entwicklungsprozesses auch anerkennt. Und ich glaube, das funktioniert wirklich nur, wenn Barrierefreiheit wirklich in der DNA der Unternehmen mit drin ist. Okay, wir könnten uns jetzt noch endlos unterhalten. Es gibt ja auch noch einige Hürden bei mobilen Apps, die aus irgendwelchen Frameworks gebaut werden, die dann gleich für iOS, für Windows, für Android und für was weiß ich noch alles irgendwie eine Barrierefreiheit oder eine angeblich barrierefreie App ausspucken. Und wenn man sich das dann anschaut, dann ist es einfach nur eine Katastrophe. Also wir kriegen wahrscheinlich auch noch eine halbe Stunde mit ARIA voll. Garantiert ohne Probleme. Aber ich glaube, wir haben das Thema jetzt zumindest erschöpfend angerissen und bei Interesse kann man ja auch uns persönlich ansprechen und dann kann man sich auch länger mit uns darüber unterhalten. Aber um das erst mal aufzuzeigen, ich denke, hat es so gereicht. Ich freue mich sehr, mich mit dir darüber unterhalten zu haben und und lass uns die Diskussion fortsetzen. Finde ich super spannend. Ja, sehr gerne im Nachgang und danke für die Einladung. Es freut mich, dass ich mich mit dir hier austauschen durfte! Ja, freut mich ebenfalls, Sarah! Kommen wir nun zum Bereich Quiz und der Antwort auf die Frage aus der letzten Episode: Was ist der Unterschied zwischen den Begriffen Accessibility, Usability und User Experience? Nach den Ausführungen von Sarah Matthies kennen Sie die Antwort vielleicht schon. Detlef Girke fasst Sie ihn hier nochmals zusammen. Während die Accessibility die technische Zugänglichkeit einer Software oder Websites beschreibt, geht es bei der Usability um die Nutzbarkeit einer Software. Bereits hier spielen Aspekte der Benutzerfreundlichkeit eine Rolle. Die User Experience umfasst das gesamte Nutzungserlebnis, also das "wie gut" lässt sich eine Software nutzen und entsteht dabei vielleicht sogar etwas wie Vertrauen oder Spaß bei der Nutzung? Und hier die Frage, die wir Ihnen in der nächsten Episode beantworten werden: Rund um das Thema Barrierefreiheit in der IT gibt es nationale, europäische und internationale Gesetze, Verordnungen und auch Vereinbarungen. Wie genau stehen diese drei Bereiche hierarchisch in Beziehung zueinander? Antwort A: Zum Thema Barrierefreiheit in der IT gibt es das internationale Recht, auch Völkerrecht genannt. Es steht direkt über dem nationalen Recht einzelner Länder und Staaten. Antwort B: Zum Thema Barrierefreiheit in der IT sind für Deutschland das europäische Recht mit Richtlinien, Verordnungen und Regeln verbindlich nach dem nationalen Recht in Deutschland. Antwort C: Die rechtliche Anwendbarkeit von Gesetzen, Verordnungen und Vereinbarungen ist klar hierarchisch gegliedert. Zuoberst steht das internationale Recht mit seinen UN Konvention, zum Beispiel die UN-Behindertenrechtskonvention von 2008. Es folgt das europäische Recht mit EU-Richtlinien und EU-Verordnungen. Erst dann folgt das nationale Recht mit Gesetzen, zum Beispiel dem Grundgesetz und dem Behindertengleichstellungsgesetz, Verordnungen (zum Beispiel Barrierefreie Informationstechnikverordnung 2.0) und Regeln, wie zum Beispiel technische Regeln für Arbeitsstätten. Auch ASR. Hören Sie nun unser Interview. Ich spreche heute mit Christoph Gesting, Leiter Digitale Barrierefreiheit bei der Dortmunder Firma Qinscape GmbH, über das Thema Design4All und barrierefreie Apps. Quinscape ist Test-, Beratungs- und Implementierungs-Partner für barrierefreie IT Anwendungen sowohl bei Unternehmen als auch öffentlichen Stellen. An diesem Punkt erst mal vielen Dank an Dich, Christoph, dass du heute dabei bist. Gerne würde ich erst einmal den Begriff [25:56] Design4All klären. Worum handelt es sich dabei? Wer muss was warum tun und welche Regeln gibt es, die dabei beachtet werden müssen? Vielen Dank, dass ich dabei sein darf. Ich freue mich sehr und das sind eine Reihe spannende Fragen, die wir auch durchaus alle beantworten können. Fangen wir einfach mal mit dem Begriff Design4All an. Das ist ein englischer Begriff, hat etwas mit Design zu tun. Design4All soll die Bedürfnisse aller betrachten und Menschen mit Behinderungen als einen selbstverständlichen Teil der Gesellschaft akzeptieren. 8 Millionen Menschen in Deutschland sind tatsächlich schwerbehindert und wenn man das auch auf ganz Europa auslegt, dann macht das 50 Millionen Menschen aus, die eine Behinderung haben. Und das sind 10 Prozent der Bevölkerung. Und da sprechen wir schon wieder von ganz anderen Zielgruppen als den einen blinden Menschen. Hinzu kommen vier weitere Millionen Menschen, die einen Migrationshintergrund haben und auch keine guten Deutschkenntnisse haben. Und auch diese profitieren von barrierefreier Informationstechnik, beispielsweise "Leichte Sprache". Sehbehinderte Nutzer haben bei Nutzen des Web-Angebots ganz andere Probleme als blinde Personen. Sie sind erst mal damit beschäftigt, ihren Maus-Cursor zu suchen. Arbeiten auf einer starken Vergrößerung der Seite oder auf einem ganz kleinen Abschnitt, weil sie eben nicht so gut sehen können, müssen diese ganze Website für sich kartografieren und sich die Position der einzelnen Elemente merken. Und auch viele ältere Menschen sind auf Vergrößerung, vergrößerte Texte und so weiter angewiesen sowie auf gute Kontraste. Und dann merkt man schon, was hinter diesem Begriff Design4All eigentlich steckt. Es gibt natürlich verschiedene Regelungen. Der Gesetzgeber hat auch schon verschiedene Regelungen erfasst und es gibt verschiedene Standards, an die man sich eben halten kann, um auf die Frage zurückzukommen. Und ab dem 1. März gibt es jetzt auch gerade für die BITV-Prüfung, wenn man sein Webangebot testen möchte, jetzt auch neue Prüfschritte, weil eine neue EU-Richtlinie mit einbezogen wird. Und wegweisend jetzt für die Zukunft hat auch der Gesetzgeber erkannt, dass das Thema sehr wichtig ist und hat jetzt auch eine neue Guideline sozusagen auf den Weg gebracht. Die European Accessibility Act, das ist die EAA, die wurde ins Leben gerufen und die soll dafür sorgen, dass das gesamte Internet insgesamt barrierefreier wird. Ansonsten kann man eben noch sagen, wenn man auf unser Gesetz wirklich schaut, da würde ich jetzt gar nicht so viele Paragraphen eingehen oder Paragraphen reiten. Wenn man jetzt diesen Begriff Design4All vor münzt auf ein Gesetz und da gibt es den Artikel 3 des Grundgesetzes, der besagt nämlich Niemand darf wegen seiner Behinderung benachteiligt werden. Und da sind wir eben genau bei diesem Begriff. Das Internet ist für alle gedacht. In dem Kontext kommt ja immer wieder das Stichwort UX auf. Wofür steht diese Abkürzung UX und was hat das eigentlich mit Barrierefreiheit zu tun? Ja, die User Experience beschreibt (die ist in Deutschland auch vernormt - also der Prozess - was UX eigentlich ist, ist ganz genau beschrieben) und bedeutet eigentlich das Nutzungs- erlebnis einer Software. Das heißt, ... Oder was heißt das eigentlich? Muss man sich vor Augen halten. Die User Experience bedeutet: Ich habe einen Gegenstand oder ein Produkt. Wir nehmen in unserem Fall wieder ein Webangebot und ich betrachte das vor der Nutzung, während der Nutzung und nach der Nutzung. Und dann spricht man von Userexperience, ein ganzes Nutzungserlebnis für alle zu schaffen. Jetzt kann man natürlich fragen, was hat denn UX mit Barrierefreiheit zu tun und wo liegen diese beiden Themen überhaupt aneinander? Während wir jetzt gerade hier miteinander sprechen, wird wahrscheinlich bei einem großen Versandhandel in einem Meeting jetzt gerade besprochen, welche Farbe und Position ein Werbebanner für die nächste Weihnachtsaktion eine höhere Conversionrate erzeugen wird. Aber worum sich in diesem Meeting wahrscheinlich jetzt gerade wieder keiner Gedanken machen wird, ob dieses ganze Webangebot, was zur Verfügung steht, überhaupt zugänglich für alle ist. Ganz oft wird außer Acht gelassen, auch mal darüber nachzudenken: Mensch, wer ist denn unsere Zielgruppe? Wir machen uns so viele Gedanken über eine gute Userexperience, über ein Nutzungserlebnis in unserem Onlineshop, vergessen aber die ganzen Nutzer, die dahinter stehen, für die das gar nicht zugänglich ist. Ich bin aber auch der klaren Meinung, dass man das Thema richtig und vernünftig angehen muss, um eben auch Angebote zugänglich zu schaffen. Es kann nicht sein, dass man sagt dieses Portal hat eine mega tolle UX. Weist das mit Labor-Probanden nach. Am Ende des Tages kann aber der über 60-Jährige nichts in diesem Shop bestellen oder der Sehbehinderte, weil es einfach schlichtweg nicht zugänglich ist. Und in dem Sinne kann man nicht von guter UX sprechen. Und aus diesem Grund sehe ich eher, dass die beiden Themen wirklich sehr nah beieinander gehören. Insbesondere ist Barrierefreiheit sehr nah an der Gebrauchstauglichkeit anzusiedeln. Denn auch in dieser Gebrauchstauglichkeit, die ja Teil der User Experience ist, beschreibt ja auch den Nutzungskontext, das Umfeld. Wie wird eine Software gerade bedient? Ein User muss wirklich seine Aufgabe effektiv, effizient und zufriedenstellend lösen können. Zeige nur das an, was er gerade braucht. Und das klingt schon alles genau nach all diesen Dingen, die auch die Barrierefreiheit umfasst. Nur eben mit dem Stern, dass es zugänglich für alle ist. Nun ist ja die Firma Quinscape ein IT-Dienstleister auch für den Mittelstand und die öffentliche Verwaltung. Warum ist das Thema für euch als Unternehmen ein wichtiges Thema? Was bringt euch und euren Kunden die Berücksichtigung dieser Aspekte in eurer Arbeit? Ja, das ist auch wieder eine spannende Frage. Bezogen auf das Unternehmen, es ist ein Unternehmen aus der Wirtschaft und in erster Linie wollen wir einfach diesen Vorteil, den wir hier bieten direkt an unsere Kunden weitergeben, da dort schließlich die Kosten eingespart werden können. Wir bringen halt diese Expertise mit. Die haben wir uns über ein Jahrzehnt angeeignet, auch an Erfahrungswerten. Und wir haben eben den Vorteil, dass wir diese Expertise in Form von einer Querschnittsabteilung in das Unternehmen integriert haben und das Wissen so in alle Projekte entlang des Unternehmens streuen können. In den Schwerpunkten von Quinscape wäre das der Bereich Data und Analytics, bei dem es darum geht, Erkenntnisse aus Daten zu ziehen. Datenqualität sicherzustellen, Daten zu bearbeiten und zu analysieren. So wie in dem Bereich des Software Engineerings, bei dem wir Kunden mit fertigen Plattformen beraten, auch im ÖV-Bereich. Und dort profitieren wirklich sämtliche Abteilungen und Kunden -Projekte von dieser Expertise. Wir hatten aber auch schon sehr viele Anfragen aus der Wirtschaft, sowohl für Apps, also aus der freien Wirtschaft, als auch zum Beispiel von einem sehr großen deutschen Pharmakonzern, dessen Portal wir in Kanada auf die dort geltenden BITV bzw. WCAG-Standards zu testen haben, um sicherzustellen, dass dieses barrierefrei ist. Was ist denn zu sagen zu der Aussage, eine barrierefreie Umsetzung sei aus technischen Gründen nicht möglich? Warum ist das nicht möglich? Und das ist dann zum einen eine Technologiefrage. Ist es eine Frage, wo ein Relaunch der Software gemacht wird? Hat man sich für die falsche Technologie entwickelt? Oder ich hatte auch jetzt vor kurzem noch mit einem Kunden ein Gespräch kann man sagen, wo es darum ging: "Das ist eine hochkomplexe Software, die nur über visuelle Dinge arbeitet, die uralt ist. Wie soll man die denn barrierefrei bekommen?" Und das Spannende ist an diesen Aussagen und damit will ich jetzt den Bogen auch schließen ist, dass diese Aussagen letztendlich immer die Menschen treffen, die eben keine BITV-Expertise vorzuweisen haben oder eben diese Klischee-Erfüllung eingehen und sagen ja, das ist nur für Blinde. Und deswegen frage ich dann immer gerne dieses: Warum? Ja, ein Blinder kann das gar nicht bedienen. Wie soll das überhaupt gehen? Und man ist sofort auf dieser Klischee-Ebene unterwegs. Und deswegen kann ich immer nur immer wieder appellieren, sich von einem Berater einmal beraten zu lassen, gegebenenfalls ein Sensibilisierung-Workshop. Dann bekommt man auch ein Gefühl für die Zielgruppe, dass man gemeinsam draufschaut. Wir bieten ja auch unterschiedliche Pakete an. Wir sind ja keine TÜV Prüfstelle, die sagt, wir gucken uns die Software an: "Das ist falsch. Das ist falsch, das ist falsch. Hier ist dein Prüfbericht und ab in der Werkstatt und repariert das jetzt." Sondern wir schauen uns das gemeinsam an. Wir haben technische Expertise in der Umsetzung. Wir Reden. Wir können Technik und wir gehen da gemeinsam ran und schauen, ob wir das hinbekommen. Und dann gibt es auch Wege, wie zum Beispiel ein POC, einen sogenannten Proof of Concept zu bauen. Das ist so eine Art Prototyp, um zu überprüfen, klappt das überhaupt so, wie wir wollen? Und dann zieht man wieder neue Erkenntnisse und so weiter und so fort. Ich halte es schlichtweg nicht für richtig zu sagen: "Das geht nicht." Wir sind schließlich auch zum Mars geflogen. Das ist ein guter Vergleich. Du hast selbst mal gesagt, in vielen Fällen ist nicht barrierefreies Design schlicht fehlerhaftes Design. Sprichst du damit genau diesen Themenbereich an? Ja, genau. Das geht schon in die gleiche Kerbe. Also im Grunde genommen das, was ich auch zu Anfang sagte, dass man einfach den Userexperience Gedanken einfach nicht verstanden hat. Es gibt da auch so viele praktische Beispiele, die man da benennen kann. Also setzt man sich beispielsweise heute in ein sehr modernes Fahrzeug, gibt es nur noch einen Touchscreen, ein Touch Display und um jetzt beispielsweise die Klimaanlage einzuschalten oder das Radio zu wechseln, da muss man auf diesen Touch Display in irgendwelche Untermenü gehen und dort eben Dinge machen. Während bei einem alten Fahrzeug hat man einen Drehregler und man kann drehen. Das bedeutet im Umkehrschluss, wenn der Beifahrer beispielsweise sehbehindert ist oder noch viel besser, man selber sitzt am Handy und checkt gerade die sozialen Medien, das Radio stört gerade, man möchte es leiser drehen, geht das nicht mehr intuitiv und das meine ich mit fehlerhaftes Design. Weil, wenn man an die Barrierefreiheit zumindest in diesem Fall ein bisschen gedacht hätte, dann würde das genauso möglich sein, das Radio leiser zu drehen, ohne seinen Blick vom Handy weg zu tun. Oder es würde auch eben den sehr schlecht sehenden Nutzer unterstützen über verschiedene Konzepte. Und das ist eben in die Kerbe, die das schlägt. Also nicht barrierefreies Design kann schön sein, aber dann muss man letztendlich sich auch immer die Frage stellen, ist es dann noch gut funktional. Wie sagte meine Oma damals: "Aus einem schönen Teller muss nicht immer alles schmecken." Ja, auch ein guter Vergleich. Du hast schon das Beispiel mit einem modernen Fahrzeug gebracht. Ich würde gern noch mal kommen auf das Thema Mobilität und in diesem Zusammenhang auf das Stichwort "mobile first". Ein Begriff "mobile first", zu dem du uns vielleicht kurz was sagen kannst und auch noch mal einen kleinen Blick darauf wirfst, was heute bei der Entwicklung moderner Software, die verfügbar sein muss, auf vielerlei Geräten, beachtet werden muss. Ja, sehr gerne. Das ist etwas, womit wir auch immer wieder konfrontiert werden, auch wenn wir in die Umsetzung gehen. Hier ist es eben auch wieder einfach nur wichtig, wenn man frühzeitig den richtigen Experten einbindet, geht es direkt in die richtige Richtung. Weil gerade, wenn mobile Geräte mit einbezogen werden müssen, wird es schon sehr kompliziert. Also beispielsweise der Nutzungskontext. Es gab mal einen Auftrag für einen größeren Hersteller, der eine App gebaut hat, wo die Bauern ihre Geräte auf dem Acker steuern. Und da gilt es (Sonneneinstrahlung): Alles was geht, also hohe Kontraste zu erzeugen. Muss gar kein schönes Design sein. Und dann betrachtet man auf jeden Fall erst mal den Nutzungskontext, bevor man sich überhaupt mit der Frage erst mal beschäftigt, machen wir mobile first oder nicht? Und wenn man dann irgendwann bei diesem Schritt tatsächlich ist, sind die Geister sehr, sehr geschieden, weil man hat früher immer gesagt: "Ja, mobile first, super wichtig. Man muss immer mit Mobile first anfangen, weil es die kleinste verfügbare Einheit ist." Und man ist automatisch gezwungen, die Informationen, die am wichtigsten sind, dort zusammenzufassen. Und dann geht man erst auf die große Variante, während das viele Belege und Artikel in der heutigen Welt auch ganz anders sehen. Und insofern macht es hier am meisten Sinn, wirklich zu betrachten, was ist denn Nutzungskontext? Was sind die User - also, dieser ganze Gedanke. Und wenn dann noch Barrierefreiheit dazukommen, muss man dann erst schauen, welchen Weg man wirklich geht. Es macht zum Beispiel überhaupt gar keinen Sinn für eine etwas komplexere Webanwendung, Stichwort B2B oder B2E, knallhart zu sagen "Nein, wir sind UX-ler, wir müssen jetzt Mobile first machen, weil das wird halt so gemacht." Das ist auch nicht der richtige Ansatz, sondern wirklich auf die Situation zielgenau auf den Kunden genau zu schauen. Was brauchen wir und wo soll die Reise eigentlich zukünftig hingehen? Und damit meine ich nicht bis zum Release, sondern damit meine ich noch viele, viele Schritte weiter. Was ist die Idee dieser App oder dieser Webanwendungen? Wo geht der Gedanke hin? Was ist das Ziel? Was soll man überhaupt damit erreichen? Und dann entscheidet man sich letztendlich über das Vorgehen und das ist halt auch so schade, dass sehr häufig viele Berater draußen dann sagen: "Ja, das ist das Vorgehen, was quasi suggeriert und postuliert wird. Und das müssen wir jetzt auch so machen, sonst stehen wir jetzt mal ganz doof uncool da." Ich habe gesehen, dass du auch ehrenamtlich dich engagierst. Mit BIT inklusive bist du im BITV Expertengremium, entwickelst mit neue Prüfverfahren und Standards im Bereich der digitalen Barrierefreiheit. Und ich würde gerne zum Abschluss noch mal von dir ganz persönlich hören, was auch die Zusammenarbeit mit Menschen mit Behinderungen für dich für eine Bedeutung hat. Seit dem Jahr, ich glaube seit kurz nachdem mal Photoshop erfunden wurde und seit dem Millenium beschäftige ich mich eigentlich damit, Oberflächen gut bedienbar zu machen. Und das Tolle: Ich hatte das wunderbare Glück bei der Quinscape GmbH, dass wir mit sehr breit gefächerten Branchen und Kunden - auch wirklich sehr großen Unternehmen, DAX 30 Konzerne stark im Automotive / Pharma Umfeld - wirklich sehr, sehr, sehr komplexe Prozesse in spannende Dialoge überführen, Konzepte dafür machen, damit Menschen da draußen ihre Arbeit besser erledigen können. Und das ist etwas, das fasziniert mich, motiviert mich und das finde ich halt super. Und die digitale Barrierefreiheit ist in meinen Augen auch sehr, sehr wichtig. Das Miteinander ist wirklich nochmal das i-Tüpfelchen, was obendrauf kommt. Und das finde ich halt klasse, weil das jetzt mit der Alterung der Gesellschaft noch mal sehr wichtig wird. Und gerade wenn man jetzt einen Onlineshop hat und um so eine Zielgruppe außer Acht lässt, dann wäre das schade. Ein weiteres Beispiel ist: Ich möchte auch mal irgendwann vor meiner Alexa oder was ich zu Hause habe, wenn ich in der Küche stehen, mir eine Internetseite vorlesen lassen. Und das ist das gleiche assistive System wie in Screenreader, den ein blinder Nutzer nutzt. Und das ist das, wo ich hin will. Die Welt irgendwie ein Stückchen cooler machen, moderner machen. Und deswegen habe ich mich da in diese Richtung verschrieben. Die Arbeit mit behinderten Menschen oder Menschen mit Behinderung ist mir sehr, sehr wichtig. Wir arbeiten ja auch mit oder sind im Austausch mit verschiedenen Vereinen, haben da den engen Draht, engagieren uns auch in verschiedenen Veranstaltungen. Das direkte Arbeiten von Menschen mit Behinderung im eigenen Unternehmen sehe ich eher neutral oder leistungsbezogen. Denn, warum sollte jetzt ein Mensch weniger gut sein, nur weil er farbenblind ist oder einen Arm weniger hat? In unserem Berufszweig der Informatik ist das alles gar nicht so wichtig. Das hängt auch ein bisschen mit der Informatiker-Kultur zusammen. Und ich möchte einfach mal einen Vergleich ziehen. Ich kenne unfassbar gute Programmierer, wirklich top Programmierer, die an den höchsten Positionen von Unternehmen arbeiten, die unfassbarsten Architekturen und Software-Systeme bauen und bereits mit 14 Jahren hochkomplexe mathematische Algorithmen für alte Konsolen und Computer gebaut haben, aber keinen Abschluss haben. Und in der Wirtschaft ist das ebenfalls ein Handicap. Und ich finde das ist so, als würde man Menschen einfach nur nach den Zeugnisnoten einstellen. Und wenn sich der Mensch in seiner Kompetenz für diese Stelle eignet und diese Aufgabe bestmöglich und hervorragend erledigen kann, dann herzlich willkommen! Christoph, ich bin ganz begeistert und freue mich darüber, dass wir ein so intensives Gespräch geführt haben. Du hast, wie ich finde, ein schönes Abschlusswort gefunden mit deinem persönlichen Statement. Und dafür bedanke ich mich ganz herzlich. Auch dafür, dass du unsere Hörerinnen und Hörer herangeführt hast an das Thema Design4All und barrierefreie Apps und insbesondere natürlich auch für deine persönliche Einstellung zu der Thematik. Ich freue mich, wenn wir vielleicht sogar noch mal eine Möglichkeit finden, in Zukunft hier auf diesem Kanal miteinander zu sprechen und sage Vielen Dank! Vielen Dank! Ich freue mich auch sehr, dass ich dabei sein durfte. Das Team von iDESkmu bedankt sich bei Sarah Matthies und Christoph Gesting für die Unterstützung des Projektes durch ihren Beitrag. Hier nochmals der Hinweis auf unsere Shownotes. Sie finden dort neben den Hintergrundinformationen zu unseren Gesprächspartnern grundsätzlich umfangreiche Quellenangaben und Tipps rund um die Beiträge und Themen dieser Episode. In der nächsten Episode spricht Wolfgang Haase mit Christiane Möller, Rechtsreferentin beim Deutschen Blinden- und Sehbehinderten Verband in Berlin, über Agenden und Vorhaben zur IT Barrierefreiheit, die sich in nationalen bzw. europäischen Gesetzen, Verordnungen und Vereinbarungen niederschlagen können. Im anschließenden Gespräch unterhalten sich Wolfgang Haase und unser Projektleiter Harald Hansen über die Themen Paradigmenwechsel, verstärkte Mitarbeiterbeteiligung und Corporate Social Responsibility, auch CSR abgekürzt. Wir freuen uns, wenn wir Ihr Interesse geweckt haben. Abonnieren Sie diesen Podcast und teilen Sie ihn mit Ihrem Netzwerk und folgen Sie uns auf Facebook und Twitter. Lernen Sie uns noch besser kennen und besuchen Sie uns auf unserer Website unter www.projekt-iDESkmu.de Sind Fragen offen geblieben oder haben sich neue Fragen für Sie ergeben? Dann senden Sie uns eine Nachricht. Wir freuen uns darauf. Das war die Episode 1 der Podcast Serie KLARTEXT FÜR IT OHNE BARRIEREN zu dem Projekt iDESkmu. Mein Name ist Nadia David. Vielen Dank für Ihr Hören.