dl041: barrierearme datenvisualisierung

dl041: barrierearme datenvisualisierung

In dieser Folge geht es endlich mal wieder um Datenvisualisierung. Wir haben uns die Frage gestellt, wie visualisierte Daten möglichst barrierearm zur Verfügung gestellt werden können. Dafür haben wir uns mit Anne-Victoria Meyer (Anvi) unterhalten. Sie hat sich in ihrer Masterarbeit intensiv mit diesem Thema beschäftigt – und zwar aus der Perspektive einer Webentwicklerin. Dabei hat sie auch eine praktische Studie durchgeführt anhand eines eigenen Prototypen für barrierearme Datenvisualisierung.

Links und Quellen

Schlagworte zur Folge

Barrierefreiheit, barrierearm, Datenvisualisierung, Accesability

Intro (00:00:00)

Thema des Podcasts (00:00:18)

Helena: Willkommen zur 41. Folge beim Datenleben Podcast, dem Podcast über Data Science. Wir sind Helena

Janine: und Janine

Helena: und möchten euch die Welt der Daten näher bringen. Was für Daten umgeben uns? Wie gehen wir mit diesen Daten um und was können wir aus ihnen lernen? Wer schon immer mehr darüber wissen wollte, ist hier richtig, denn diesen Fragen gehen wir nach.

Thema der Folge (00:00:37)

Janine: Und in der diesmaligen Folge möchten wir wieder an das Thema Datenvisualisierung anknüpfen, worüber wir schon mal relativ allgemein geredet haben, aber diesmal mit einem bestimmten thematischen Schwerpunkt. Und zwar geht es uns nämlich um Bildbeschreibungen von Datenvisualisierung, also die Frage, wie können visualisierte Daten wiederum so beschrieben werden, dass sie auch ohne das, was man sieht, verständlich sein können. Weil wir das Thema super spannend finden, aber selbst vielleicht noch nicht unbedingt so viel darüber nachgedacht hatten, haben wir uns heute eine Person eingeladen, die schon sehr viel mehr darüber nachgedacht hat als wir. Und zwar werden wir gleich mit Anvi reden, die über das Thema Barrierefreiheit von Datenvisualisierung eine Masterarbeit geschrieben hat und darüber einen Talk auf dem Fireshonks gehalten hat. Das fanden wir sehr spannend und deswegen haben wir sie gefragt, ob sie bei uns mal noch mehr darüber reden möchte.

Warum ist das Thema wichtig? (00:01:32)

Helena: Ja, und wir finden das Thema generell einfach spannend, so wie alle Themen, die Datenvisualisierung betreffen. Aber auch, weil es darum geht, wie kommuniziere ich meine Daten auch an Menschen, die die Visualisierung eben nicht sehen können oder für die die Visualisierung nicht sonderlich informativ sind. Und ja, dazu haben wir dich eingeladen, Anvi. Möchtest du dich einmal vorstellen?

Wer ist anvi? (00:01:59)

Anvi: Hi, ja, vielen Dank für die Einladung. Ich freue mich sehr, hier zu sein. Ich bin Anne Viktoria oder kurz Anvi. Meine Pronomen sind sie, ihr. Ich arbeite seit einigen Jahren als Frontend Entwicklerin und habe jetzt vor kurzem meinen Master im Bereich Mensch-Computer-Interaktion abgeschlossen. Und eben als Thema meiner Masterarbeit habe ich mir dieses Thema ausgesucht, Barrierefreiheit von Datenvisualisierung. Eben weil ich auch als Web-Entwicklerin arbeite, ist hier mein Fokus oder meine Perspektive natürlich die einer Web-Entwicklerin. Das heißt, ich habe mich recht darauf fokussiert, auch was können Web-Entwickler*innen zum Beispiel beachten, wenn sie Visualisierungen auf Seiten einbinden, gerade wenn sie sie zum Beispiel mit Libraries wie D3.js entwickeln, um diese Datenvisualisierung auch Menschen mit Behinderungen zugänglich zu machen. Bei dem Stichpunkt möchte ich kurz dazu sagen, dass ich hier auch die Perspektive habe von jemandem, der sich sehr für das Thema interessiert und sich dafür einsetzen möchte, aber dass ich selber keine Behinderung habe und deshalb nicht aus dieser Perspektive darüber sprechen kann.

Janine: Vielen Dank für deine Vorstellung. Es ist auf jeden Fall sehr spannend, sonst wärst du ja auch nicht hier und wir hätten dich nicht gefragt, wenn wir es nicht auch so sehen würden. Und da gehen wir gleich nochmal ein bisschen ins Detail, aber vorher haben wir noch einen kleinen Einspieler wie sonst auch zum Thema. Und zwar durfte ich hier Anvis Einleitungen ihrer Masterarbeit verarbeiten.

Einspieler: Stell dir vor... die Hälfte wird dir nicht gesagt (00:03:27)

Janine: Stell dir vor, du öffnest einen Artikel. Er handelt von den aktuellen Entwicklungen eines globalen Ereignisses, wie zum Beispiel der Coronavirus-Pandemie. Direkt unter dem Titel, noch ehe der eigentliche Artikel beginnt, stößt du auf folgenden Text. 26.02. 12.03. 26.03. 09.04. 23.04. 0 200 400 600. Gleitender 7-Tage-Durchschnitt. Du bist irritiert, fragst dich, was das sein soll. Vielleicht ein Fehler, vielleicht hat die Autor*in dieses Artikels versehentlich etwas aus einer Kalkulationstabelle eingefügt und es dann vergessen, vor der Veröffentlichung wieder aus dem Artikel zu entfernen. Dieser Text ist aber nichts Ungewöhnliches. Er ist sogar ziemlich typisch für das, was eine blinde oder sehbehinderte Person hört, wenn sie einen Artikel mit ihrem Bildschirmlesegerät anhört. Und zwar meistens dann, wenn sie auf eine Datenvisualisierung auf einer Webseite stößt. Während die eine Person ein überzeugendes Diagramm mit Statistiken über die Entwicklung der Pandemie sieht, hört eine andere Person eine unverständliche Aneinanderreihung von Daten und Zahlen ohne Kontext. Leider sind Datenvisualisierungen auf Webseiten für blinde oder sehbehinderte Menschen häufig unzugänglich. Diese Unzugänglichkeit ist insbesondere dann zu beobachten, wenn blinde oder sehbehinderte Personen eine Bildschirmlesesoftware verwenden, die die Informationen mit Text-to-Speech wiedergibt, also aus den schriftlichen Informationen der Webseite eine sprachliche Wiedergabe erzeugt. Eben vorliest, was andere visuell erfassen würden. Bei genauer Betrachtung des obigen Beispieltextes könnte man vermuten, dass es sich bei den Datumsangaben am Anfang um die Markierung der einen Achse eines Diagramms handelt und bei den folgenden Zahlen um die Markierung der anderen Achse. Der Text, gleitender 7-Tage-Durchschnitt, am Ende könnte dann eine Legende oder eine Beschriftung einer Datenreihe im Diagramm sein. Wenn wir nur den Text hören oder lesen, können wir jedoch nur spekulieren, was die Visualisierung, aus der dieser Text stammt, eigentlich zeigen soll. Die Zugänglichkeit von Datenvisualisierungen für Menschen mit Behinderung ist ein Thema, das von der Forschung bisher leider vernachlässigt wurde. Wenn ich mir als Mensch aber etwas vorstellen können soll, dann brauche ich die Informationen, um diese Vorstellung mit etwas auffüllen zu können. Es reicht nicht, einfach nur Zahlenreihen und eine Beschriftung zu hören. Ich muss verstehen können, was dargestellt ist, so wie alle anderen es eigentlich vielleicht auch verstehen können oder zumindest die Chance haben, es zu verstehen, indem sie einfach hinsehen. Welche Informationen fehlen? Welche brauche ich, um überhaupt eine Vorstellung von etwas haben zu können? Diese Frage ist sehr wichtig und die Antwort darauf noch umso wichtiger, vor allem, wie das umgesetzt werden kann.

Was ist Datenvisualisierung? (00:07:04)

Janine: Um uns diesem Thema anzunähern, möchten wir nochmal ein bisschen zurückblicken und die Frage nochmal aufmachen, was ist Datenvisualisierung? Und deswegen, ja, möchte ich hier nochmal ganz kurz darauf verweisen. Wir haben in Folge 13, die genau so heißt nämlich, Datenvisualisierung, schon darüber gesprochen und da aufgemacht, welche Zwecke und Ziele Datenvisualisierung haben kann. Und ja, Helena, wiederholst du einmal kurz, was wir da so besprochen haben?

Helena: Ja, im Grunde meinen Datenvisualisierung jede Sichtbarmachung von Daten. In der Regel nicht Tabellenformen, sondern zum Beispiel grafische Darstellungen. Aber die Zwecke sind sehr unterschiedlich und in der Folge haben wir insbesondere über die Exploration von Daten geredet, also darum, dass man mal einen Überblick bekommt, was überhaupt man für Daten hat. Und ein weiterer Zweck von Datenvisualisierung, den wir besprochen hatten, ist die Validierung von Modellen, die man auf Basis dieser Daten gemacht hat, also dass man bestimmte Sachen analysiert hat und dann guckt, passt die Analyse überhaupt zu diesen Daten. Dafür gibt es auch spezielle Formen von Datenvisualisierung und der Teil, den Menschen, die selber nicht mit Daten arbeiten, wahrscheinlich am öftesten sehen, ist die Anwendung der Kommunikation der Daten, um eben für andere Menschen Daten verständlicher zu machen. Die ersten Bereiche sind halt auch für Leute, die mit Daten arbeiten, selber, während die Kommunikation eben auch dafür da ist, anderen Leuten Daten verständlich zu machen. Da gibt es sehr viele verschiedene Methoden und da sollte man sich auch immer Gedanken über die Zielgruppe machen. Für wen möchte ich oder wem möchte ich die Daten jetzt kommunizieren? Weil Leute, die mehr technisches Wissen haben, könnten vielleicht andere Darstellungen bevorzugen als Leute, die weniger spezifisches Wissen in manchen Bereichen haben.

Janine: Wo uns die häufigste Form der Datenvisualisierung glaube ich vorkommt, ist in den Nachrichten häufiger, wenn da zum Beispiel über Wahlergebnisse geredet wird oder über irgendwelche Arbeitsmarktquoten. Ich muss hier gerade auch noch an die Data-Feminism-Folge denken, wo auch noch mal so ein bisschen genau über solche Aspekte geredet wurde. Aber ja, Datenvisualisierung, wir werden damit recht häufig konfrontiert. Anvi, was waren denn so deine Berührungspunkte mit Datenvisualisierung?

Anvi: Ja, zuletzt jetzt natürlich prominent meine Masterarbeit, wo ich mich intensiv mit der Barrierefreiheit von Datenvisualisierung beschäftigt habe und wo ich auch selber einen Prototyp umgesetzt habe in Form einer Webseite mit zwei Datenvisualisierungen.

Was hast du zu barrierefreier Datenvisualisierung erarbeitet? (00:09:43)

Helena: Aber worum ging es denn in deiner Masterarbeit?

Anvi: Also in sich, grob habe ich es ja schon gesagt, im Genaueren muss man natürlich sich immer ein bisschen einschränken bei so einer Masterarbeit. Das heißt, ich habe mich einerseits speziell fokussiert auf Datenvisualisierung, die direkt auf Webseiten eingebunden werden. Ich bin von diesem Fall ausgegangen, dass wir sagen, wir haben schon die Daten und wir wollen mit Code etwas umsetzen, was auf einer Webseite eingebunden wird, was dann eine Datenvisualisierung ist. Ich habe mich speziell eben auch damit beschäftigt, was man dabei beachten kann, dann als Entwickler*in, wenn man das umsetzt. Und ich habe mich auch speziell damit beschäftigt, was man beachten muss für die Barrierefreiheit von Menschen mit Sehbehinderung. Hier möchte ich dazu sagen, natürlich Menschen mit Sehbehinderung sind nicht die einzigen Menschen, die hier das Thema Barrierefreiheit betrifft. Es gibt auch andere Behinderungen, die hier auf jeden Fall relevant sind. In meiner Masterarbeit haben wir jedoch den Fokus so gewählt, dass ich mich primär mit Barrierefreiheit für Sehbehinderung beschäftigt habe.

Helena: Okay, aber könnte man sagen, dass damit das, was du dir angeguckt hast, nicht ganz übertragbar wäre, wenn man die jetzt in Social Media verwenden würde? Das wäre dann wahrscheinlich ein etwas anderer Fokus.

Anvi: Genau, das wäre natürlich ein anderer Fall dann wieder, weil man natürlich, wenn man die Kontrolle über die Webseite hat und über den Code, hat man ganz andere Möglichkeiten, das einzubinden und das barrierearm umzusetzen, als wenn man jetzt zum Beispiel in Social Media was postet und man nur ein fertiges Bild hat, was man hochladen kann und dem man maximal vielleicht eine Bildbeschreibung dazu geben kann, wo es aber nicht die Möglichkeit gibt, zum Beispiel unter dem Bild dann noch eine gut formatierte Tabelle einzubinden oder so etwas.

Helena: Okay, ja, und was hast du dann gemacht?

Anvi: An sich in meiner Masterarbeit wollte ich herausfinden, was gibt es eigentlich schon an Wissen dazu, wie man Datenvisualisierung barrierearm machen kann und wie gut funktioniert es, wenn man das in der Praxis versucht umzusetzen und wie nützlich ist es dann auch wirklich für Menschen mit Behinderungen, wenn man diese Techniken anwendet. Deswegen habe ich in meiner Masterarbeit im ersten Schritt geguckt in der Literatur, was gibt es schon für Empfehlungen aus vorherigen Studien oder anderen Werken, was man berücksichtigen sollte, um die Datenvisualisierung möglichst barrierearm umzusetzen. Daraus habe ich dann so 19 Guidelines entwickelt. Die habe ich dann wiederum angewendet in einem Prototyp mit zwei Datenvisualisierungen, den ich implementiert habe mit D3.js, also die Datenvisualisierung sind mit D3.js umgesetzt, und das habe ich dann wiederum evaluiert in einer kleinen Studie mit fünf Personen mit Sehbehinderungen, wo wir uns jeweils in Zoom getroffen haben und diese Personen dann zuerst Aufgaben bearbeitet haben mithilfe des Prototyps. Und hinterher habe ich ihnen dann noch ein paar Fragen gestellt zur Usability und welche Features ihnen gefallen haben und so weiter.

Helena: Okay.

Janine: Das heißt, du hast gleich irgendwie versucht, einen praktischen Zugang dazu zu finden und nicht nur theoretisch darüber nachgedacht, wie man es machen könnte, sondern auch mit Menschen zusammengearbeitet, um das eben auszuprobieren und dann zu Ergebnissen zu kommen.

Anvi: Genau, also das war mir auch wichtig in meiner Masterarbeit, dass ich, ich sage mal, möglichst nah an der Praxis und möglichst nah an den Menschen, die es betrifft, arbeite, dass ich nicht jetzt, wie es halt leider häufig passiert, irgendwo in meinem Kämmerlein sitze und mir irgendwas ausdenke. Ich als Person ohne Behinderung denke mir irgendwas aus, was meiner Meinung nach super cool wäre für Leute mit Behinderung und schreibe dann da irgendwas drüber. Und in Wahrheit geht es total an der Lebensrealität von den Menschen vorbei. Deswegen war das für mich eben wichtig, was zu machen, einerseits was konkret anwendbar ist mit aktuell vorhandenen Web-Technologien und halt dann auch wirklich zu gucken mit Menschen, die Behinderungen haben, ob es für sie gut funktioniert.

Helena: Okay, du hattest gerade was von 19 Empfehlungen, die du umgesetzt hättest, erzählt. Was hast du da gemacht konkret?

Anvi: Unterschiedlich. Es ist schwierig, das zusammenzufassen, ohne jetzt diese 19 Punkte durchzugehen. Aber ich kann euch ein paar Beispiele geben.

Helena: Ja, das ist gut.

Anvi: Also ich möchte jetzt nicht behaupten, dass es die wichtigsten wären, weil ich hier jetzt keine Hierarchie der Wichtigkeit aufbauen möchte. Aber ein Beispiel zum Beispiel, was ich immer empfehlen würde und was auch Teil von diesen Guidelines war, ist, die Daten als Tabelle anzubieten, zusätzlich zur Datenvisualisierung. Es ist egal, wie gut die Datenvisualisierung umgesetzt ist, ob sie zum Beispiel für Screenreader-User*innen gut zugänglich ist oder ob es eine gute Beschreibung gibt. Es ist immer sinnvoll, auch eine Tabelle mit einzubinden, wo die Daten dargestellt sind. Und das ist zum Beispiel eine von den Empfehlungen. Dann zum Beispiel auch, dass die Farben ausreichend Kontrast haben sollten, so dass sie gut erkennbar sind. Sie sollten gut unterscheidbar sein, auch für Menschen, die zum Beispiel eine Farbsehschwäche haben. Schrift sollte gut lesbar sein. Es sollte alles gut beschriftet und gelabelt sein. Wenn man zum Beispiel einen Screenreader verwendet, ich weiß nicht, soll ich erklären, was ein Screenreader ist?

Janine: Ja, mach gern mal.

Anvi: Ein Screenreader ist eine Software, die häufig von Menschen mit Sehbehinderung genutzt wird, aber nicht nur von dieser Gruppe, die sie verwenden, um sich das vorlesen zu lassen, was auf dem Bildschirm zu sehen ist. Also der Screenreader parsed alles, was auf dem Bildschirm zu sehen ist. Und wenn wir jetzt über Webseiten reden, dann parsed er alles, was auf der Webseite ist, schaut sich an zum Beispiel, was für Überschriften gibt es und so weiter und macht das dann für die Person verfügbar, die über bestimmte Tastaturbefehle dann diese Webseite durchgehen kann, zum Beispiel zwischen den Überschriften hin und her springen kann. Und das wird dann meistens über Sprachausgabe ausgegeben. Dann wird zum Beispiel vorgelesen, was die Überschrift ist, auf der man sich aktuell befindet. Und Screenreader sind zum Beispiel sehr typisch für Menschen, die blind sind, die damit dann zum Beispiel Webinhalte konsumieren.

Woher kann ich wissen, was ich machen muss, für Barrierefreie Zugänge? (00:16:19)

Helena: Jetzt mal abgesehen von deiner Masterarbeit. Woher kann ich denn wissen, wenn ich eine Webseite baue, worauf ich achten sollte? Was kann ich mir denn mal angucken oder gibt es da irgendwelche Richtlinien für, die das irgendwie mir als Person, die selber noch nicht so genau weiß, worauf es ankommt, zugänglicher macht, um zu wissen, was ich machen kann?

Anvi: Also wenn wir jetzt allgemein über Barrierefreiheit von Webseiten sprechen, dann gibt es schon seit langer Zeit die Webcontent Accessibility Guidelines vom World Wide Web Consortium. Das sind Richtlinien, die bestimmte Kriterien vorgeben, was erfüllt sein sollte, damit eine Webseite möglichst barrierearm ist. Da stehen dann so Sachen drin, wie zum Beispiel, achte drauf, dass die Schriftgröße mindestens so und so groß ist, Bilder müssen Bildbeschreibungen haben, die Navigation sollte konsistent und verständlich sein und solche Sachen. Natürlich, allein diese Kriterien zu erfüllen, garantiert noch nicht, dass die Webseite irgendwie irgendwo in der Nähe von barrierefrei ist. Das kommt halt sehr viel immer darauf an, dass man auch das so umsetzt, dass es irgendwie auch verständlich ist, dass es gut benutzbar ist, dass es Sinn ergibt. Aber an sich ist das so die Grundlage, wonach sich die meisten richten, wenn sie versuchen, eine Webseite möglichst barrierearm zu machen.

Helean: Ja, und wenn es jetzt konkret bezogen auf Daten, kannst du da auch was empfehlen?

Anvi: Genau, also an sich, diese Webcontent Accessibility Guidelines sind recht allgemein formuliert, so dass sie möglichst auf alle Arten von Webseiten passen sollten. Das ist einerseits sehr gut, weil man sie dann sehr breit anwenden kann, aber es ist eben auch ein Problem, wenn man dann so doch recht spezifische Arten von Content hat auf einer Webseite, wie eben Datenvisualisierung, die schon ein bisschen spezieller sind teilweise, gerade wenn sie interaktiv sind. Und da ist es häufig dann gar nicht so klar, wie eigentlich diese Richtlinien anzuwenden und zu verstehen sind in Bezug auf Datenvisualisierung. Was ganz cool ist, ist, es gibt ein Projekt, das nennt sich Chartability, und dort gibt es Richtlinien, die sehr ähnlich aufgebaut sind wie die Webcontent Accessibility Guidelines und zielt speziell ab auf die Barrierefreiheit von Datenvisualisierung. Und dieses Chartability würde ich zum Beispiel empfehlen, wenn man auf seiner Webseite Datenvisualisierung einbindet und man sich dann beschäftigen möchte, wie kann ich die möglichst barrierearm umsetzen, worauf sollte ich achten? Dann hilft es auf jeden Fall, dass es so einen Kriterienkatalog vorgibt, den man durchgehen kann, um zu schauen, wo eventuell noch Barrieren sind in der Datenvisualisierung.

Was sind typische Barrieren? (00:19:14)

Janine: Und was sind da die typischen Barrieren, die es da gibt?

Anvi: Was typisch ist zum Beispiel gerade für Screenreadernutzer*innen, sind häufig Datenvisualisierung gar nicht als solche erkennbar. Normalerweise ein Screenreader sagt zum Beispiel an, wenn auf einer Webseite ein Bild ist, und man dorthin navigiert, wo dieses Bild ist, dann sagt der Screenreader an, hier ist ein Bild, und wenn es eine Bildbeschreibung gibt, dann wird die Bildbeschreibung auch vorgelesen. Das Problem mit Datenvisualisierung ist, dass sie häufig so umgesetzt sind, dass überhaupt nicht erkennbar ist, dass dort überhaupt etwas ist, oder dass nur erkennbar ist, hier ist irgendwas, hier sind irgendwelche Zahlen, ich höre irgendwelche Zahlen, aber ich höre nicht, was das eigentlich ist. Das heißt, häufig ist ein Problem, dass gar nicht klar ist, dass eine Datenvisualisierung gerade vorhanden ist. Und andererseits auch, wenn es irgendwie verständlich ist, dass es hier gerade eine Datenvisualisierung ist, passiert es auch häufig, dass der Screenreader-Output nicht wirklich nützlich ist. Wenn jetzt nicht irgendwelche speziellen Schritte unternommen wurden, um diese Datenvisualisierung barrierearm zu machen, und diese Datenvisualisierung zum Beispiel mit D3.js umgesetzt wurde und aus SVG-Elementen besteht, dann würde der Screenreader höchstwahrscheinlich einfach das vorlesen, was er an Text findet in dieser Datenvisualisierung. Und das sind eben dann so Sachen wie irgendwie Text, der in der Legende steht, oder die Tickmarks an einer Achse, wenn es eine Achse gibt, oder ein Label, was neben einer Linie steht. Aber nicht zum Beispiel, was das für eine Visualisierung ist, wie sie aussieht, warum sie dort ist, was da drin zu erkennen ist, was für Daten da drin sind, was die Trends in den Daten sind, und all dieses, was eigentlich interessant wäre, warum man eigentlich meistens diese Visualisierung auch einbindet auf der Seite, das ist dann meistens überhaupt nicht erkennbar, wenn man einen Screenreader benutzt.

Janine: Zum Beispiel, wie du es auch in der Einleitung gemacht hast, die ich hier im Einspieler verarbeiten durfte, wo eben einfach nur vorgelesen wurde, verschiedene Daten, verschiedene Zahlen und dann eben das vermutliche Label mit dem Sieben-Tages-Wert, der dann mit dabei stand. Das war ja auch so kontextlos. Also gut, ich habe dann vielleicht gewusst, um welche Daten es geht, also an welchem Tag etwas war und was sozusagen die Bandbreite der Skala war, nämlich von 0 bis 600, aber dazwischen fehlt alles andere an Informationen.

Anvi: Genau, also das war jetzt zum Beispiel auch ein konkretes Beispiel von einer echten Seite, ich sage nicht welche, auf der ich mit einem Screenreader war und da war eben genau so eine Statistik der Sieben-Tage-Inzidenz und das war eben genau dieser typische Fall, dass nur eigentlich die Beschriftungen vorgelesen wurden, aber es keinen Zugang gab zu den eigentlichen Daten und es auch eben keine Möglichkeit gab, auf die Daten selber zuzugreifen.

Janine: Ja, oder überhaupt zu wissen, warum diese Zeile da jetzt auftaucht.

Anvi: Also was es manchmal gibt, ich weiß jetzt nicht, ob das in dem Fall der Fall war, ist eben zum Beispiel ein Link dann zu einer Datentabelle. Das ist natürlich cool, wenn es das gibt, weil das zumindest dann eine Alternative schon mal gibt, auf die Daten zuzugreifen. Aber diese Tabellen sind halt auch nicht die Norm, noch nicht.

Janine: Ja, mir ist gerade noch eingefallen, was ja für Screenreader tatsächlich auch einen Unterschied macht, ist zum Beispiel, wie ich Schrift benutze. Also ich denke jetzt, was ich in Social Media bisher mitbekommen habe, ist, wenn Hashtags benutzt werden, meinetwegen #DatenlebenLeaks. Das hatten wir schon öfter mal als Hashtag benutzt. Und wenn alles klein geschrieben wird, kann es für den Screenreader schwer sein, das zu interpretieren. Und deswegen setzt man bei sowas, weil Hashtags müssen ja in einem Wort geschrieben werden, um so anklickbar zu sein. Deswegen benutzt man eben Großbuchstaben, um die Worte einzeln vorlesbar zu machen, sodass der Screenreader das dann besser interpretieren kann. Also das ist jetzt so etwas, was mir gerade noch einfällt. Trifft wahrscheinlich auf die meisten Datenvisualisierung in dem Fall jetzt nicht zu. Ist bestimmt Social Media spezifisch, aber ja, kann helfen, die Worte verständlich zu machen.

Anvi: Aber das ist natürlich auch ein Punkt hier, sag ich mal, dass man möglichst mitdenken oder mit Screenreader ausprobieren sollte, wie sich die Sachen mit Screenreader anhören. Und das ist natürlich auch relevant bei Daten, gerade wenn es zum Beispiel um Zahlen geht. Da ist es nämlich zum Beispiel wichtig, dass man möglichst die Daten so formatiert, wenn das zum Beispiel so eine Zahl ist wie 7,5 Millionen, dass man sie schön mit den ordentlichen Tausender- und Dezimal-Trennzeichen versieht, dass dann der Screenreader das auch vorliest als 7,5 Millionen und nicht als 7 5 0 0 0 0 0. Weil das nämlich auch dann den Cognitive Load erhöht und das natürlich das schwerer verständlich macht, wenn man mit dem Screenreader so eine Datenvisualisierung durchgeht und anstatt, dass man die Zahl verständlich vorgelesen kriegt als 7,5 Millionen, man dann die einzelnen Ziffern nur angesagt bekommt, weil die Zahlen nicht richtig formatiert wurden. Also das ist auch so ein Punkt, dass man das immer mitdenken sollte. Natürlich ist das häufig auch eine Sache, die unterschiedlich ist zwischen verschiedenen Screenreadern und die teilweise auch eine Einstellungssache ist, weil natürlich Screenreader auch Einstellungen haben, zum Beispiel wie verbos die Sachen vorlesen, welche Sonderzeichen wie vorgelesen werden und so weiter. Ich habe es in meiner Studie zum Beispiel auch gehabt, dass, ich glaube, bei vier von fünf Personen wurden die Zahlen super vorgelesen und bei einer Person wurden aus irgendeinem Grund die Ziffern alle einzeln vorgelesen, was es halt total schwierig macht, mit den Daten zu arbeiten.

Helena: Ja.

Janine: Als ich den einen Spieler eingesprochen habe, hatte ich das Problem tatsächlich auch. Und dann habe ich gedacht, naja, aber vielleicht hätte der Screenreader das ja auch schon als Datum interpretiert und wahrscheinlich 12.3., 26.3. und so was weiter gesagt. Da war ich selbst verwirrt und ich hatte kurz überlegt, ob ich dich noch anfrage, wie ich es denn vorlesen soll. Weil ja, mir hat da auch der Kontext gefehlt. Was war das Ergebnis? Wie wurde das gemacht? Und ja, das finde ich spannend. Natürlich geht so den Programm selbst auch, wenn man das jetzt mal so menschlich sagt, wenn denen vorher nicht gesagt wird, wie funktioniert das, dann werden sie da ein ganz anderes Ergebnis ausspucken.

Helena: Ja, aber es ist bei Zahlen generell so, wenn man zu viele Nachkommastellen dahinschreibt, wenn die gar nicht relevant sind, dass das dann generell Daten weniger leicht verständlich macht. Oft sind die Nachkommastellen ja sogar nur komplette Berechnungsartefakte und komplett irrelevant ab einem gewissen Punkt. Und wenn man die jetzt wahrscheinlich mit zehn Nachkommastellenzahlen irgendwohin macht, dann hilft das jetzt gerade auch mit Screenreadern natürlich auch nicht weiter. Die würde ja eh niemand lesen.

Anvi: Genau, aber das ist natürlich ja auch eine Sache, die für Accessibility auch wichtig ist, jetzt unabhängig von Sehbehinderungen zum Beispiel, weil das natürlich auch eine Dimension von Accessibility oder von Barrierefreiheit ist, dass ich gucke, wie mache ich die Datenvisualisierung so, dass sie möglichst leicht verständlich ist? Und leichter verständlich ist natürlich, wenn die Zahl irgendwie sinnvoll gerundet und schön formatiert ist, als wenn die da irgendwie in einer unnötig hohen Präzision oder mit unnötig vielen Nachkommastellen drinsteht.

Was kann ich tun, um auf Barrierefreiheit hinzuarbeiten? (00:26:51)

Helena: Ja, aber kommen wir doch noch mal zu dem Thema, was kann ich denn tun, um die Barrierefreiheit beziehungsweise die Barriere, ja, die Barrieren zu reduzieren?

Anvi: Ja, Barrierefreiheit ist so ein komisches Wort, oder? Weil also wirklich kann man je hundertprozentige Barrierefreiheit erreichen, das ist zu bezweifeln.

Helena: Ja.

Janine: Das stimmt.

Anvi: Genau, also ich kann gerne mal noch ein paar Tipps geben, Beispiele geben dazu. Wenn ich jetzt mal mir die Situation vorstelle, ich bin Webentwicklerin oder Webentwickler, möchte auf meiner Webseite eine Datenvisualisierung umsetzen, was sind da typische Sachen, die es zu beachten gibt? Da kann ich gerne eine Übersicht geben, jetzt von den Sachen, die man beachten könnte, die man natürlich auch in zum Beispiel Chartability wiederfinden wird, deswegen hier muss jetzt niemand mitschreiben, kann gerne ein paar Sachen erzählen, aber in Zweifelsfall würde ich euch empfehlen, bei Chartability reinzuschauen. Aber was zum Beispiel eine Sache ist, die ich in der Literatur immer wieder gelesen habe und die ich selber auch in meiner Studie festgestellt habe, ist, dass es unglaublich wertvoll ist, die Daten und die Visualisierung auf mehreren Wegen zugänglich zu machen. Das heißt zum Beispiel, dass ich einerseits die Visualisierung selber anbiete, das kann zum Beispiel jetzt in einem simplen Fall einfach ein Bar Chart sein, und dass ich dem zum Beispiel als erste Alternative eine Bildbeschreibung gebe, wo beschrieben wird, was für eine Art von Chart ist das, was ist darin zu sehen, warum ist das Chart hier, was möchte ich mit dem Chart ausdrücken. Und dass ich dann als weitere Alternative zum Beispiel eine Datentabelle anbiete, unter dem Chart oder als Link, dann auf einer eigenen Seite, für Menschen, für die das einfach einfacher ist, zum Beispiel das als Tabelle aufzurufen. Oder auch zum Beispiel, dass die Daten als Download angeboten werden, dass man einfach sagt, okay, wir bieten einen Download an und wer die Daten lieber in einem eigenen Programm öffnen möchte, kann die Daten einfach runterladen und in einem eigenen Programm öffnen. Dann kann man natürlich auch noch Sachen machen, wie dass man zum Beispiel versucht, wirklich die Elemente der Visualisierung selber barrierearm zu machen, also barrierearm meine ich jetzt gar nicht, sondern ich meine Screenreader zugänglich in diesem Fall, dass man sagt, okay, die einzelnen Elemente können auch mit dem Screenreader zum Beispiel durchgegangen werden. Oder dass ich zum Beispiel auch eine Audio-Version anbiete, wo die Daten nicht visuell dargestellt werden, sondern zum Beispiel in Form von Tönen. Und das sind einfach jetzt so Beispiele dafür, wie man die Daten auf viele verschiedene Arten und Weisen zugänglich machen kann. Und der Trick ist hier einfach, je größer die Anzahl ist von Wegen, auf denen man diese Daten zugreifen kann, desto größer ist die Wahrscheinlichkeit, dass das für eine bestimmte Person dann einer dieser Wege funktioniert.

Helena: Okay, ja.

Janine: Ist das etwas, was du in deiner Masterarbeit dann mit deinen Proband*innen auch rausgefunden hast? Also hast du diese Rückmeldung auch bekommen?

Anvi: Es war recht interessant, weil ich das so stark gar nicht erwartet hatte. Meine Proband*innen, es waren insgesamt fünf, waren alle, sag ich mal, auf dem Spektrum von komplett blind bis stark sehbehindert und sie haben sehr unterschiedliche Features eigentlich genutzt im Prototyp und es haben ihnen auch unterschiedliche Features gefallen. Ich habe zum Beispiel textuelle Beschreibungen von den Visualisierungen drin gehabt und es gab eine Person, die hat sehr viele von den Aufgaben, die ich gestellt habe, einfach gelöst, indem die Person die textuellen Beschreibungen durchsucht hat oder sich angehört hat und dort schon die Lösung gefunden hat oder dort einen Hinweis gefunden hat, zumindest in welchem Bereich der Daten sie suchen muss, um den richtigen Wert zu finden. Dann gab es zum Beispiel andere Personen, die total viel mit der Tabelle gearbeitet haben und die auch gesagt haben, total super, dass die Tabelle drin ist, die gesagt haben, die Tabelle ist für sie persönlich sehr wichtig und würden sie begrüßen, wenn mehr Seiten sowas hätten. Es gab dann auch wiederum eine Person, die ein Feature sehr viel genutzt hat, das war die Zoom-Funktion. Und zwar habe ich eine Zoom-Funktion eingebaut, wo man die Datenvisualisierung in Fullscreen öffnen kann und man dann rein und raus zoomen kann auf das Chart. Und da gab es eben eine Person, die das sehr viel genutzt hat und die sich sehr drüber gefreut hat, dass es dieses Feature gab. Und da war ich eigentlich schon überrascht, dass, obwohl ich nur fünf Proband*innen hatte, was eine eher geringe Anzahl ist, es doch recht divers war, welche Features sie genutzt haben und welche Features ihnen gefallen haben.

Helena: Ja, ich meine, letztlich kriegt man ja bei allen Themen immer komplett verschiedene Antworten, wenn man Leuten fragt, ja, wie nutzt ihr denn diese eine Sache? Oder welcher Teil davon ist für euch wichtig? Das ist ja immer unterschiedlich, die Antworten. Deswegen ist das ja auch ein guter Punkt, darauf hinzuweisen, dass man eben verschiedene Arten anbieten sollte. Und insbesondere die Tabelle wäre ja technisch auch besonders leicht umzusetzen, ohne großen Mehraufwand. Also nicht jede Person, die eine Webseite betreibt, hat vielleicht die Kapazitäten und die Tabelle ist, glaube ich, dann das Einfachste, was man machen kann. Also das sollte eigentlich immer machbar sein. Ja, was ich auch schön fände, wäre, wenn Standardprogramme, die Datenvisualisierung bereitstellen, auch ein automatisches Feature hätten, dann passende Tabellen auszuspucken.

Anvi: Ja, das gibt es bei manchen. Ich glaube das, oder ich sage mal, ich hoffe, das wird jetzt auch mehr. Aber ich weiß, bei manchen gibt es das schon.

Helena: Ja.

Janine: Also wir hatten ja auch schon mal über ggplot geredet, womit Helena gerne Grafik gemacht. Und da kann man ja auch schon die verschiedenen Farbschemata reinladen, die eben für Farbsehschwächen hilfreich sind, um Graphen besser lesbar zu machen.

Helena: Aber irgendwie automatisches Extrahieren wiederum von bestimmten Informationen habe ich da jetzt noch nicht gesehen. Ich habe aber auch noch nicht nachgeguckt, ob es das da schon gibt.

Was gibt es beim Thema Kontrast zu beachten? (00:33:11)

Janine: Eine Sache, die du gerade ja schon angesprochen hattest für die Verbesserung von Barrieren oder den Abbau von Barrieren war der Kontrast. Gibt es da bestimmte Sachen zu beachten oder wie gehe ich damit um?

Anvi: Genau, das ist natürlich auch eine typische Barriere bei Datenvisualisierung, dass einerseits die Schrift zu klein, zu wenig kontrastreich, zu schlecht lesbar ist. Aber auch häufig, dass die grafischen Elemente selber zu wenig Kontrast haben, schlecht unterscheidbar sind und häufig für Menschen mit Farbsehschwäche zum Beispiel auch schwer zu unterscheiden ist, was dann zu was gehört in der Legende und in der Visualisierung. Und deswegen ist es natürlich dann auch wichtig, was das Visuelle angeht, dass man alles möglichst gut lesbar macht, dass man möglichst große und gut lesbare Schrift wählt, dass man gut unterscheidbare Farben wählt und dass man alles möglichst kontrastreich macht, würde ich mal sagen. Da gibt es ja auch zum Beispiel Online-Tools, mit denen man das Kontrastlevel überprüfen kann. Es gibt auch Tools, die einem helfen, Farbpaletten zu generieren für Datenvisualisierung, die für Menschen mit Farbsehschwäche auch gut unterscheidbar sein sollten. Also da gibt es viele Tools, die einem auch helfen können, zum Beispiel dann richtige Farben für Sachen zu wählen, die dann gut lesbar und gut unterscheidbar sind. Und was natürlich jetzt, sag ich mal, noch super cool wäre, ist, wenn man Möglichkeiten zur Anpassung von Farben und Kontrast einbindet. Also, wenn man zum Beispiel die Möglichkeit anbietet, in der Datenvisualisierung selber das Farbschema zu ändern oder die Schrift größer zu machen oder den Kontrast zu erhöhen. Das wäre natürlich optimal.

Helena: Ja, das kann ich mir vorstellen, weil würde man maximalen Kontrast einstellen, wird es ja dann wieder für viele Menschen unangenehm anzugucken. Also normalsichtige Menschen, ich weiß nicht, ob das ein gutes Wort ist. Aber ich kenne das von einigen Programmen, wenn ich auf maximal Kontrast gestellt habe, um das mal auszuprobieren, dass es für mich dann plötzlich schwieriger wird, mir Grafiken anzugucken, weil für meine Sehgewohnheit das nicht so gut passt. Und deswegen finde ich den Vorschlag, das anzubieten, dass man das interaktiv einstellen kann, eigentlich ziemlich gut, weil eben die Ansprüche oder die Barrieren für Leute ja unterschiedlich sind.

Janine: Ja.

Helena: Und man nicht alles mit einer einzigen Visualisierung abfangen kann.

Janine: Also aus der Bildbearbeitung weiß ich auch, wenn mich nicht alles täuscht zumindest, dass je höher ich den Kontrast drehe, desto mehr Informationen gehen aber verloren. Also Farben bleiben dann irgendwann auf der Strecke, weil nur noch die kontrastreichsten dann irgendwann über bleiben und wenn man einfach nur am Kontrast dreht, kann es auch schnell zu Sachen kommen, die miteinander verschwimmen.

Helena: Ja.

Janine: Von daher sind so ganz unterschiedliche Einstellungen, die vorgenommen werden können. So ein bisschen mehr Interaktivität mit der Darstellung garantiert von Vorteil.

Helena: Aber wenn man bei einer grafischen Darstellung von Daten zu viele verschiedene Farben hat, dann ist das generell für alle unverständlich.

Janine: Das stimmt.

Anvi: Genau. Irgendwann sollte man sich auch überlegen, ob es dann nicht Zeit ist, eine andere Art der Visualisierung zu wählen. Wenn man 20 verschiedene Linien in 20 verschiedenen Farben hat, dann sollte man vielleicht hinterfragen, ob man wirklich alle diese Linien nebeneinander anzeigen muss.

Janine: Ja.

Helena: Ja, genau. Das kann niemand unterscheiden.

Janine: Gibt es denn noch weitere Sachen, wo eine individuelle Anpassung sinnvoll wäre, jetzt nicht nur bei der Farbauswahl oder dem Kontrast?

Anvi: Wo es natürlich cool wäre, aber schwierig umzusetzen, sage ich mal, ist bei textueller Beschreibung, bei der textuellen Beschreibung der Datenvisualisierung. Das ist nämlich etwas, wo die Präferenzenrechte auseinandergehen. Ich weiß nicht, wer sich schon mal damit beschäftigt hat, eine gute Bildbeschreibung zu schreiben. Ist schon, ja, ich würde sagen, eine Form der Kunst, so eine gute zu schreiben, die halt angemessen ist für das, was man kommunizieren möchte, die das präzise, ohne zu lang ausschweifen zu werden, rüberbringt. Und gerade bei textuellen Beschreibungen gehen die Präferenzen auch recht stark auseinander. Einerseits, wie lang oder kurz sie sein sollte, und auch, welche Inhalte jetzt interessant sind. In meiner Studie zum Beispiel hatte ich den Fall, ich habe an sich Bildbeschreibungen für die Datenvisualisierung inkludiert. Da drin wurde beschrieben, allgemein, was ist das für ein Diagramm, welche Achsen gibt es, wo liegen die Extremwerte, was für Trends sind zu sehen. Und all diese Sachen wurden beschrieben in dieser Bildbeschreibung. Das heißt, es war recht ausführlich. Und wie ich vorhin schon gesagt habe, gab es eben eine Person zum Beispiel, die diese Bildbeschreibung total gerne mochte, die damit sehr viel gearbeitet hat in der Studie und die auch gesagt hat, sie würde sich wünschen, dass andere Webseiten auch sowas hätten. Und diese Person hat zum Beispiel gesagt, wenn sie sich aussuchen könnte, dann hätte sie es sogar lieber, dass diese Bildbeschreibung noch ausführlicher wäre und dass dann noch mehr Daten, also das noch genauer beschreiben würde, wie der Trend zum Beispiel verläuft in der Datenvisualisierung. Andererseits hatte ich dann eine Person in der Studie zum Beispiel, die am liebsten eigentlich die Bildbeschreibung auf ein Minimum reduziert hätte. Diese Person hat gesagt, dass es ihr am liebsten wäre, wenn in der Bildbeschreibung nur drinsteht, was das für eine Visualisierung ist und warum die hier ist. Und dass diese Person von der Bildbeschreibung eigentlich nur möchte, dass die Bildbeschreibung kommuniziert, was für ein Element ist das hier. Und diese Person würde danach dann direkt zum Beispiel zu einer Tabelle gehen wollen und dann direkt nur mit der Tabelle arbeiten, was zum Beispiel dann die Person in der Studie auch gemacht hat. Ich habe auch in der Literatur zum Beispiel eine Studie gelesen, wo Personen Bildbeschreibungen bewerten sollten. Ich glaube, das haben sie mit sehenden und nicht sehenden Personen gemacht. Es ist sowohl zwischen den beiden Gruppen ziemlich auseinandergegangen, teilweise auch innerhalb der Gruppen, welche Art von Informationen diese Menschen gerne in einer Bildbeschreibung hätten von einer Datenvisualisierung und welche Informationen sie zum Beispiel nicht gerne hätten. Und deshalb wäre das wahrscheinlich eine Sache, wo es cool wäre, wenn das irgendwie auch anpassbar wäre. Wie viel textuelle Beschreibung bekomme ich zu der Datenvisualisierung? Wenn ich gar keine haben möchte, dann bekomme ich nur ganz kurz eben einen Satz dazu, was das da für ein Element ist. Oder wenn ich jemand bin, der total gerne damit arbeitet, der am liebsten gerne noch zusätzliche Erklärungen, Kontextinformationen, Erklärungen der Trends und so weiter hätte, dass ich eben auch diese Informationen dann noch textuell bekommen kann. Wie man das am besten umsetzen könnte? Keine Ahnung, aber cool wäre es sicher.

Janine: Ja, das klingt auf jeden Fall so.

Was sollte eine Bildbeschreibung enthalten? (00:40:29)

Helena: Wenn wir jetzt schon beim Thema textuelle Beschreibung sind. Wenn ich jetzt eine ausführliche Beschreibung machen möchte. Wie sollte ich da vorgehen? Ich meine, wenn es ein bestimmtes Schema gibt, kann ja vielleicht die eine Person ja auch einfach weiterspringen, die dann das nicht so ausführlich haben will.

Anvi: Wenn man jetzt zum Beispiel in Social Media etwas postet, dann ist es ja häufig so, dass man wirklich nur einen Text eingeben kann als Bildbeschreibung und keine Möglichkeit hat, das zu formatieren. Der große Vorteil ist natürlich, wenn man selber das umsetzt auf einer Webseite, dass man nicht gezwungen ist, das als einen Fließtext, als einen langen Block umzusetzen, sondern dass man eben die Möglichkeit hat, weil es eine Webseite ist, Markup zu verwenden und dass man zum Beispiel auch so eine längere Beschreibung dann gliedert in zum Beispiel Unterüberschriften, die dann sagen, hier ist eine kurze Beschreibung allgemein, dann ist hier eine kurze Beschreibung der Trends, die zu sehen sind und hier ist eine kurze Erklärung des Kontexts von dieser Datenvisualisierung. Das ist natürlich eine Sache, die man machen kann, die da helfen könnte. Ansonsten, was den Inhalt selber angeht, gab es zum Beispiel einen Vorschlag einer Strukturierung von solchen Bildbeschreibungen von Datenvisualisierung von zwei Wissenschaftlern von Lundgard und Satyanarayan und die haben eben so ein Modell entwickelt, wo sie gesagt haben, es gibt eigentlich vier Ebenen, auf denen man so eine Datenvisualisierung beschreiben kann. Sie haben jetzt nicht gesagt, man muss von allen vier Ebenen die Informationen mit reinnehmen. Da gab es eben ja auch diese unterschiedlichen Präferenzen zwischen den Leuten, welche Informationen für sie nützlich waren und welche nicht. Aber ich kann einmal kurz erklären, was die vier Ebenen sind, auf denen man eine Datenvisualisierung beschreiben kann. Das erste wäre Übersicht und Aufbau. Das sind so grundlegende Informationen wie, was ist das eigentlich für eine Datenvisualisierung? Ist das ein Liniendiagramm? Ist das ein Balkendiagramm? Ist das ganz was anderes? Dann auch, was zum Beispiel ist der Titel? Was für Achsen gibt es zum Beispiel in dieser Visualisierung? Und wie sind die Daten codiert? Das wäre so die ganz grundlegende Ebene. Hier haben wir noch nichts über den Inhalt erfahren. Hier haben wir nur was über den Aufbau der Visualisierung erfahren. Dann die zweite Dimension wäre ein statistischer Überblick. Das sind alle Informationen, die man aus den Daten statistisch berechnen kann. Das sind so Sachen wie, wo liegt hier der Median in der Datenreihe? Wo liegen die Extremwerte? Oder auch einfache Vergleiche, wie zum Beispiel, die eine Datenreihe verhält sich so und so zur anderen Datenreihe in bestimmten Punkten. Dann die dritte Ebene oder Dimension wären die sichtbaren Phänomene. Hier geht es dann darum, dass man die Sachen, die für sehende Personen eben sichtbar sind, als zum Beispiel Trends in den Daten, in der Visualisierung, als bestimmte Muster, als Cluster oder als Outlier, dass man diese Sachen in Text beschreibt, damit eben diese wertvolle Information auch Screenreadernutzer*innen zugänglich gemacht wird. Und dann die vierte Dimension. Das sind, ja so ich sag mal, zusätzliche Kontextinformationen. Das sind so Sachen wie Erklärungen der allgemeinen Thematik um dieses Chart drumrum. Zum Beispiel, wenn das jetzt eine Visualisierung von Bevölkerungsdaten ist, dann könnte dort zum Beispiel eine Erklärung sein zum demografischen Wandel oder etwas so. Oder es könnte zusätzliche Kontextinformationen geben, warum zum Beispiel die Bevölkerung in dieser Statistik in einem bestimmten Jahr stark gewachsen, stark gesunken ist. Vielleicht gab es ein bestimmtes Event, was damit zu tun hatte oder es wurde ab einem bestimmten Zeitpunkt anders gezählt oder etwas. Alle diese zusätzlichen Informationen würden in diese vierte Kategorie zählen.

Helena: Okay, also für mich klang das Vierte jetzt nach, wenn man eine Webseite macht, auf der auch Text zu der allgemeinen Erklärung für alle steht, die dann auch eigentlich für alle relevant wäre.

Janine: Oder auch Interpretationen zu der Darstellung vielleicht an diesem Punkt.

Anvi: Mhm.

Janine: Also gut kenntlich gemachte Interpretationen muss es natürlich sein. So stelle ich mir das gerade vor. Der Aufbau liest sich für mich sehr vom Allgemeinen ins Spezielle runter steigend. Und dann natürlich die Abgrenzung bei den zusätzlichen Informationen gegebenenfalls zu dem, was sind die Schlüsse, die daraus gezogen werden. So, vielleicht. Ich kann es mir auf jeden Fall, finde ich das sehr verständlich strukturiert.

Anvi: Aber da hast du eben was Interessantes auch gesagt, mit dem, was hast du gemeint, gut kenntlich gemacht. Das ist tatsächlich auch ein Punkt oder einer der Gründe, warum häufig dann die Meinungen zu den Bildbeschreibungen so auseinandergehen, weil es nämlich häufig eben auch berechtigt, sage ich mal, die Kritik gibt, dass das immer irgendwie eine Interpretation ist. Das ist quasi, wenn ich eine Beschreibung von einer Datenvisualisierung lese, die entweder automatisch generiert wurde oder die von jemandem per Hand geschrieben wurde, dann ist da immer eine gewisse Interpretation mit drin. Zumindest, ich sage mal, ab dieser Ebene der sichtbaren Phänomene, wo dann immer natürlich bewusst eine Auswahl getroffen wird. Was sind für mich als sehende Person, die jetzt diese Bildbeschreibung schreibt, die sichtbaren Phänomene? Was sind für mich die Phänomene, die ich als wichtig genug erachte, sie jetzt in die Bildbeschreibung mit reinzuschreiben? Und was sind jetzt die Annahmen, die ich treffe, was interessant wäre, zum Beispiel für eine sehbehinderte Person, zu wissen über dieses Chart? Da ist es natürlich, finde ich, auch verständlich, dass dann manche Leute sagen, sie möchten lieber selber möglichst guten Zugriff auf die Daten haben, weil sie eben nicht diese Daten nur so durch die Beschreibung einer anderen Person mediiert quasi erleben möchten, sondern weil sie selber direkten Zugang haben möchten. Und das ist eben ein häufiger Vorbehalt, der natürlich auch begründet ist.

Janine: Ja, absolut. Das hatten wir auch in der Data-Feminism-Folge auf einer anderen Ebene, nämlich eben, dass die Darstellung selbst ja auch schon eine Auswahl von Daten ist. Und da war auch einer der Punkte, dass das gleichzeitige Zurverfügungstellen der Rohdaten verhindert, dass es nur auf die Interpretation ankommt. Genau, deswegen kann ich mir das auch gut vorstellen, dass hier der zusätzliche Zugang zu den Daten innerhalb einer Tabelle beispielsweise dann eben auch davor schützt, nur auf die Interpretation angewiesen zu sein.

Anvi: Ja. Ein anderer Punkt, von dem ich aus anderen Studien gelesen habe, ist auch, dass es leider häufig das Problem gibt, dass bei Datenvisualisierung, wenn sie eine Bildbeschreibung haben, häufig die Bildbeschreibung nicht aktuell ist. Das heißt, gerade wenn es um so Sachen geht wie irgendwelche Dashboards von aktuellen Entwicklungen, die vielleicht täglich oder mehrmals täglich aktualisiert werden, dass diese Bildbeschreibung, gerade eben, wenn sie nicht automatisch generiert, sondern per Hand geschrieben wird, einfach vergessen wird, mit zu aktualisieren. Und dass halt dann häufig Screenreadernutzer*innen auch schon schlechte Erfahrungen gemacht haben, dass sie zum Beispiel eine Bildbeschreibung sich angehört haben, dort die vermeintlich aktuellen Daten sich angehört haben, und dann wechseln sie zur Tabelle und stellen auf einmal fest, das ist hier eine Beschreibung von vor zwei Wochen, die ich gerade gehört habe, und der Wert für mich ist genau null davon. Das ist eben auch so ein Punkt, warum halt dann manche skeptisch gegenüber solchen Beschreibungen sind und sagen, okay, wenn ich mir die Beschreibung anhöre und hinterher erst merke, dass die irgendwie total out of date war, dann bitte gebt mir einfach direkt die Daten.

Helena: Ja, deswegen wäre es für solche Sachen natürlich gut, wenn man eine Methode findet, dass man die Bildbeschreibung auch generieren kann aus den Daten.

Anvi: Das wird teilweise auch empfohlen, dass die direkt automatisch generiert werden, eben aus solchen Gründen, damit es nicht möglich ist, das zu vergessen, sie zu aktualisieren, wenn die Daten sich ändern.

Helena: Ja, das ergibt auf jeden Fall Sinn, ja.

Was ist dein Fazit aus deiner Masterarbeit? (00:49:04)

Janine: Ja, wir haben ja jetzt schon über ganz viele verschiedene Punkte gesprochen. Hast du denn aus deiner Masterarbeit, was ist denn so dein Fazit, was du daraus noch gezogen hast?

Anvi: Eigentlich, was recht erfreulich war für mich, war die Erkenntnis, dass wir im Prinzip auf einem guten Weg sind in Richtung Abbau von Barrieren bei Datenvisualisierung, auch wenn natürlich aktuell in der Praxis, sage ich mal, auf realen Webseiten der Zustand in diesem Bereich noch katastrophal ist. Nichtsdestotrotz habe ich gemerkt, dass wenn man die Literatur sich anschaut, wenn man sich anguckt, was andere sich überlegt haben, was andere herausgefunden haben und das wirklich anwendet, dass dabei eigentlich was ganz Passables rauskommt. Es konnten die Aufgaben ziemlich gut bearbeitet werden in meiner Studie mithilfe des Prototypen. Auch das Feedback von den Probanden zum Prototyp war sehr positiv. Das heißt, wenn man es wirklich will, dann kriegt man es auch möglichst barrierearm hin mit dem, was wir aktuell haben an Technologie, mit dem, was wir aktuell haben an Wissen. Natürlich ist das jetzt noch eine Sache, dass es dann auch gewollt und priorisiert werden muss in der Praxis, aber prinzipiell sind wir auf einem guten Weg, würde ich sagen, und das hat mich eigentlich recht gefreut.

Janine: Das klingt sehr schön und vielversprechend.

Anvi: Bei der Tabelle, wie sollte ich die denn dann machen? Hast du da irgendeine Erkenntnis zu, was ist einer Tabelle nützlich? Weil irgendwie denke ich ja, der Standardscreenreader wird ja nicht irgendwie selber in der Lage sein, Tabellen leicht zugänglich zu machen oder wie muss ich mir das vorstellen? Kann ich da sinnvoll drin suchen oder wie funktioniert das?

Anvi: Bei den Tabellen sollte man natürlich allgemein beachten, dass man die Accessibility Best Practices beachtet, einfach was das Umsetzen von HTML-Tabellen angeht, also zum Beispiel, dass man von Headern den Scope setzt, dass klar ist, worauf sie sich beziehen, damit dann die Screenreader, wenn man durch die einzelnen Einträge durchnavigiert, auch ansagen können, in welcher Spalte bin ich gerade, in welcher Zeile bin ich gerade, worauf bezieht sich das gerade? Das ist die eine Sache und ansonsten, was sehr wichtig wäre, dass man die Tabelle nicht nur als statische Tabelle anbietet, sondern dass man sie auch interaktiv macht. Das habe ich tatsächlich in meinem Prototyp nicht gehabt. Ich habe nur eine statische Datentabelle gehabt und das wurde mehrfach genannt von den Proband*innen, dass es super nützlich wäre, wenn diese Tabelle sortierbar wäre und wenn sie durchsuchbar wäre, weil ich zum Beispiel so Aufgaben hatte in meiner Studie, wo dann gefragt wurde, in welcher Altersgruppe sind die meisten Menschen in der Datenvisualisierung? Und da habe ich dann das Feedback bekommen, ja, diese Frage könnte ich super schnell beantworten, wenn die Tabelle sortierbar wäre, aber da sie nicht sortierbar ist, müsste ich jetzt hier den ganzen Tag sitzen und jeden Eintrag einzeln anhören und mir im Kopf merken und mit den anderen Einträgen im Kopf vergleichen, um dann hinterher irgendwie hoffentlich sagen zu können, was jetzt der größte Eintrag war.

Helena: Mhm.

Anvi: Was halt einfach nicht haltbar ist. Deswegen, das ist halt so eine kleine Sache, die aber das Leben unglaublich viel leichter machen kann, dass man diese Tabelle sortierbar und durchsuchbar macht.

Helena: Ja, ich meine, für alle Leute, die mit einer Tabelle arbeiten, ist es angenehmer, wenn man die sortieren kann. Oder auch filtern, dass man dann nur bestimmte Einträge sich anzeigen lässt und die dann sortiert zum Beispiel.

Anvi: Ja, auf jeden Fall.

Helena: Ja, und etwas, was du auch noch angesprochen hattest, war so das Hörbemachen von Grafiken. Das ist etwas, was ich jetzt so aus verschiedenen Raumfahrtkontexten oder irgendwie Astronomie- kontexten öfter mal gehört hatte, wo, wenn ich mir das anhöre, ich dann denke, ja, okay, es klingt manchmal ganz nett, aber ich wüsste jetzt erst mal mit dieser Hörbarmachung nicht so viel anzufangen. War das denn irgendwie bei deinem Prototypen erfolgreicher oder wie war das Feedback da?

Anvi: Genau, bei meinem Prototyp hatte ich an sich für die Visualisierung jeweils so eine kleine Sonification eingebaut. Da konnte man über einen Playbutton einfach einen Track starten, wo dann in der Reihenfolge, in der die Daten in der Datenvisualisierung von links nach rechts angezeigt werden, genau in dieser Reihenfolge einfach Töne abgespielt werden. Zum Beispiel hatte ich ein Balkendiagramm und dort wurde dann pro Balken ein Ton abgespielt und im Liniendiagramm pro Zeitpunkt, den ich jeweils hatte auf der x-Achse, wurde ein Ton abgespielt und die Höhe des Tons hat dann angezeigt, wie hoch oder niedrig dieser Datenwert war. Und da musste ich sagen, dass einfach so, wie ich das umgesetzt habe, das überhaupt nicht nützlich war. Also das war für niemanden nützlich in der Studie. Es war nicht ganz klar, was genau diese Sonification jetzt eigentlich bringen sollte im Sinne von Use Case. Also es war nicht, es fehlte ein klares Konzept, ob diese Sonification jetzt nur wie so einen kurzen hörbaren Thumbnail einfach einen Überblick über die Daten geben soll oder ob es möglich sein soll, anhand der Sonification wirklich die Daten zu analysieren und quasi einzelne Datenpunkte nacheinander abzuspielen, vor und zurück zu navigieren und so weiter. Das hat einfach gefehlt bei mir, dieses Konzept für die Sonification. Und entsprechend war die Sonification recht nutzlos in der Form, in der ich sie eingebaut habe. Die Proband*innen haben recht schnell die Orientierung verloren. Es war zum Beispiel nicht klar, wenn ich jetzt einen Ton höre, der eine bestimmte Höhe hat, war nicht klar, ist das jetzt gerade ein sehr niedriger Wert, ist es ein sehr hoher Wert oder ist es ein eher so durchschnittlicher Wert gerade? Und teilweise waren die Sonifications auch recht lang, vor allem bei dem einen Diagramm, was einen recht langen Zeitraum umfasste, wo die Personen dann irgendwann auch die Orientierung verloren haben von in welchem Jahr befinde ich mich eigentlich gerade, bin ich gerade eher so in der Mitte der X-Achse oder eher schon so gegen Ende irgendwo?

Helena: Mhm.

Anvi: Also ich will überhaupt nicht ausschließen, dass Sonifications nützlich werden können. Ich weiß nicht, ob es jetzt einfach nur meine Implementierung war in dem Fall, die mangelhaft war, aber da kann ich einfach nicht wirklich was zu sagen. Also vielleicht, wenn es jemand anders noch mal probiert, dann ist es vielleicht viel nützlicher.

Helena: Ja, ich kann mir auch vorstellen, weil bei vielen anderen visuellen Darstellungen ist es auch so, wir werden darauf trainiert, dass wir die oft sehen und wenn es noch keinen wirklichen Standard gibt für bestimmte Darstellungen, sind wir auch nicht gewohnt, damit zu arbeiten. Wenn es da einen Standard gäbe, den viele Leute einsetzen würden, wären die wahrscheinlich besser nachvollziehbar, weil man dann weiß, wie man das zu interpretieren hat, weil es oft vorkommt. Aber solange das immer nur einzelne Experimente bleiben, kann es ja diese Art von Gewöhnung gar nicht geben.

Anvi: Ja, also ich schätze, das betrifft beide Seiten. Zum einen natürlich, dass User*innen sich dann erst daran gewöhnen müssen, was eine Sonification ist und wie man sie bedient. Und zum anderen müssen sich wahrscheinlich auch erst so Patterns und Best Practices finden dafür, wie man sie umsetzt, so gewisse Standard-Interaktionsmuster, die dann die User*innen mit der Zeit auch lernen können und wo sie dann auch wissen, ah, das ist jetzt wieder eine Sonification. Da gibt es wahrscheinlich jetzt ein Play-Button und wahrscheinlich ein Vor- und Zurück-Button und dass sie ungefähr wissen, worauf sie sich auch einstellen können. Ja, das kann ich mir gut vorstellen. Ja, und ich kann mir auch vorstellen, dass es letztendlich vielleicht auch einfach darauf ankommt, welches Mittel für welche Inhalte sich gut eignet. Also vielleicht eignet es sich nicht, um etwas Größeres darzustellen, sondern vielleicht für kleinere Datensätze oder für Sachen, die gar nicht jetzt sich unbedingt auf gesammelte Daten beziehen, sondern auf aktuelle Werte. Das ist zum Beispiel, ich meine, wir wissen es ja, im Prinzip ist ja ein Feuermelder auch so eine Form von Sonification. Er informiert uns über einen zu hohen Wert von etwas in der Luft, so dass wir wissen, jetzt müssen wir handeln.

Anvi: Mhm.

Janine: So, das ist ja auch so etwas in die Richtung und ich kann mir vorstellen, dass vielleicht auch einfach das Ziel und der Zweck von so etwas eine Rolle spielt bei der Umsetzung.

Anvi: Ja, auf jeden Fall. Ich denke, das braucht einfach noch einige Arbeit, bis wir da dann schlauer sind, was das Thema angeht, wie wir Sonification sinnvoll einsetzen können.

Was waren die Schwierigkeiten bei der Umsetzung deines Prototypen? (00:57:43)

Helena: Ja, was hattest du denn insgesamt für Schwierigkeiten bei der Umsetzung von deinem Prototypen?

Anvi: Du meinst jetzt meine Perspektive quasi als Designerin und Entwicklerin dieses Prototyps?

Helena: Genau, als Webentwicklerin, die technisch Dinge umgesetzt hat.

Anvi: Ja, was tatsächlich recht schwierig war, war, dass es recht wenig Guidance gab einfach dafür bisher, wie man Datenvisualisierung wirklich so implementiert, dass sie möglichst barrierearm sind. Zum Beispiel habe ich ja mit die D3JS gearbeitet, was aus den Daten SVG-Elemente generiert und zum Beispiel musste ich mir da selber dann recht viel überlegen und rumprobieren, wie ich zum Beispiel die einzelnen SVG-Elemente innerhalb von der Datenvisualisierung dann so markieren kann, so taggen kann, dass sie auch zum Beispiel von Screenreadern erkannt werden, sodass es zum Beispiel möglich ist, mit der Tastatur oder mit dem Screenreader dann zum Beispiel von Datenpunkt zu Datenpunkt zu navigieren innerhalb der Visualisierung.

Helena: Hast du auch noch andere Libraries in JavaScript mal ausprobiert, sowas wie Plotly oder so, im Vergleich zu D3?

Anvi: Ich habe jetzt tatsächlich in meiner Masterarbeit nur mit D3.js gearbeitet. Natürlich gibt es unterschiedliche und natürlich arbeiten die Libraries auch recht unterschiedlich. Also D3.js zum Beispiel arbeitet ja recht, wie nenne ich das, recht low-level, dass man eigentlich sehr viel Code selber schreiben muss dazu, wie man das visualisiert.

Helena: Man kann dafür auch viel Code selber schreiben.

Anvi: Genau, das heißt zum Beispiel so, out of the box gibt einem D3.js gar nichts, was Accessibility angeht, aber dadurch, dass man sehr viel selber macht, kann man eben auch sehr viel dann tüfteln und ausprobieren.

Helena: Ja.

Anvi: Gibt auch andere Libraries, die zum Beispiel, denen man einfach sagt, hier sind die Daten, gib mir mal einen Bar Chart und dann gibt die Library einem einfach ein fertiges Bar Chart, wo man natürlich dann viel weniger Kontrolle hat und wo es dann einfach darauf ankommt, hat die Library zum Beispiel eine Funktion, dass man eine Bildbeschreibung einbindet? Hat sie die Möglichkeit, dass man die einzelnen Elemente, Tastatur benutzbar, Screenreader benutzbar macht? Hat sie die Möglichkeit, dass man die Farben manuell auswählt und so weiter? Also Libraries direkt verglichen habe ich jetzt nicht. Ich weiß, es gibt manche Libraries, die schon auch Accessibility Features mit eingebaut haben. Gibt manche, die es besser machen, manche, die es schlechter machen, aber genaue Aussagen kann ich dazu nicht machen.

Helena: Ja, abgesehen von dem, was du jetzt gerade erzählt hast, was war denn noch schwierig?

Anvi: Was recht tricky war dabei, war vor allem auch, wie ich die Semantik richtig kommunizieren kann. Also wie ich zum Beispiel die einzelnen Elemente in der Visualisierung so implementieren kann, dass der Screenreader sinnvoll damit interagieren kann und sinnvoll dann dem Benutzer oder der Benutzerin kommunizieren kann, was das eigentlich ist. Was ich damit jetzt meine ist, es gibt in HTML viele Elemente, die inhärent eine gewisse Semantik haben. Und deswegen im Bereich Accessibility wird zum Beispiel auch immer wieder wiederholt die Aufforderung, dass man semantisches HTML schreiben soll. Das heißt zum Beispiel, die Hauptüberschrift auf einer Webseite sollte immer mit einem h1-Tag umgesetzt werden, weil Screenreader eben diese Standard-Elemente, wie zum Beispiel h1, kennen und auch die Semantik davon kennen und das dann entsprechend ansagen können. Das heißt, der Screenreader erkennt, dort ist ein h1 und kann dann dem Nutzer oder der Nutzerin ansagen, Hauptüberschrift oder Überschriftebene 1 und dann die Überschrift vorlesen. Oder zum Beispiel, wenn wir ein Button-Element verwenden, dann weiß der Screenreader zum Beispiel, dass ist etwas, wo drauf geklickt werden kann, dass ist etwas, was interaktiv ist, weil eben ein Button-Element diese Semantik direkt mitbringt und diese Interaktionsmöglichkeiten. Und für eben viele typische Inhalte, die es auf Webseiten gibt, eben wie Überschriften, wie Buttons, wie Links, wie Tabellen, wie Listen und Listen-Elemente, gibt es eben schon diese vorgefertigten HTML-Elemente, die gewisse Funktionalität und eine gewisse Semantik out of the box mitbringen, die von den Screenreadern auch so erkannt werden. Was es dann möglichst bequem macht oder was es dann häufig bequem macht, damit zu interagieren, so haben zum Beispiel viele Screenreader auch Features, um zum Beispiel Tabellen effizient zu navigieren oder um zum Beispiel sich eine Liste geben zu lassen von den Überschriften, die es auf einer Seite gibt oder um von Link zu Link zu springen und solche Sachen, so dass eben auch eine effiziente Navigation möglich ist. Wenn wir uns jetzt wieder Datenvisualisierungen angucken, da gibt es natürlich auch gewisse typische Elemente, die häufiger vorkommen in den Visualisierungen, wie zum Beispiel eine Achse, eine x-Achse mit einer Beschriftung, eine y-Achse mit einer Beschriftung oder zum Beispiel einen Balken in einem Balkendiagramm oder etwas wie ein Tooltip, wo die Daten zu einem Datenpunkt drinstehen und solche Sachen. Und die Schwierigkeit, die ich hatte oder ich sag mal, was ich mir gewünscht hätte, wäre, dass es halt eben auch, wenn nicht von HTML selber, aber wenn es zumindest irgendwelche Best Practices gäbe, wie ich die Sachen umsetzen und markieren kann, so dass eben vom Screenreader dann auch eine effiziente Navigation ermöglicht wird und dass eben auch der Person gut kommuniziert werden kann vom Screenreader, dass hier ist gerade eine Achse, auf der du bist oder du bist gerade innerhalb vom Tooltip und diese drei Zeilen von Text gehören zu diesem Tooltip noch dazu. Oder dass es die Möglichkeit gibt, zum Beispiel so wie es die Möglichkeit gibt, von Link zu Link zu springen, dass es die Möglichkeit gäbe, von Balken zu Balken zu springen. Das sind natürlich alles Sachen, die man manuell implementieren kann und eben das ist natürlich auch, was ich dann gemacht habe. Aber das Problem war eben, dass es häufig dann sehr fragil war, was ich implementiert habe. Also ich habe zum Beispiel dann gemerkt, okay, ich implementiere es, es funktioniert mit dem einen Screenreader, mit dem einen Browser, aber wenn ich zum Beispiel einen anderen Screenreader oder einen anderen Browser verwende, gibt es schon wieder Schwierigkeiten, weil dieser Screenreader eben diese Elemente, die ich verwendet habe, wieder anders interpretiert oder bestimmte Labels, die ich verwendet habe, nicht vorgelesen werden oder bestimmte Interaktionsformen, die ich implementiert habe, in dem einen Browser mit dem einen Screenreader funktionieren und in dem anderen nicht. Da fehlen einfach so noch die Standards und Best Practices dafür, wie man eben solche typischen Elemente in Datenvisualisierung so umsetzt, dass man auch mit dem Screenreader zum Beispiel damit effizient arbeiten kann.

Gibt es noch etwas, was du zu diesem Thema noch loswerden möchtest oder dich noch interessiert? (01:04:35)

Janine: Das klingt auf jeden Fall sehr sinnvoll. Also und eigentlich auch gar nicht unmöglich, aber ja, muss halt irgendwo irgendwann irgendwer Standards auch festschreiben können. Ich würde mal sagen, wir haben schon recht viel geredet und schon viele interessante Punkte auf jeden Fall abgedeckt. Gibt es noch etwas, was du zu diesem Thema noch loswerden möchtest oder dich noch besonders interessiert?

Anvi: Eine Sache, die ich gerne noch den Zuhörer*innen hier mitgeben würde, ist, dass es wichtig ist, dass man im Kopf behält, dass auch wenn wir hier jetzt viel von Screenreadern reden und dass natürlich Menschen, die blind sind, meistens Screenreader benutzen, dass nicht alle Screenreader-Nutzer*innen 100% blind sind und dass überhaupt Blindheit nicht so etwas ist, was man hat oder nicht hat, sondern dass es eben ein Spektrum ist von Sehbehinderung zu starker Sehbehinderung zu verschiedenen Graden der Blindheit. Und dass eben sehr wohl viele Menschen, die stark sehbehindert sind und zum Beispiel einen Screenreader benutzen, dass die nicht komplett blind sind, sondern dass die immer noch zum Beispiel auch gewisse Sachen auf dem Bildschirm erkennen können und das auch sich zunutze machen. Zum Beispiel habe ich eine Person auch in der Studie gehabt, die stark sehbehindert war und einen Screenreader genutzt hat, die aber auch ihr Restsehvermögen genutzt hat, um zum Beispiel im Chart so ungefähr zu erkennen, wo denn die Balken am höchsten sind und sich dann mit dem Screenreader die Balken genauer angehört hat, aber eben nur in diesem Bereich, wo sie gesehen hat, dass die Balken sehr hoch sind. Das war jetzt bei der Frage, wo es darum ging, das Maximum zu finden. Und das ist einfach so etwas, was gerne vergessen wird, weil ich höre häufiger so Vorschläge mit, wäre das nicht viel cooler für Screenreadernutzer*innen, beziehungsweise für blinde Leute, eine ganz andere User Experience zu bauen? Wäre es nicht cooler, wenn man einfach sagt, ja, wir machen jetzt komplett irgendwie hier eine sichtbare Version der Datenvisualisierung und jetzt machen wir eine Audio Experience für die Leute, die blind sind? Und da würde ich halt immer von abraten, weil halt das einfach so eine falsche Unterteilung ist. Es gibt nicht sehende Leute und dann Leute, die blind sind und Screenreader benutzen, sondern es gibt eben, es ist Blindheit und Sehbehinderung ist ein Spektrum. Und abgesehen davon sind auch sehbehinderte Leute nicht die einzigen Leute, die Screenreader benutzen, sondern es gibt auch Leute, die zum Beispiel keine Sehbehinderung haben, sondern andere Behinderungen und deshalb Screenreader benutzen. Es gibt Leute, die in gewissen Situationen einfach Screenreader benutzen, zum Beispiel wenn sie müde sind und keinen Text lesen wollen und die sich das einfach gern vorlesen lassen. Das ist einfach etwas, wo ich immer gerne dran erinnere, weil das meiner Meinung nach gerne vergessen wird. Nicht alle Screenreadernutzer*innen sind blind.

Helena: Ja, was möchtest du noch zu diesem Thema loswerden, bevor wir zum Fazit kommen?

Anvi: Es gibt eigentlich nur eine Sache, an die ich gerne noch erinnern würde, das habe ich schon vorhin genannt, aber wenn ihr jetzt wirklich in der Situation seid, dass ihr Datenvisualisierung macht und euch fragt, okay, wie kann ich das möglichst barrierearm machen, dann würde ich auf jeden Fall empfehlen, dass ihr euch Chartability anguckt von Frank Elavsky. Das ist eben dieser Kriterienkatalog, der ähnlich aufgebaut ist zu den Webcontent Accessibility Guidelines. Der ist meiner Meinung nach eine super hilfreiche Ressource dabei, Datenvisualisierung barrierearm zu machen.

Janine: Das klingt super gut und werden wir definitiv auch in den Shownotes verlinken.

Anvi: Sehr gut.

Janine: Wie überhaupt auch deine Arbeit, deine Masterarbeit ist ja öffentlich zugänglich, die ist online publiziert, die werden wir natürlich auch gerne verlinken und ein paar andere Ressourcen noch.

Fazit (01:08:26)

Janine: Ja, Helena, ich würde sagen, dann ist es Zeit für ein Fazit. Was meinst du?

Helena: Ja, also ich fand das sehr spannend zu hören, weil, ja, wie ich schon am Anfang meinte, finde ich es einfach sehr relevant, dass man Daten, wenn man die kommunizieren möchte, auch zugänglich macht und dazu gehören halt viele Punkte. Und ja, jetzt habe ich einen groben Überblick, wie ich da vorgehen könnte und vor allen Dingen, dass Tabellen sehr wichtig sind. Das ist so etwas, was ich mitnehme. Und wenn ich zumindest eine Verbesserung mache, dann wenigstens, dass ich Tabellen hinzufüge, im Idealfall aber auch noch mehr anbiete. Das ist eine sehr gute Erkenntnis.

Janine: Ja, also ich nehme auf jeden Fall auch mit, was du vorhin über den Aufbau von den Beschreibungen gesagt hast, aus der Literatur, auf die du da angespielt hast, mit den verschiedenen Ebenen des Beschreibungstextes. Da werde ich auf jeden Fall auch noch mal gucken, inwiefern ich da zum Beispiel Sachen wiederfinde, die ich eben auch für unseren Podcast schon beschrieben habe, wo ich Bildbeschreibungen für Grafiken angefertigt habe und so. Das interessiert mich jetzt vor allem auch mal, da mal zu gucken, inwiefern ich da gut mit diesen Ebenen umgehe, so dass das potenziell auch verständlicher ist und klarer herauskommt, worauf es da ankommt.

Helena: Ja, in unserem Podcast haben wir ja auch ab und zu Folgen, wo wir tatsächlich Grafiken beschreiben, über die wir reden.

Janine: Ja.

Helena: Da könnte das auch hilfreich sein. Gibt es noch irgendwas Persönliches, zu dem du Werbung machen möchtest? Werbung für dich oder für deine weiteren Projekte?

Anvi: Ich möchte Werbung machen für Bildbeschreibungen. Wenn ihr auf Social Media etwas postet, wenn ihr einen Blog habt und der hat Bilder, beschreibt die Bilder. Dankeschön.

Janine: Das ist ein sehr schönes Schlusswort. Ich verlinke auch dazu auf jeden Fall noch einen Fireshonks Talk von Casey. Casey ist eine Webentwicklerin mit Sehbehinderung, die über Bildbeschreibungen auf Social Media geredet hat und da auch sehr gute Hinweise gibt. Ich fand das auch sehr aufschlussreich. Dann jetzt auch danke dir, Anvi, dass du uns an deiner Zeit hast teilhaben lassen und vor allem an dem, was du in deiner Masterarbeit, dir an Wissen erarbeitet hast. Und ich hoffe auch, unsere Hörer*innen können da einiges daraus mitnehmen. Vielen Dank.

Helena: Ja, von mir auch vielen Dank.

Anvi: Ja, vielen, vielen Dank euch, dass ihr mich eingeladen habt. Ich bin so froh, dass ich die Möglichkeit hatte, einfach so das, was ich aus meiner Masterarbeit mitgenommen habe, einfach noch mal weiterzugeben, auch, weil ich das so schade finde, wenn man wirklich sich in ein Thema reinarbeitet, wirklich versucht, auch etwas Sinnvolles rauszuziehen, wenn man es dann niemandem weitergeben kann. Und deswegen bin ich total dankbar, dass ich hier die Möglichkeit hatte, jetzt einfach das noch mal weiterzugeben, was ich so gelernt habe aus meiner Masterarbeit. Und ich hoffe, dass es irgendjemand aus der Zuhörerschaft vielleicht weiterhilft.

Helena: Ja, das denke ich doch. Sehr schön.

Nächste Folge: Wahrscheinlichkeiten im September (01:11:28)

Helena: Dann kündige ich mal die nächste Folge an.

Janine: Mach mal.

Helena: Ja, im September erscheint dann die nächste Folge. Darin geht es um Wahrscheinlichkeiten, und zwar am Beispiel von Asteroiden, die potenziell unseren Planeten treffen könnten. Wenn ihr wissen wollt, wie man auf diese Wahrscheinlichkeiten kommt und wie man die berechnet, dann hört euch die Folge an.

Call to Action (01:11:51)

Janine: Genau. Und wenn ihr uns weiterhören möchtet, dann folgt uns doch auf Twitter unter @datenleben oder Mastodon @datenleben@podcasts.social. Ihr findet unsere Folgen nicht nur im Podcatcher eurer Wahl, wenn ihr unseren Feed abonniert, sondern auch noch auf unserer Webseite www.datenleben.de. Da könnt ihr uns auch Feedback hinterlassen. Darüber freuen wir uns immer sehr. Und ihr könnt uns auch als Data Scientist buchen für Analysen oder Projekte. Falls ihr Fragen oder Themen habt, die euch interessieren, dann schreibt uns gerne.

Helena: Und dann bleiben wir nur noch, für eure Aufmerksamkeit zu danken. Und bis zum nächsten Mal. Ciao.

Anvi: Tschüss.

Janine: Tschüss.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert