Transcript
Stefanie Hallo und herzlich willkommen zum INNOQ Podcast. Heute mal wieder mit einer Ausgabe zum Thema Women in Tech. Ich habe heute nämlich eine liebe Kollegin hier zu Gast, die Joy. Hi Joy, schön, dass du heute da bist.
Joy Hallo!
Stefanie Joy, vor sehr, sehr langer Zeit hast du mal diesen einen Satz gesagt. “Ich hasse CSS”. Das war glaube ich sogar in den Vorstellungsgesprächen hier bei INNOQ, wenn ich richtig informiert bin. Steht der Satz heute noch so?
Joy Nein, der Satz steht nicht mehr so. Ich habe tatsächlich, als ich bei INNOQ angefangen habe und mich beworben habe, gesagt “Ich bin Backend Entwicklerin. Ich mache nur Backend. Ich mag CSS nicht, ich entwickle sehr gerne, aber bitte nichts mit diesem CSS-Kram da”.
Stefanie Und heute nennst du dich Full Stack Entwicklerin. Das heißt, da hat sich einiges getan in der Zwischenzeit. Warum sich das Blatt gewendet hat und wie es dazu kam, darüber sprechen wir heute. Außerdem, warum Themen wie Web Accessibility und Responsable Web Apps wichtige Themen für dich sind. Bevor wir damit starten, würde ich vorschlagen, du stellst dich einmal kurz vor, damit unsere Hörerinnen und Hörer wissen, mit wem sie es hier zu tun haben. Sag doch mal kurz, seit wann du bei INNOQ bist, was du bei uns schwerpunktmäßig machst. Schieß einfach mal los.
Joy Ich heiße Joy Heron. Ich bin bei INNOQ seit ungefähr sieben Jahren und bin Full Stack Entwicklerin. Und tatsächlich mache ich seit ein paar Jahren eher Schwerpunkt Frontend, Schwerpunkt Accessibility, Schwerpunkt CSS. Obwohl ich damit, wie ich schon angekündigt habe, nicht so angefangen habe.
Stefanie Genau. Lasst uns doch mal ganz kurz über deine Anfänge sprechen, wo du das jetzt schon so in den Ring geworfen hast. Wie bist du überhaupt in die IT gekommen? Und warum erst einmal dieser Schwerpunkt Backend Entwicklung?
Joy Tatsächlich bin ich über die sehr typischen Wege in Informatik gekommen. Mein Vater hat mir mit 16 gesagt “Ich glaube, Programmieren würde dir gefallen”. Und dann habe ich es ausprobiert. Und dann hat es mir tatsächlich sehr, sehr, sehr, sehr gut gefallen. Und ich habe im Anschluss Informatik studiert. Der Weg, wie ich dann da hinkam, ist sehr typisch. Ich habe so einen Bachelor gemacht, einen Master gemacht und dann habe ich angefangen zu arbeiten.
Stefanie War INNOQ gleich dein erster Job nach dem Studium?
Joy INNOQ war mein erster Job in der Industrie. Ich habe schon davor in der Uni gearbeitet und davor Software entwickelt, aber nicht während des Masters und nicht in der Industrie.
Stefanie Und mich interessiert natürlich die Entwicklung von einer reinen Backend Entwicklerin in Richtung Frontend Entwicklerin. Wie kam es dann dazu, dass du dich überhaupt mit CSS-Themen auseinandergesetzt hast und wie bist du dann kleben geblieben?
Joy Bei mir ist es so, ich fand persönlich CSS unglaublich frustrierend als Sprache. Wenn man aus der Backend-Ecke kommt, dann hat man das Gefühl, ich möchte alles kontrollieren. Ich möchte Pixel. Wenn ich so eine UI programmiere, ist meine Vorstellung: Ich möchte die volle Kontrolle darüber haben. Ich möchte wirklich pixelgenau sagen, wo etwas auf dem Bild gezeichnet wird. Und das darf sich auf keinen Fall ändern. Wenn man aber so anfängt, Webentwicklungen zu schreiben, kann man das eigentlich nicht. Zum einen ist es so, dass die Implementierungen in den unterschiedlichen Browsern so unterschiedlich sind. Das ist inzwischen ein bisschen besser geworden. Die Kompatibilität ist deutlich besser, als es vor sieben Jahren war. Dieser CSS ist gedanklich viel anders als eine imperative Programmiersprache. Und wenn man anfängt, CSS zu schreiben. Es gibt ein Comic davon. CSS sieht einfach aus, aber es löst nicht ein einfaches Problem und das ist Teil des Problems. Wenn man CSS anschaut, dann sieht die Syntax total einfach aus und da denkt man: Och, das ist die einfachste Programmiersprache, die ich je gelernt habe und dann schreibe ich einfach das runter. Alles gut. Aber wenn man das in der Praxis einsetzt, die Probleme, die CSS lösen soll, sind gar nicht komplex. Styling, Kompatibilität zwischen Browsern, die Unterstützung von User Präferenzen und die Präferenzen, die ich vorschlage. Und das dauert so eine sehr lange Zeit. Bei mir hat es eine Weile gedauert, bis ich so kapiert habe, dass es darum geht. Tatsächlich ist CSS so eine Sprache, wo man dem Browser Dinge vorschlägt. Ich hätte gerne, dass diese Seite so und so aussehen würde. Wir müssen dabei bewusst sein, dass wenn Benutzer so Präferenzen für sich eingestellt haben, dass deren Präferenzen eben Vorrang haben über meine. Ich bin nur der Entwickler von der Seite. Aber wenn jemand zum Beispiel eingestellt hat, dass die Fontgröße doppelt so groß ist, weil sie Sehschwächen haben, dann sollte ich das auf jeden Fall berücksichtigen und deren Präferenzen nicht überschreiben. Das ist tatsächlich sehr gut von CSS, es ist als Sprache konzipiert. Ich glaube, der Grund, warum ich hier hängengeblieben bin, eben mit den Frontend-Sachen, ist, dass es mir einfach nicht egal ist. Ich habe am Anfang gesagt, ich möchte eigentlich kein Frontend machen, aber wenn ich so eine UI anschaue und man entwickelt das wohl und dann macht man die Seite irgendwie ein bisschen kleiner und alles bricht zusammen und geht auseinander und es ist alles kaputt. Irgendwie ist es mir nicht egal, was da passiert. Mich interessiert schon sehr wie die End User von meiner Anwendung sind und wer sie sind, was sie tun, welches Problem möchten sie lösen? Wie werden sie tatsächlich mit meiner Software interagieren und wie kann ich deren Leben besser machen? Und weil das mir eben nicht egal war, habe ich dann letztendlich doch diese CSS-Aufgaben gemacht, weil ich wollte es einfach richtig machen und gut machen. Und letztendlich habe ich dann über die Zeit ein bisschen mehr über CSS gelernt und das wurde auch über die Zeit einfacher. Ich habe ein bisschen mehr gelernt, wie CSS konzipiert ist und wie man damit Dinge quasi gut entwickeln kann. Und das hat so ein bisschen länger gedauert, aber sobald ich das kapiert habe, hat es mir tatsächlich auch Spaß gemacht, CSS zu schreiben. Die Lernkurve war einfach viel größer, als ich gedacht habe.
Stefanie Ja, sehr cool. Es klingt auch so ein bisschen wie so ganz unterschiedliche Herangehensweisen bei Backend und Frontend Entwicklung. Also Backend klingt eher so nach Kontrolle. Ich gebe einen Code ein und es kommt dann eine bestimmte Sache X raus und bei CSS scheint das eher ein Vorschlag zu sein.
Joy genauso ist es. Tatsächlich gibt es auch im Backend unterschiedliche Paradigmen. Bei der Programmierung. Es gibt zum Beispiel imperative Programmierweisen, objektorientierte Programmierweisen, logische Programmiersprachen, funktionale Programmiersprachen. Die haben alle auch irgendwie Vor- und Nachteile. Man weiß als Backend Entwickler, dass es auch ein bisschen Zeit braucht, so umzudenken. Wenn man von Java, was eine objektorientierte Sprache ist, zu Closure wechselt. Closure ist eine funktionale Programmiersprache, erfordert es ein gewisses Umdenken und als Backend Entwickler habe ich damals auch schon geschätzt, ich wusste zum Beispiel, dass das Paradigma so anders war und dass es gut war, das versuchen zu lernen, weil man lernt dabei auch anders zu denken und der eigene Horizont wird erweitert. Auch wenn man weiterhin Java schreibt. Und bei CSS war es mir gar nicht bewusst, dass es ein komplett anderes Paradigma war. Dieses CSS sortiere ich tatsächlich in meinem Kopf als visuelles Paradigma. Irgendwie ist es etwas komplett anderes als Backend. Und ich glaube, das ist eine andere Sache, bei der Webentwicklung allgemein ist es so, wie du schon gesagt hast, Frontend Entwicklung allgemein, das ist nicht nur CSS, sondern auch HTML, CSS und gleichzeitiges JavaScript. Das ist tatsächlich immer so eine Sache, dass wir viel mehr Unsicherheit haben in der Frontend-Entwicklung, als wir es hätten, wenn wir zum Beispiel das Backend kontrollieren. Wenn wir das Backend schreiben, wissen wir meistens, in welcher Programmiersprache wir das schreiben. Wir wissen meistens, auf welcher Hardware das laufen wird, welche Datenbank verwendet wird und wir können da eine gewisse Kontrolle ausüben und die Variablen kleiner ziehen. Aber mit Frontend können wir eigentlich nicht sagen, welcher Browser verwendet wird, um diese Anwendung zu öffnen. Welche Einstellungen hat der Benutzer so eingestellt? Haben sie Daten aktiviert auf dem Betriebssystem oder Light Mode? Oder haben Sie irgendetwas anderes? Verwenden Sie so ein Screenreader, um mit der Webseite zu interagieren? Wir wissen das einfach gar nicht. Das ist der Vorteil von Web, dass wir quasi etwas zur Verfügung stellen können, wo sehr viele unterschiedliche User Agents darauf zugreifen können. Sehr viele unterschiedliche Browser, sehr viele unterschiedliche assistierende Technologien. Die können alle mit dem gleichen Code interagieren. Eigentlich ist das eine der großen Vorteile von Web und von Frontend. Aber das bringt so eine gewisse Schwierigkeit mit sich, außer, wenn man das wirklich gründlich in allen unterschiedlichen Browsern testet und mit allen unterschiedlichen assistierenden Technologien. Dann weiß man nicht, dass das wirklich 100 % für alle funktioniert.
Stefanie Da muss man sich vermutlich erst mal darauf einlassen. Gab es für dich denn so einen Aha-Moment, wo es Klick gemacht hat oder ist das einfach ein Prozess gewesen?
Joy Ich glaube, es gab ein paar Aha-Momente. Ich glaube, als ich angefangen habe. Das ist ein bisschen dieser Gedanke, man sagt jetzt Mobile first. Aber wenn man anfängt, eine Anwendung zu schreiben und damals habe ich angefangen und habe so versucht, ein Layout auf Desktop zu bauen. Und dann habe ich versucht, CSS zu schreiben, damit, wenn ich die Seite so schrumpfe, dass es noch gut aussieht. Ich habe ein sehr inflexibles Layout implementiert für Desktop Devices. Und dann habe ich das kleiner gezogen und dann ist jedes Mal irgendwie eine von den Eingabefeldern aus dem Rand ausgerückt und es sah schlecht aus und es hat nicht das getan, was ich gewollt habe. Ich habe einen Kollege gefragt: Wie kann man das besser machen? Und er hat mir dann das mit Mobile first erklärt. Eigentlich fängt man mit der Mobilvariante zuerst an und man implementiert quasi das einfache Layout auf kleinen Bildschirmen. Meistens, zum Beispiel bei einem Formular wären alle Eingabefelder übereinander und wenn man das Feld vergrößert sieht, kann man das Layout so anpassen, damit Dinge dann nebeneinander zu rücken. Und das funktioniert eigentlich sehr gut, wenn man es in der Richtung macht. Wenn man es in eine andere Richtung macht, ist es sehr fehleranfällig und schmerzhaft. Das ist zum Beispiel einer von diesen Aha-Momenten. Da habe ich gesagt: Okay, zuerst kleine Devices betrachten, dann größere Devices betrachten und man lernt auch. Ich glaube, das war der größte Aha-Moment. Und dann einfach dieser Punkt, wenn man endlich zugibt, dass man die Kontrolle nicht hat. Wenn man glaubt, dass man die Kontrolle erzwingen kann, wird man mit CSS-Mitteln eigentlich immer ziemlich unzufrieden sein. Aber sobald man sich darauf einlässt: Die Größe des Viewports wird sich immer ändern und ich muss mich immer darauf einstellen. Ich muss einen Weg finden, damit umzugehen, anstatt dagegen zu kämpfen und das ist so ein Switch, den man auf jeden Fall machen muss, ansonsten ist man einfach immer frustriert.
Stefanie Mut zur Unsicherheit.
Joy Genau.
Stefanie Du hast das jetzt paar Mal in so einem Halbsatz fallen lassen. CSS ist eine Sprache. Ist CSS denn eine Programmiersprache?
Joy Ja, es gibt einige Menschen, die behaupten, CSS sei keine Programmiersprache. Ich weiß nicht, was genau die Motivation dahinter ist. Es ist eine Sprache, die wir schreiben, in einer Datei speichern und die von einem Computer interpretiert wird. In diesem Fall ist der Interpreter tatsächlich der Browser, der die Sprache interpretiert. Es gibt mehrere Implementierungen davon, wie dieses CSS interpretiert wird. Aber das ist für mich die Definition einer Programmiersprache. Es ist eine Sprache, die ein Mensch schreibt, um dem Computer Befehle zu geben, wie er etwas zu tun hat. Und ich weiß nicht, vielleicht kommt es auch aus dieser Ecke. Wenn man sagen würde, eine Programmiersprache sei etwas, wo ich es runter kompiliere in ein Programm, der von dem Computer ausgeführt wird, dann ist es ein bisschen schwammig, aber es gibt auch sehr viele andere Programmiersprachen, die auch interpretiert werden. Zum Beispiel Java ist eine interpretierte Programmiersprache bzw. zumindest der JBM. Man kompiliert es nicht zu Byte-Code, sondern zu JBM-Code. Aber zum Beispiel JavaScript, serverseitiger JavaScript. Node.js ist auch interpretiert, auch Python, Ruby. Es gibt sehr viele Programmiersprachen, die interpretiert sind und das ist kein Ausschlusskriterium, dass sie Programmiersprachen sind. Es ist nur so ein bisschen anders, in dem Fall von CSS, dass der Interpreter in dem Fall der Browser ist. Deswegen ist er ein bisschen anders formuliert und es gibt auch die Kombination von CSS und HTML ist auch turing-complete. Insofern ist es egal, welche Definition jemand verwendet, um eine Programmiersprache zu definieren, glaube ich, ist CSS eigentlich eindeutig eine Programmiersprache.
Stefanie Hat das auch so ein bisschen mit Gatekeeping zu tun? Backend versus Frontend?
Joy Ja, das ist mein Gefühl. Das ist wie: Eine Programmiersprache ist wertvoller als eine Nicht-Programmiersprache. Und theoretisch könnte man jemandem mehr Geld bezahlen, wenn sie Java machen, als wenn sie CSS machen. Ich glaube, in der Regel ist es auch tatsächlich so, dass Arbeit mit HTML und CSS weniger gut bezahlt wird als Jobs, die Jaca oder JavaScript machen. Aber ich könnte da auch Unrecht haben. Das ist auch mein Gefühl. Ich finde das immer so spannend, dass Frontend verachtet wird. Und dann kommt man zu einem Projekt und sagt: Ich mache gerne CSS und UI und alle freuen sich so sehr, weil sie es einfach nicht machen wollen. Also nicht alle, aber es ist mir immer so passiert, dass in jedem Projekt, wo ich reingegangen bin, auch wenn ich nicht von Anfang an gesagt habe, ich möchte unbedingt die CSS machen. Letztendlich mache das, weil das nicht so die beliebteste Aufgabe ist und es oft sehr geschätzt wird, wenn man tatsächlich im Projekt mitarbeitet. Diese Fähigkeit wird sehr geschätzt. Aber die Außendarstellung wird weniger wertgeschätzt, als wenn man so Kubernetes kann oder eine Backend-Programmiersprache. Das wird als hochwertiger erachtet als die Frontend-Tätigkeiten. Ich glaube, sie sind aber genauso wichtig.
Stefanie Das ist interessant, weil für mich klingt das so, dass diese Frontend Arbeit auch viel mit dem Nutzer zu tun hat, der am Ende, das die Software nutzen soll. Und eigentlich machen wir doch Software für die Nutzenden, richtig?
Joy Man würde hoffen, dass man das tun würde. Ich glaube tatsächlich, dass die User Experience und die Benutzbarkeit von einer Software tatsächlich komplett durch die ganze Anwendung durchdrängt. Von Datenbank bis hin zu Frontend. Und tatsächlich ist es sehr schwierig. Wenn man auf UI Ebene Dinge reparieren muss, die auf Backend Ebene kaputt sind, damit man den Benutzer zufriedenstellen kann, dann weiß man, dass etwas nicht stimmt. Tatsächlich bei der Softwareentwicklung allgemein inklusive Backend ist meiner Meinung nach die Notwendigkeit, immer auf den Benutzern Acht zu haben. Aber es stimmt schon, wenn man sich nur auf das Backend konzentriert, sind die Benutzer meistens ein bisschen weiter weg. So eine Jason API mit Usern zu testen, geht gar nicht. Wenn man Software so bauen würde, das ist ein anderes Thema, aber da hat man so diese Brücke zwischen den Entwickler und den Usern und das sollte eigentlich nicht so sein. Meiner Meinung nach sollte man immer das Softwarestück als Ganzes betrachten und eigentlich haben alle im Team, auch die Backend-Entwickler, die Verantwortung dafür sicherzustellen, dass es für den User gut funktioniert.
Stefanie Ich halte fest, wenn man Full Stack entwickeln kann, sowohl Backend als auch Frontend, ist man sehr beliebt in Projekten, weil man beides machen kann.
Joy Ich glaube, es ist eine gute Sache. Ich glaube, tatsächlich es ist wichtig, dass das Team Full Stack ist und dass man das integriert im Team. Und ich glaube, es ist gut, beide Sachen zu beherrschen tatsächlich, damit man besser kommunizieren kann mit allen im Team, was die Bedürfnisse sind und die Notwendigkeit ist. Da hilft die Zusammenarbeit tatsächlich sehr viel, wenn man das kann.
Stefanie Was macht denn deiner Meinung nach eine gute Webanwendung aus?
Joy Meiner Meinung nach muss die Webanwendung die Probleme der Benutzer lösen. Das ist das, was im Mittelpunkt steht. Und zwar alle Benutzer, nicht unbedingt der Benutzer, der genauso wie ich ist, der mit einem teuren Laptop die Anwendung bedient oder mit einem teuren iPhone die Anwendung bedient, sondern ich darf nicht davon ausgehen, dass sie unbedingt teure Hardware haben. Ich darf nicht unbedingt davon ausgehen, dass sie mit der Maus navigieren. Vielleicht haben Sie eine Beschwerde in der Hand und müssen mit so einer Tastatur navigieren. Das wird auf jeden Fall machbar sein. Vielleicht haben sie gewisse Beeinträchtigungen, weswegen sie assistierende Technologien wie ein Screenreader verwenden müssen. Das sollen wir einfach irgendwie immer betrachten, dass die Benutzergruppe, die wir haben, nicht so eine Gruppe von Menschen ist, die genau gleich aussieht, sondern es ist immer eine Gruppe von unterschiedlichen Menschen mit unterschiedlichen Fertigkeiten und Fähigkeiten. Und ich kann quasi diese Brille anziehen. Als Entwickler kann ich versuchen mehrere Brillen anzuziehen und versuchen mich in den Schuhen von den anderen zu setzen und sagen: Wenn ich jetzt die Anwendung aus der Perspektive von jemandem betrachte, der gerade blind ist, wie würde ich mit der Anwendung interagieren? Und das so testen. Auch nicht sowas vergessen wie kognitive Einschränkungen. Wenn jemand irgendwie kognitive Einschränkungen hätte, dann möchte ich auch, dass sie diese Anwendung verwenden können und nicht irgendwie verwirrt werden. Und wenn ich das so mache und das aus unterschiedlichem Blickwinkel betrachte und diese unterschiedlichen Brillen immer wieder anziehe und die Anbindung an die unterschiedlichen Brillen und verbessere, dann kann ich am Ende sicher sein, dass die Anwendung für mehr Benutzer verwendbar ist als davor.
Stefanie Das klingt total komplex. Es gibt wahrscheinlich 1003 verschiedene Arten von Beeinträchtigungen. Wie wird man denen allen gerecht?
Joy Es gibt sehr viele unterschiedliche Arten von Beeinträchtigungen. Es gibt so eine Sache, zum Beispiel, wenn man assistierende Technologien braucht. Es gibt schon so eine Abstraktion unterhalb. Zum Beispiel, wenn jemand blind ist und ein Screenreader verwenden muss, die verwenden unter der Haube, der Screenreader verwendet, das nennt sich Accessibility Tree und das ist so eine Abstraktion von der tatsächlichen Anwendung, womit sie interagieren. Und wenn ich das zum Beispiel mit Screenreader teste, dann kann ich ziemlich sicher, nicht unbedingt sicher sein. Eigentlich müsste man die Benutzergruppe fragen und auch quasi die bitten, die Anwendung zu testen. Das ist eigentlich das, was man machen muss, aber wenn man den Screenreader zum Beispiel verwenden kann und die Anwendung verwenden kann, dann habe ich zumindest ein besseres Gefühl, dass das gut für andere assistierende Technologien verwendet werden soll. Und wie gesagt, es gibt natürlich sehr viele unterschiedliche Beeinträchtigungen, aber ich betrachte das persönlich durch unterschiedliche Brillen, die ich anziehe. Ich ziehe die Brille von Screenreader Verwendungen an, ich ziehe die Brille von Tastaturverwendungen an, ich ziehe die Brille von Menschen mit Bedürfnissen nach Kontrast. Menschen, die einen Zoom beim Bildschirm brauchen, damit sie sich auf etwas konzentrieren können. Menschen, die eventuell Probleme mit bestimmten Farben haben. Es gibt unterschiedliche Dinge, die man lernen und dann versuchen kann: Ich mache mir so eine Liste und ich versuche dann diese Anwendungen in dem Fall mit dieser Brille zu betrachten, damit ich dann sicherstellen kann, dass diese Person eventuell damit klarkommt. Und eigentlich, wenn man das tut, kommt man ziemlich weit, dass man sicherstellen kann, dass das so zumindest einigermaßen für die Benutzer funktioniert. Letztendlich muss man das nachher so testen, mit Nutzern. Das ist der letzte Schritt. Aber wenn man zum Beispiel selber die Anwendung nicht mit einem Screenreader getestet hat. Es könnte sein, dass ich das einfach mit so vielen Barrieren gebaut habe, dass sie überhaupt nichts mit der Anwendung etwas anfangen können. Und da ist schon was anderes, wenn ich mir schon Gedanken gemacht habe, schon selber getestet habe. Da glaube ich zumindest, dass alle Sachen, die ich brauche, erreichbar sind für Screenreader. Das ist schon ein guter Schritt. Und dann kann man im zweiten Schritt nach Feedback fragen und das integrieren: Ich habe das gebaut, es ist irgendwie erreichbar, aber es ist noch nicht optimal. Und wenn man das Feedback bekommt, kann man die Anwendungen anpassen, damit es besser verwendbar ist, wenn man dieses Feedback bekommt. Letztendlich geht es darum, erstens nach Feedback zu fragen und zweitens dieses Feedback so weit wie möglich schnell einzubauen. Wenn man das tut, man geht nicht davon aus, dass man von Anfang eine Anwendung hat, die für alle die beste Anwendung der Welt ist. Aber eigentlich ist es ein interaktiver Prozess, wenn man nach Feedback fragt und mit den Benutzern ständig im Gespräch mit denen ist, dann kann man so was bauen, was wirklich gut verwendbar ist über die Zeit, wenn man das Feedback bekommt und das einbaut.
Stefanie Wenn man sich jetzt als Entwickler oder Entwicklerin informieren möchte und überhaupt einen Ausgangspunkt haben möchte? Was wäre denn so eine gute Informationsquelle, um da loszulegen?
Joy Ich hatte vor kurzem eine neue Präsentation bzw. Microsite entwickelt. Ich weiß nicht mehr, was der Titel war, aber da hatte ich zum Beispiel die Punkte aufgelistet, die ich verwende, wenn ich mit der Webentwicklung anfange. Und das ist natürlich nicht vollständig. Tatsächlich finde ich den Weg allgemein mit der Anwendung anzufangen und ich glaube, der beste Weg ist es mit zwei Dingen anzufangen. Einmal mit Screenreader-Tests anzufangen und einmal mit Tastatur-Tests. Und da ist definitiv nicht alle eingeschlossen. Da gibt es ein paar andere Dinge, die man eigentlich betrachten muss, wenn man eine Anwendung implementiert. Aber das ist so der Schritt, wie man anfängt zu testen. Wenn man sicherstellen kann, dass es mit der Tastatur funktioniert und mit Screenreader funktioniert, würde man schon ziemlich viel lernen und dann näherkommen und den Fuß durch die Tür durchkriegen.
Stefanie Ganz generell, es gibt schon so ein paar Prinzipien, Web Accessibility, BCAG-Richtlinien. Zum Beispiel. Das lohnt sich wahrscheinlich, da mal reinzuschauen.
Joy WCAG, wie du gesagt hast, das sind diese Richtlinien, die gesetzlich notwendig sind. Das muss einem bewusst sein. Ich als Entwicklerin konnte nicht so viel damit anfangen, weil ich mich überwältigt gefühlt habe. Eigentlich alles, was man mit dem WCAG so bedecken muss. Das musst du können, das stimmt. Und es gibt auch so ein paar Accessibility Tools sowie Wave Accessibility Tool, für die das testet und die dabei unterstützen. Und letztendlich haben wir tatsächlich die Verpflichtung, all diese Punkte zu befüllen. Aber für mich als Entwickler ist es nicht so einfach, mit den Guidelines anzufangen. Was ich meine ist, wenn man diese Stichpunkte von oben nach unten durchliest, ist es immer schwierig für mich, die anzuwenden an dem Problem, was ich aktuell habe. Deswegen mache ich das eher so, dass ich zuerst betrachte: Was habe ich für eine Anwendung? Und dann schaue ich, eventuell mithilfe von einem dieser Tools, welche der Sachen verletze ich gerade? Und so kann ich mich orientieren an den Anforderungen. Ich glaube eine von denen, die WK3 ist tatsächlich in Arbeit und ich glaube einer der Ziele von der WK3 ist, glaube ich tatsächlich so gebaut, damit sie auch einfacher zu verstehen ist von Anfang an und das finde ich eigentlich super. Tatsächlich versucht dieses WK3 barrierefreier auch für die Entwickler und für die Tester sein.
Stefanie Genau. Du hast selbst auch so eine Ressourcensammlung ins Netz gestellt. Unter responsibleweb.app. Kann man natürlich auch verlinken. Erzähl doch mal, was man da findet.
Joy Das ist, das ist das, was ich vorher erwähnt habe. Ich habe im Wesentlichen eine Checkliste von den Dingen, die ich immer mache, zusammengestellt. Und es ist auf keinem Fall vollständig und das habe ich auch nicht das Ziel, dass es vollständig sei. Es ist mehr dieser Gedanke, Fuß durch die Tür. Wie kann man damit anfangen? Und ich habe dann die Dinge aufgelistet. Es heißt Responsible Web Applications, weil es eine Kombination von responsive und accessible ist, also responsible. Und da sind einige Punkte, die man anwenden kann, um die Responsiveness und die Barrierefreiheit von der Website zu verbessern.
Stefanie Ich finde das übrigens ein sehr schönes Wortspiel.
Joy Genau, es ist leider aus Versehen passiert. Ich wollte soeben einen Vortrag über responsive und accessible Web Applications machen und als ich versucht habe, responsive und accessible Web Application zu sagen, kam es so irgendwie responsible Web Application raus und es hat dann gepasst. Ich wünschte, dass es absichtlich gewesen wäre.
Stefanie Du hättest es jetzt anders verkaufen können. Aber trotzdem sehr schönes Wortspiel. Web accessibility, ist das eigentlich eine Sache, die von Kunden aktiv nachgefragt wird? ‘Bau mir eine barrierefreie Web-Anwendung’ oder ist das eher Aufgabe der Entwickelnden, das als Standard quasi mitzudenken?
Joy Es gibt tatsächlich eine gesetzliche Verpflichtung, die Barrierefreiheit von Webseiten sicherzustellen.
Stefanie Ab 2025 müssen Websites barrierefrei sein. Aber es gibt auch jahrelange Übergangsfristen. So ganz hart scheint mir das nicht zu sein.
Joy Ja, aber ich meine, irgendwann wird es sein, dass es diese Verpflichtung gibt. Und ich glaube, es gibt schon eine Verpflichtung, dass wenn jemand eine Beeinträchtigung hat, dass die Firma zumindest die Person ermöglicht, das Gleiche zu tun. Im Sinne von Gleichberechtigung glaube ich, dass das schon eine Verpflichtung ist. Ist das gesetzlich gefordert? Ich weiß es nicht.
Stefanie Als interne Anwendung, dass alle Mitarbeitenden das nutzen müssen. Ich glaube, das ist schon eine Verpflichtung.
Joy Ich glaube auch. Da gibt es schon auf jeden Fall so eine Verpflichtung. Und dann wird es eine Verpflichtung geben, dass alles barrierefrei ist. Ich glaube aber, dass Entwickler sich mit dem Thema näher beschäftigen sollen, wenn man die Dinge gelernt hat, die man unbedingt vermeiden soll, ist es nicht unbedingt schwieriger eine Web-Anwendung, die barrierearm ist zu bauen. Oft fehlt einfach das Wissen oder die Motivation. Deine Frage war: wird das immer angefragt? Leider ist das oft nicht in den Anforderungen, dass etwas barrierefrei ist, aber es ist auch oft nicht in den Anforderungen, dass es responsive ist und dass es auf unterschiedlichen Geräten funktioniert ist auch oft nicht. Ich finde, das ist einer von diesen Punkten, die immer interessant ist. Ich verstehe den Wunsch von den Kunden. Sie haben ein limitiertes Budget, dann streichen wir Features, damit wir irgendwie damit klarkommen. Aber ich versuche einfach dann den Kunden immer zu erklären, das ist einfach die Wahrheit. Diese Dinge wie Responsiveness oder Accessibility sind nicht Dinge, die man einfach nachher so dran klatschen kann, in der Hoffnung dann alle Probleme der Welt zu lösen. Sondern wenn man das von Anfang an betrachtet, kostet das vielleicht ein bisschen mehr mit der Umschulung von den Entwicklern, die das noch nicht können. Es kostet vielleicht ein bisschen mehr mit dem Testen von den Anwendungen, weil man das auch auf unterschiedlichen Geräten versuchen musst. Aber die Implementierung ist dann nachher, wenn man das nachher einbauen möchte, ist das deutlich teurer, deutlich aufwendiger, als wenn man das einfach von Anfang an betrachtet. Das ist der Grund. Wenn ich etwas für Kunden baue, dann mache ich das einfach von Anfang an und betrachte diese Aspekte. Nicht, dass es unbedingt schon auf Accessibility optimiert ist. Aber es funktioniert. Das ist immer mein Anspruch. Es sollte immer funktionieren und auf eine Art und Weise gebaut werden, damit ich das im Nachgang anpassen kann und verbessern kann. Und ich baue nie etwas, wenn ich weiß, dass es grundsätzliche Probleme mit Accessibility hat. Und wenn man da Accessibility dran pflanzen müsste, müsste man das ganze Ding wegwerfen und neu bauen. Sowas baue ich einfach nicht. Und ich glaube, wenn man gelernt hat, das richtig zu bauen, dann wird man feststellen, dass es eigentlich nicht so schwierig ist.
Stefanie Es halten sich so ein paar Vorurteile gegenüber Web Accessibility oder Mythen, könnte man auch sagen oder zu teuer. Das hast du gerade schon angesprochen, aber zum Beispiel auch: Ist nicht relevant für meine Zielgruppe oder Accessibility bedeutet immer ein schlechtes Design. Ist daran was dran?
Joy Der letzte Punkt finde ich überhaupt nicht, dass Accessibility unbedingt ein schlechtes Design hat. Das finde ich eigentlich überhaupt nicht. Ich glaube, da müssen wir einfach den Designer so ein bisschen auffordern und denen auch beibringen, was sind die Dinge, die wir berücksichtigen müssen? Wenn man allgemein Webseiten baut, ist es so, dass es zum Beispiel viel besser für alle Benutzer ist, wenn Dinge so wirklich schriftlich draufgeschrieben sind. Wenn man nicht zum Beispiel eine Bildsprache, eine Icon-Sprache verwendet, die eventuell schlecht für unterschiedliche Benutzer verwendbar ist. Die Benutzer müssen dann zum Beispiel lernen: Was bedeutet dieses Icon in dieser Anwendung? Und eigentlich ist es besser, wenn man den Designern im Voraus sagen können: Wir wollen immer ein Icon in Verbindung, also eine textuelle Beschreibung von der Schaltfläche verwenden, weil das einfach besser bedienbar ist für alle Benutzer. Und wenn man das hat und die Designer das wissen und die das tun und das integrieren, dann ist das, was rauskommt. Es gibt keine Anforderung, dass das hässlich ist. Wenn die Designer gut sind, werden sie wahrscheinlich das gut einbauen können und gut integrieren können. Ich glaube, bei ein paar Sachen ist schwierig, wenn Dinge, die supertoll aussehen und grundsätzliche Probleme mit der Barrierefreiheit haben, zum Beispiel Animationen. Es gibt zum Beispiel dieses Parallax, eine Animation, wenn man durch eine Website scrollt und die Teile der Website irgendwie auseinandergehen oder sich sehr komisch bewegen auf der Seite, könnten viele Menschen übel werden dadurch. Es könnte sogar sein, dass sie eine Epilepsie haben und da sie könnten dadurch getriggert werden. Es ist eine sehr ernste Sache. Ich sage grundsätzlich, man sollte solche Animationen gar nicht verwenden, weil die sehr viele Probleme mit Accessibility haben und es gibt Wege, wie man die ausschaltet. Es gibt zum Beispiel CSS Media Queries, wo wir fragen können. Der Benutzer kann einstellen: Prefers reduced motion und dann können wir einstellen, dass diese Animation nur für Benutzer eingestellt sind, die diese Präferenz nicht haben. Das ist eine Sache, wo ich sagen würde, das sollten wir nicht tun, weil wir nicht sicherstellen können, dass der Benutzer, der das Problem hat, auf einem anderen Rechner unterwegs ist, wo wir diese Einstellung nicht einschalten können und dadurch leiden. Sowas lehne ich grundsätzlich ab, sage ich mal so, aber ich finde man kann auch lernen, zum Beispiel kleinere Animationen, die vielleicht nicht den großen Effekt hätten. Die könnten wir zum Beispiel hinter diese Prefers reduced motion stecken, damit wir ein bisschen Animation einbauen, aber nicht diese große Animation, die Menschen sehr schlecht beeinflussen können.
Stefanie Was ist denn deiner Meinung nach das Hauptargument für Accessibility? Um das mal positiv zu formulieren. Klar, es gibt gesetzliche Richtlinien, man muss das machen. Aber einfach so proaktiv. Was ist denn das Hauptargument, das umzusetzen?
Joy Ja, das Hauptargument ist, dass man Menschen damit wirklich einschließt. Das ist meine Meinung. Darum geht es. Eigentlich geht es bei mir gar nicht darum, alle Anforderungen zu erfüllen. Ich kann glauben, dass jemand theoretisch in der Lage wäre, die alle zu erfüllen und trotzdem eine Software zur Verfügung zu stellen, die für den Benutzer super schlecht ist. Deswegen ist es wichtig, wie ich gesagt habe, die alle zu erfüllen, aber im Mittelpunkt steht bei mir immer der Benutzer. Ich fange mit dem Benutzer an, ich stelle sicher, dass das für alle die Benutzer, ich meine alle die Benutzer in meiner Benutzergruppe ist schwierig, aber zumindest mit genug Menschen reden, dass ich das Gefühl habe, dass die Menge von Menschen insgesamt gut unterstützt wird. Und auch diese Frage nach dieser Bitte. Diese Bitte, wenn ich etwas kaputt gemacht habe, bitte sage mir Bescheid. Ich mache dir kein Versprechen, dass ich das von Anfang an so wirklich alles 100%ig richtig mache. Ich weiß, dass ich da wahrscheinlich einiges noch nicht so optimal gemacht habe. Ich bin offen für Feedback und ich möchte das wirklich im Laufe der Zeit verbessern. Und ich glaube, dann kann man die Menschen wirklich einschließen. Ich finde es immer so schwierig. Wir haben die Möglichkeit, mehr Menschen Dinge zur Verfügung. Wir haben mit dem Web eigentlich die Möglichkeit bei mehr Sachen die Barrieren runterzunehmen für Menschen, die ansonsten nicht die Möglichkeit hätten etwas zu tun. Und ich finde es immer sehr schwierig, wenn wir einfach künstlich diese Barrieren wieder aufbauen, weil wir keine Zeit oder keine Lust haben.
Stefanie Genau, das hast du auch praktisch schon mehrfach umgesetzt. Zum Beispiel auch bei einer internen Anwendung, die du für INNOQ mitentwickelt hast. Spacy. Erzähl doch mal, was es damit auf sich hat und warum ihr das überhaupt entwickelt habt.
Joy Genau, das war so ein Punkt. Es geht in eine ähnliche Richtung. Wir haben einen Kollegen bei uns, der sehbeeinträchtigt ist und einen Screenreader verwendet. Als Corona angefangen hat, htten wir sehr oft so Open Spaces. Das ist, wo alle Teilnehmer an dem Event zusammenkommen und die dürfen alle irgendwie ihre Sessions vorschlagen. Und dann gestalten wir zusammen das Programm für unser Event. Das ist tatsächlich eine Sache, die grundsätzlich auch in der physischen Welt für jemanden, der sehbeeinträchtigt ist, nicht accessible ist. Man kann das auf so ein Post-it schreiben und das an eine Tafel kleben. Aber das ist für jemanden, der nicht sehen kann, auch nicht accessible.
Stefanie Tatsächlich nutzen wir Spacy auch noch heute, wo wir wieder zu Vor-Ort Events zurückgekehrt sind, weil es dann Andreas, unser Kollege, mit einschließt.
Joy Genau. Und das sah ich als Gelegenheit. Wir haben jetzt eine Gelegenheit, etwas zu machen, was in der physischen Welt nicht accessible ist, das ins Web reinzubringen. Wir können eine Anwendung bauen, die ist ziemlich klein und es ist nicht so eine riesige Anwendung. Aber die Idee dahinter ist, dass wir genau das abbilden, was wir in einem Vorort-Event machen würden. Diese Tafel ist so eine Webseite und man kann da einen Session-Vorschlag eintragen und wird in der Liste zugeordnet. Und alle Benutzer in der Liste können eins nach dem anderen ihre Session auf der Tafel platzieren. Und das habe ich genauso, wie ich erzählt habe. Ich habe das versucht, nach bestem Wissen und Gewissen barrierefrei zu machen. Accessible first und dann im Nachgang durch das Testen kam raus, dass es nicht optimal gewesen ist. Und dann habe ich durch das Feedback viel gelernt und auch viel umsetzen können, um das noch besser zu gestalten. Und das sollte auch für jeden, der daran teilnimmt, gut verwendbar sein.
Stefanie Ja, es ist auf jeden Fall auch für sehende Menschen sehr einfach und intuitiv zu bedienen. Das kann ich bestätigen. Wir haben dazu auch eine kleine Case Study gemacht. Das heißt, wenn man ein bisschen nachlesen möchte, wie das entstanden ist und was da auch im Backend passiert, kann das dann nachlesen. Und zum Abschluss wollte ich dann noch mal ein Zitat daraus vorlesen tatsächlich, was ich total cool und passend zu diesem Podcast finde. Und zwar hast du mal gesagt “Als Entwicklerinnen haben wir die Pflicht, Webanwendungen zu schreiben, die für alle Menschen accessible sind. Immerhin befinden wir uns im Web. Es ist möglich, barrierefreie Anwendungen zu schreiben. Warum tun wir es nicht einfach?” Das ist auf den Punkt gebracht und eigentlich ein ganz schönes Schlusswort für diesen Podcast. Joy, vielen Dank, dass du heute mit mir hier gesprochen hast, im Rahmen dieses Podcast. Ich fand es super spannend. Ich hoffe, unseren Zuhörerinnen und Zuhörern hat es auch gefallen. Wenn ihr uns Feedback geben möchtet oder Fragen habt, [email protected] ist unsere E-Mail-Adresse. Und ansonsten sage ich: Vielen Dank und bis zum nächsten Mal. Tschüss.
Joy Tschüss.