Einleitung

Ein sehr wichtiger Aspekt der Softwareentwicklung ist das UX/UI-Design. Daher kommt die zugrundeliegende Idee dieses Innovationsprojektes, welche es war ein Tool zu entwickeln, welches mit Hilfe von KI im UX/UI-Design unterstützt. Als Zielgruppe wurden Softwareentwickler und UX/UI-Designer gewählt. Da das UX/UI-Design viele Bereiche umfasst, wurde das Thema in einem ersten Schritt eingegrenzt. Ein Bereich des UX/UI-Designs ist die digitale Barrierefreiheit. Mit immer mehr kommenden Gesetzen und Richtlinien ist dies ein sehr wichtiges Thema, weshalb es zum Fokus dieses Innovationsprojektes wurde. Eines der Gesetze ist das Barrierefreiheitsstärkungsgesetz (BFSG), welches den European Accessibility Act (EAA) in das nationale Recht überführt. Mit dem BFSG ist festgelegt, welche Barrierefreiheitsanforderungen Produkte und Dienstleistungen, die ab dem 28.06.2025 auf den Markt kommen zu erfüllen haben. [1] Doch auch innerhalb der Barrierefreiheit gibt es verschiedene Aspekte, die beachtet werden müssen. Einer davon sind ausreichende Farbkontraste zwischen beispielsweise der Schriftfarbe eines Textes und dem zugehörigen Hintergrund. Hierzu gibt es die Richtlinien 1.4.3 Kontrast (Minimum) [2] und 1.4.11 Nicht-Text-Kontrast [3], die in diesem Zusammenhang beachtet werden müssen.

Im Verlauf des Innovationsprojektes wurde daher ein Tool entwickelt, welches mit Hilfe von Gemini die Farbkontraste von Bildern und Webseiten auf Barrierefreiheit überprüft. Um die Aussagekraft und Korrektheit des Tools zu validieren wurden zwei Forschungsfragen festgelegt, welche durch Usertests des Tools beantwortet werden. Als Forschungsfragen wurden „Wie zuverlässig kann ein multimodales Sprachmodell wie Gemini die Farbkontraste und Farbgestaltung eines Bildes im Hinblick auf WCAG-Richtlinien bewerten und verbessern?“ und „Wie unterscheiden sich manuelle WCAG-Kontrastprüfungen von automatisierten, KI-basierten Analysen im Hinblick auf Genauigkeit, Zeitaufwand und Nutzerfreundlichkeit?“ festgelegt.

Im folgenden Paper wird zuerst auf den theoretischen Hintergrund des Themas eingegangen, bevor die Konzeption und Entwicklung des Tools beschrieben werden. Anschließend folgt die Durchführung und Auswertung der Usertests, bevor das Paper mit der Beantwortung der Forschungsfragen endet.

Theoretischer Hintergrund und verwandte Tools

In diesem Kapitel werden wichtige theoretische Hintergründe erläutert, die benötigt werden, um die folgende Arbeit zu verstehen. Ebenso werden verwandte Tools aufgeführt.

Digitale Barrierefreiheit

Die digitale Barrierefreiheit beschreibt, wie digitale Inhalte und Benutzeroberflächen dargestellt werden sollen, so dass sie für alle Menschen erkennbar und nutzbar sind. Dies umschließt sowohl Menschen ohne Beeinträchtigungen als auch Menschen mit temporären und dauerhaften Beeinträchtigungen. Bei den Farbkontrasten betrifft die Einhaltung der Barrierefreiheitsstandards vor allem Menschen mit Sehbeeinträchtigungen. [4]

Barrierefreiheits-Richtlinien

Im Rahmen der Barrierefreiheit von Farbkontrasten sind die Richtlinien 1.4.3 Kontrast (Minimum) und 1.4.11 Nicht-Text-Kontrast relevant.

In der Richtlinie 1.4.3 Kontrast (Minimum) wird festgelegt, dass Texte und Text in Bildern ein Kontrastverhältnis von mindestens 4,5:1 haben muss. Eine Ausnahme hiervon bildet großer Text, der lediglich ein Kontrastverhältnis von mindestens 3:1 benötigt. Ebenso als Ausnahme zählt Text oder Text in Bildern, welcher rein dekorativ oder für niemanden sichtbar oder Teil einer inaktiven Benutzerschnittstelle ist, da hierfür keine Kontrastanforderungen herrschen. Ebenso keine Kontrastanforderungen gibt es für die dritte Ausnahme, welche Wortbildmarken bilden, also Text, welcher Part eines Logos oder Markennamen ist. [2]

Die Richtlinie 1.4.11 Nicht-Text-Kontrast besagt, dass alle Bestandteile der Benutzerschnittstelle und alle grafischen Objekte zu benachbarten Farben mindestens ein Kontrastverhältnis von 3:1 benötigen. Als Bestandteil der Benutzerschnittstelle zählen alle sichtbaren Bedienelemente, wie beispielweise Buttons, Eingabefelder und Links, und auch deren Zustandsanzeigen, wenn deren Erkennbarkeit relevant ist für die Bedienbarkeit. Hierzu zählen aktiv, fokussiert und ausgewählt. Auch hierbei gibt es wieder eine Ausnahme, welche kein Kontrastverhältnis vorgibt, wenn die Bestandteile der Benutzerschnittstelle deaktiviert sind oder wenn die unveränderte Standarddarstellung des Browsers genutzt wird. Zu den grafischen Objekten zählen alle Bildbestandteile, welche benötigt werden, um den Inhalt zu verstehen. Beispiele hierfür sind Diagramm-Linien, Symbole auf Karten und Piktogramme. Eine Ausnahme hiervon bilden grafische Objekte, bei denen die exakte visuelle Gestaltung selbst eine Information transportiert. Ein Beispiel hierfür sind Heatmaps, in denen mit Farbabstufungen die verschiedenen Daten dargestellt werden. [3]

Barrierefreiheits-Gesetz

In der Einleitung wurde bereits das Barrierefreiheitsstärkungsgesetz (BFSG) erwähnt. Dieses Gesetz wurde am 15.06.2022 verabschiedet und überführt den European Accessibility Act (EAA) ins nationale Recht. Das BFSG besagt, welche Barrierefreiheitsanforderungen für Produkte und Dienstleistungen, welche entweder nach dem 28.06.2025 auf den Markt gebracht werden oder für Verbraucher erbracht werden, zu erfüllen sind. Zu den Produkten, für die das BFSG gilt, zählen Hardwaresysteme einschließlich ihrer Betriebssysteme, Selbstbedienungsterminals, Verbraucherendgeräte, die einen interaktiven Leistungsumfang haben und für Telekommunikationsdienste oder den Zugang zu audiovisuellen Mediendiensten verwendet werden und E-Book-Lesegeräte. Zu den Dienstleistungen gehören Telekommunikationsdienste, verschiedene Elemente von Personenbeförderungsdiensten, wie Webseiten, Apps, elektronische Tickets und die Bereitstellung von Verkehrsinformationen, Bankdienstleistungen für Verbraucher, E-Books mit zugehöriger Software und Dienstleistungen im elektronischen Geschäftsverkehr. [1]

Verwandte Tools

Neben der Theorie zur Barrierefreiheit ist es zudem wichtig zu wissen, welche ähnlichen Tools bereits existieren. Ein Beispiel dafür ist das  Stark-Plugin, welches in verschiedenen Anwendungen und Browsern aktiviert werden kann. Hierzu zählen Figma und Chrome. Als Browser-Plugin bietet das Tool einen automatischen WCAG-Audit, der die aktuelle Webseite auf WCAG-Kriterien prüft und in einer Übersicht die Ergebnisse zur Verfügung stellt. Welche WCAG-Kriterien genau geprüft werden ist auf der Webseite nicht dokumentiert. [5] Ebenso bietet das Tool die Möglichkeit händisch den Kontrast verschiedener Farben zu überprüfen und bietet hierzu Verbesserungsvorschläge an, die direkt auf die Webseite oder das Design angewendet werden können. Das bietet die Möglichkeit die neuen Farben temporär direkt im aktuellen Design begutachten zu können, bevor sie dann händisch übernommen werden. [6] In einem manuellen Test des Tools konnten jedoch vereinzelte Mängel festgestellt werden. So gab es Probleme die richtigen Farben auszuwählen und es wurden nicht immer Farb-Verbesserungsvorschläge geliefert. Zudem wichen die Farb-Verbesserungsvorschläge teilweise deutlich von den originalen Farben ab.

Ein weiteres Tool ist das ARC Toolkit, welches als Browser-Erweiterung verwendet werden kann. Mit dem ARC Toolkit kann eine Barrierefreiheitsprüfung auf Basis von WCAG 2.0, WCAG 2.1, WCAG 2.2, EN 301 549 und Section 508 durchgeführt werden. Ein Teil der Überprüfung ist hierbei auch die Überprüfung auf barrierefreie Farbkontraste. Das Tool liefert hierbei die Information darüber an welcher Stelle das Problem liegt und welche Richtlinie nicht erfüllt wird. Es liefert jedoch keinen Farbverbesserungsvorschlag. [7]

Es lässt sich somit sagen, dass es zwar bereits Tools gibt, die bei der Überprüfung von barrierefreien Farbkontrasten helfen, jedoch gibt es kein Tool, welches sowohl browser- und designtool-unabhängig Farbkontraste analysiert und zusätzlich automatisierte Farb-Verbesserungsvorschläge liefert. Daher wird dies im Folgenden mit Hilfe von Gemini umgesetzt.

Konzeption und Entwicklung

Im Folgenden wird zuerst die Konzeption des Tools beschrieben, bevor auf einzelne Komponenten der Entwicklung eingegangen wird.

Konzeption

Im Laufe der Konzeption wurden verschiedene grundlegende Details der Anwendung festgelegt, wie beispielsweise was für eine Art von Anwendung entwickelt werden soll, wie sie aufgebaut sein soll und welche Gemini Version verwendet wird.

In einem ersten Schritt wurde festgelegt, was für eine Art von Anwendung entwickelt werden soll und welche Komponenten im Frontend benötigt werden. Auf Grund der Übersichtlichkeit der dargestellten Informationen wurde sich gegen eine mobile Anwendung und für eine Desktop Anwendung entschieden, um somit eine größere Bildschirmfläche zur Verfügung zu haben. Um jedoch möglichst viele Nutzer erreichen zu können, wurde festgelegt, dass es sich um eine plattformunabhängige Anwendung handeln soll. Bei der Analyse welche Komponenten im Frontend benötigt werden, wurde unterschieden zwischen dem Zustand vor der Analyse und dem Zustand nach der Analyse. Für den Zustand vor der Analyse war das Ergebnis, dass eine Upload-Fläche für Bilder benötigt wird, durch welche auf das Dateisystem zugegriffen werden kann, um Bilder hochzuladen. Zu diesem Zeitpunkt war die Konzeptidee ausschließlich auf zu untersuchende Bilder ausgelegt, bevor später auch Webseite-URLs hinzukamen. Für nach der Analyse wurde festgelegt, dass sowohl das hochgeladene Bild oder ein Bild der eingegebenen Webseite angezeigt werden soll als auch eine übersichtliche Darstellung des von Gemini zurückgelieferten Feedbacks. Als Eingabeformat der Bilder sollten sowohl PNG als auch JPG möglich sein. Bei der übersichtlichen Darstellung des zurückgelieferten Feedbacks sollte dies als Text erfolgen. Dabei sollte sowohl ein allgemeines Feedback zum Farbkonzept gegeben werden als auch eine Auflistung der gefundenen Probleme und ihrer Farb-Verbesserungsvorschläge. Um den Designern und Entwicklern eine möglichst einfache Nutzung der Farb-Verbesserungsvorschläge zu ermöglichen, sollte sowohl der Farbcode der aktuellen Farbe angegeben werden als auch der Farbcode des Verbesserungsvorschlags.

Als einzusetzendes KI-Modell im Hintergrund wurde Gemini gewählt. Gemini wurde gewählt, da es sich mit Hilfe von Vertex AI, einem Teil der Google Cloud Platform, sehr einfach nutzen lässt. [8] Zusätzlich erhalten Neukunden bei Google ein Startguthaben von 300$, welches zur Nutzung von verschiedenen Google Cloud Produkten, wie Vertex AI und Gemini genutzt werden kann. Durch dieses Startguthaben konnten alle Kosten, die durch das Innovationsprojekt entstanden sind, gedeckt werden. Dies hat die Nutzung von Gemini in Kombination mit der Google Cloud Platform für dieses Projekt qualifiziert. [9]

Da es bei der Analyse der Bilder und Webseiten wichtig ist, dass das KI-Modell die enthaltenen Farben möglichst genau erkennt und möglichst zuverlässig in der Erkennung der Farben und der Bestimmung von Farb-Verbesserungsvorschlägen ist, wurde die Gemini Version 2.5 Pro gewählt. Gemini 2.5 Pro ist das zurzeit „leistungsstärkste[s] Denkmodell mit höchstmöglicher Antwortgenauigkeit und modernster Leistung“ [10]. Zudem bietet diese Version die Möglichkeit von strukturierten Ausgaben, was nützlich ist für die Darstellung des erhaltenen Feedbacks im Tool. Ebenso hat es die Fähigkeit interne Denkprozesse durchzuführen vor der Antwort, was hilfreich ist für eine genauere Aussage in der erhaltenen Antwort. [10]

Im zweiten Schritt wurden die Komponenten aus Schritt 1 in einem Paper-Prototyp dargestellt, als Grundlage für die folgende Entwicklung. Dabei wurde in 3 verschiedenen Versionen unterschieden, wobei das Design vor der Analyse immer das Gleiche bleibt. Es ist in Abbildung 1 zu sehen. Auch in diesem Schritt wird die Eingabe-Möglichkeit für eine Webseiten-URL noch nicht mitberücksichtigt, jedoch wird sie später mit implementiert. Die Ausgabe in Version 1 setzt sich, wie in Abbildung 2 zu sehen aus dem Eingabebild und dem textuellen Feedback zusammen. Dabei wird das Eingabebild auf der linken Seite als Orientierung und zur besseren Verständlichkeit des textuellen Feedbacks auf der rechten Seite angezeigt. Das textuelle Feedback unterteilt sich indem erst das allgemeine Feedback angegeben wird und darunter eine Auflistung der einzelnen gefundenen Probleme angegeben wird. Das allgemeine Feedback, welches im Paper-Prototyp noch explizit in Stärken und Schwächen unterteilt wird, wird im späteren Verlauf des Projektes als Kurzer Fließtext angegeben. Bei der Auflistung der einzelnen Probleme ist es wichtig, dass immer das genaue Problem inklusive der Problemstelle benannt wird, ebenso wie der zugehörige Farb-Verbesserungsvorschlag.

Die Version 2 baut auf die Version 1 auf und fügt dieser ein weiteres Feature hinzu. Neben der schriftlichen Ausgabe des Feedbacks erfolgt nun zusätzlich im Bild auf der linken Seite eine farbliche Umrandung der Problemstellen, wie in Abbildung 3 zu sehen. Dies soll zu einer besseren Orientierung und schnelleren Auffindung der Probleme für den Nutzer führen.

Auch wenn nur Version 1 und Version 2 als relevant im Zusammenhang mit dem Umfang dieses Innovationsprojektes gezählt werden, ist auch Version 3 der Vollständigkeit halber aufgeführt und in Abbildung 4 zu sehen. Version 3 unterscheidet sich vom Design von Version 1 und Version 2. Das allgemeine Feedback ist in dieser Version oberhalb des Eingabebildes zu finden. Das Eingabebild dagegen ist mittig des Bildschirms dargestellt. Auch hier sind die Problemstellen mit einer farblichen Umrandung markiert. Im Gegensatz zu Version 1 und 2 sind die einzelnen Probleme nun aber nicht mehr in einer Liste untereinander dargestellt, sondern sie erscheinen als Pop-Up, sobald der Nutzer die zugehörige farbliche Umrandung auswählt.

Entwicklung

Nachdem nun die Konzeption abgeschlossen war, wurde mit der Entwicklung gestartet. Im Kontext dieses Papers wird dabei auf verschiedene relevante Punkte im Rahmen der Entwicklung eingegangen.

Screenshot erstellen

In Kapitel Konzeption wird beschrieben, dass in der Ausgabe nach der Analyse sowohl in Version 1 als auch in Version 2 auf der linken Seite das Eingabebild oder ein Bild der eingegebenen Webseite angezeigt werden soll. Bei der Eingabe eines Bildes ist dies einfach umzusetzen, da hierbei einfach direkt das hochgeladene Bild verwendet werden kann. Bei der Eingabe einer Webseiten-URL ist dies nicht direkt möglich. Um hier trotzdem ein Bild darstellen zu können, muss ein Screenshot der Webseite erstellt werden. Dafür wurde Selenium verwendet. Mit Hilfe von Selenium WebDriver kann ein Chrome-Browser gestartet werden und dank der guten Integration mit Python ist es für dieses Projekt besonders geeignet.

In den gestarteten Browser wird dann die vom User eingegebene URL geladen. Mit der Methode driver.get_screenshot_as_png() wird ein Screenshot der geladenen Webseite erzeugt und als Binärdaten im Arbeitsspeicher zurückgegeben. Da der Screenshot nur in der laufenden Verarbeitung benötigt wird und nicht gespeichert werden soll, ist bewusst diese Methode gewählt worden anstatt driver.get_screenshot_as_file(). [11]

Um sicherzustellen, dass nicht nur der aktuell sichtbare Bereich der Webseite auf dem Screenshot zu sehen ist, sondern die gesamte Webseite, wird mit driver.execute_script(“return document.body.scrollHeight”) die Höhe der kompletten Webseite ermittelt. Diese wird dann in driver.set_window_size() als Fensterhöhe gesetzt, damit der Screenshot über die gesamte Seitenlänge erstellt wird. [12]

CSS extrahieren

Der Screenshot kann jedoch nicht nur zur Darstellung in der Ausgabe genutzt werden, sondern kann auch dem Prompt, der an Gemini gesendet wird, hinzugefügt werden. Der genaue Aufbau des Prompts wird im nächsten Absatz beschrieben. Jedoch wird neben dem Screenshot auch das CSS der Webseite dem Prompt hinzugefügt, da Gemini dieses nicht selbstständig aus der URL rauslesen kann.

Um das CSS der Webseite zu erhalten, wird in einem ersten Schritt mithilfe der Bibliothek BeautifulSoup der HTML-Inhalt der Webseite geparst. Dadurch kann anschließend gezielt auf die <style>- und <link>- Elemente zugegriffen werden. Zuerst werden alle Inline-CSS-Styles über das <style>-Tag extrahiert und in einem String gesammelt. Anschließend werden alle externen CSS-Dateien über den <link>-Tag in Kombination mit dem Attribut rel=“stylesheet“ identifiziert, heruntergeladen und ebenso dem String hinzugefügt.

Prompt

Nachdem nun beschrieben wurde, wie ein Screenshot der Webseite erzeugt wird und wie das CSS extrahiert wird, geht es in diesem Absatz um den eigentlichen Prompt.

Insgesamt werden in diesem Projekt drei verschiedene statische Prompts verwendet für drei unterschiedliche Usecases. Der erste Usecase ist der Fall, wenn der Nutzer ein Bild hochlädt. Der zweite Usecase umfasst den Fall, dass der Nutzer eine URL eingibt und ein Screenshot erzeugt werden kann. Und der dritte Usecase tritt ein, wenn der Nutzer eine URL eingibt, jedoch kein Screenshot erzeugt werden kann. Da die drei Prompts sich nur in Kleinigkeiten unterscheiden ist im Folgenden lediglich der Prompt für das Bild abgebildet, bevor anschließend sowohl der Prompt beschrieben als auch die Unterschiede der drei Usecases hervorgehoben werden.

Der Prompt des Bildes ist sieht folgendermaßen aus:

„Analysiere das Farbkonzept der Webseite gemäß WCAG 2.2 AA und gib das Ergebnis ausschließlich im folgenden JSON-Format zurück. Keine weiteren Erklärungen oder Texte. Schreibe deine Antwort auf Deutsch.

Das Bild hat eine Auflösung von {width} Pixel in der Breite und {height} Pixel in der Höhe.

{{
“general_feedback”: “Maximal 3 kurze Sätze allgemeines Feedback zum Farbkonzept.”,
“problems”: [

{{
“title”: “Problem X”,
“description”: “Was ist das Problem?”,
“location”: “Wo auf der Webseite tritt das Problem auf?”,
“current_color”: “z.B. #FFFFFF”,
“suggested_color”: “z.B. #000000”,
“bounding_box”: [x1, y1, x2, y2]
}}

]
}}

Wichtig: Die bounding_box muss die exakten Pixelkoordinaten [x1, y1, x2, y2] angeben, bezogen auf das gesamte Bild.
– Der Ursprung (0,0) ist die obere linke Ecke des Bildes.
– (x1, y1) ist die obere linke Ecke der Box.
– (x2, y2) ist die untere rechte Ecke der Box.
– Gib die Box so eng wie möglich um das betroffene Element an (z. B. nur um den Text, nicht den ganzen Button oder Bereich).

Wenn keine Lokalisierung möglich ist, setze bounding_box auf null.
Fülle das X bei title mit der Problem-Nummerierung aus der Liste der Probleme.

Wenn keine Probleme existieren, gib eine leere Liste bei “problems” zurück.“

Diesem Prompt wird im Usecase 1 zudem noch das hochgeladene Bild hinzugefügt. Im Usecase 2 wird der erstellte Screenshot und das extrahierte CSS hinzugefügt und im dritten Usecase wird nur das extrahierte CSS angehängt.

Im ersten Abschnitt des Prompts wird Gemini mitgeteilt nach welchem WCAG-Standard analysiert werden soll. Hierbei wurde sich auf WCAG 2.2 AA festgelegt, da dies der von W3C empfohlene Standard ist. [13] Ebenso wird Gemini hier mitgeteilt, dass das Ergebnis im JSON-Format zurückgegeben werden soll. Dadurch wird von der im Kapitel Konzeption erwähnten Möglichkeit von strukturierten Ausgaben Gebrauch gemacht. Dies erleichtert die Darstellung des erhaltenen Ergebnisses. Damit es bei der Darstellung der Antwort zu keinen Problemen kommt, wird dem Prompt zudem hinzugefügt, dass außerhalb der JSON-Antwort keine weiteren Erklärungen gewünscht sind.

Der zweite Absatz ist nur in Usecase 1 und 2 zu finden. Hierbei wird die exakte Größe des hochgeladenen Bildes bzw des erstellten Screenshots in Pixeln angegeben.

Der dritte Absatz gibt das im ersten Absatz bereits angesprochene JSON-Format vor. Hierbei werden die Schlüssel vorgegeben und was als zugehöriger Wert erwartet wird. Dabei lässt sich gut die Unterteilung in das allgemeine Feedback unter dem Schlüssel „general_feedback“ und die Liste mit den gefundenen Problemen unter dem Schlüssel „problems“ erkennen. Jedes Problem wird mit einem Titel versehen, der eine Nummerierung der gefundenen Probleme enthält. Dazu erhält jedes Problem eine Problembeschreibung und die Information, wo das Problem auftritt. Für die Darstellung des bereits angesprochenen Farb-Verbesserungsvorschlags wird sowohl der aktuelle Farbwert als auch der Farbwert des Verbesserungsvorschlages als Hexadezimalfarbcode angegeben. Der letzte geforderte Wert hat den Schlüssel „bounding_box“. Hierbei handelt sich es um die Koordinaten des gefundenen Problems. Wie diese ermittelt werden sollen, wird im vierten Absatz genauer beschrieben. Durch die Rückgabe der Antwort von Gemini als JSON-Format kann im Tool einfach Textoutput im für die Ausgabe gewünschten Format erzeugt werden, da davon ausgegangen werden kann, dass immer dieselbe Form von Antwort erhalten wird.

Wie bereits angesprochen wird im vierten Absatz genauer beschrieben, wie die Bounding Box ermittelt werden soll. Im zweiten Absatz wurde bereits angegeben welche Pixel-Größe das mitgelieferte Bild hat, nun wird zusätzlich definiert, dass die obere linke Ecke des Bildes die Koordinaten (0,0) hat. Ebenso wird angegeben, dass die Werte x1 und y1 für die obere linke Ecke stehen und x2 und y2 die untere rechte Ecke der Bounding Box angeben. Zudem erhält Gemini die Vorgabe die Bounding Box möglichst eng, um das betroffene Element zu legen. Benötigt wird die Bounding Box für die farbliche Markierung in Version 2.

In den Absätzen fünf und sechs werden noch zusätzliche Informationen angegeben, die besagen welche Werte zurückgegeben werden sollen, wenn keine Bounding Box ermittelt werden kann oder wenn keine Barrierefreiheits-Farbprobleme gefunden werden können.

Farbliche Markierungen der Version 2

In vorherigen Kapiteln wurde bereits erwähnt das ein in Version 2 des Tools hinzukommendes Feature eine farbliche Markierung der gefundenen Probleme auf dem angezeigten Bild bzw Screenshot ist. Dafür wird zuerst das Bild an die Klasse ImageDraw aus der Pillow-Bibliothek übergeben, um ein Zeichenobjekt zu erstellen. Darauffolgend wird für jedes gefundene Problem überprüft, ob eine vollständige Bounding Box vorhanden ist. Falls dies der Fall ist, wird ein rotes Rechteck um die betroffene Stelle gezeichnet.

Usertests

Zur Überprüfung der zu anfangs festgelegten Forschungsfragen „Wie zuverlässig kann ein multimodales Sprachmodell wie Gemini die Farbkontraste und Farbgestaltung eines Bildes im Hinblick auf WCAG-Richtlinien bewerten und verbessern?“ und „Wie unterscheiden sich manuelle WCAG-Kontrastprüfungen von automatisierten, KI-basierten Analysen im Hinblick auf Genauigkeit, Zeitaufwand und Nutzerfreundlichkeit?“, wurden im Anschluss an die Entwicklung drei verschiedene Usertests durchgeführt. Im Folgenden werden diese beschrieben und ihre Durchführung ausgewertet.

Beschreibung

Um die Forschungsfragen beantworten zu können wurde ein Usertest für die Genauigkeit des Tools durchgeführt, ein Weiterer um die Zeitersparnis des Tools gegenüber einer händischen Überprüfung zu ermitteln und ein dritter Usertest für die Nutzerfreundlichkeit.

Mit dem Usertest für die Genauigkeit sollten die folgenden Fragen beantwortet werden:

• Wie konsistent ist das Ergebnis des Tools?
• Mit welcher Wahrscheinlichkeit werden alle Fehler gefunden?
• Mit welcher Wahrscheinlichkeit werden Fehler erkannt, die keine Fehler sind?
• Sind alle gegebenen Verbesserungsvorschläge tatsächlich WCAG konform?

Um diese Fragen beantworten zu können wurde der Test-Retest-Ansatz verwendet. Mit diesem Test wird die Konsistenz eines Testobjektes, in diesem Fall das Tool, überprüft, indem der gleiche Test zu unterschiedlichen Zeitpunkten erneut durchgeführt wird. Die Ergebnisse sollten im besten Falle immer die Gleichen sein. [14] Für eine gute Aussagekraft der Ergebnisse wurden für diesen Usertest 10 Bilder und 10 Webseiten getestet. Um die Ergebnisse des Tools zudem mit den tatsächlichen Barrierefreiheits-Farbkontrast-Problemen vergleichen zu können, wurde zudem ein händischer Test für jedes Bild und jede Webseite durchgeführt. Dabei wurden die Bilder und Webseiten im Firefox-Browser geöffnet und die korrekten Farbwerte mit der dort in den Werkzeugen vorhandenen Farbpipette bestimmt. Der Farbkontrast wurde dann mit dem Colour Contrast Analyzer überprüft. Dabei handelt es sich um ein Tool, welches das Kontrastverhältnis zwischen zwei Farbwerten angibt und ebenso, ob die beiden Richtlinien 1.4.3 Kontrast (Minimum) [2] und 1.4.11 Nicht-Text-Kontrast [3], auf die geprüft wird, erfüllt sind. Um die Koordinaten bestimmen zu können wurde das Tool IrfanView verwendet. Die genauen Fragen sind in Anhang Usertest Genauigkeit zu finden.

Der Ustertest zur Zeitersparnis sollte die Frage beantworten

• Wie viel schneller ist das Tool im Vergleich zur manuellen Prüfung?

Um diese Frage zu beantworten, sollte laut Jakob Nielsen ein Test mit 20 verschiedenen Testobjekten durchgeführt werden. [15] Daher wurden für den Test 10 verschiedene Bilder und 10 verschiedene Webseiten getestet. Jedes Bild und jede Webseite wurde dafür einmal händisch getestet und dreimal durch das Tool.

Im dritten Usertest sollte ermittelt werden, die gut Nutzer mit dem Tool zurechtkommen und wie hilfreich es empfunden wird. Laut einer Untersuchung von Nielsen und Landauer sollten für einen solchen Test je 3-5 Personen von den 2-3 wichtigsten Zielgruppen hinzugezogen werden. [16] Da dieses Tool vor allem für Softwareentwickler und UX/UI-Designer entwickelt wurde, wurden als Probanden 4 Softwareentwickler, 3 UX/UI-Designer und zwei Probanden, die in keine der beiden Gruppen passen, ausgewählt. Die Probanden bekamen im Test zwei Aufgaben. In der ersten Aufgabe musste ein Bild hochgeladen werden und in der zweiten Aufgabe sollte eine Webseiten-URL eingegeben werden. Anschließend mussten dann Fragen zu Intuitivität der Aufgabe und zur Qualität der Antwort beantwortet werden. Die genauen Aufgaben und Fragestellungen sind in Anhang Usertest Nutzerfreundlichkeit zu finden.

Auswertung

Der Usertest zur Nutzerfreundlichkeit ergab ein sehr gutes Ergebnis. Aufgabe 1 hat auf einer Skala von 1 bis 5 eine durchschnittliche Intuitivität von 4,78 erreicht, wobei der niedrigste Wert bei 4 lag. Aufgabe 2 hat sogar einen durchschnittlichen Wert von 5 erhalten. Die Frage “Wie empfindest du das erhaltene Ergebnis?“ wurde für Aufgabe 1 mit einem durchschnittlichen Wert von 4,67 bewertet, während Aufgabe 2 lediglich 3,89 erreicht. Die Frage „Fandest du die Problembeschreibung verständlich?“ erzielte dagegen sehr ähnliche Werte mit 4,67 bei Aufgabe 1 und 4,44 bei Aufgabe2. Somit lässt sich sagen, dass zwar die Problembeschreibung bei Bildern und bei Webseiten verständlich formuliert ist, jedoch bei Bildern als hilfreicher empfunden wird als bei Webseiten. In Abbildung 5 sind die Bewertungen der Probanden grafisch dargestellt.

Die Frage, wie das Design des Tools bewertet wird erreichte einen durchschnittlichen Wert von 3,78. Hierbei gibt es jedoch deutliche Unterschiede zwischen den unterschiedlichen Probanden-Gruppen. Während die Gruppe Sonstiges das Design durchschnittlich mit einem Wert von 4,5 bewertet, schneidet das Design bei den UX/UI-Designer mit 3 am schlechtesten ab. Die Probanden-Gruppe Softwareentwickler hat durchschnittlich den Wert 4 vergeben. Auch in den schriftlichen Antworten zeichnet sich dieses Ergebnis ab, da mehrere der Probanden der Probandengruppe UX/UI-Designer das Design als verbesserungswürdig beschrieb. Die Frage, ob das Tool verwendet werden würde, wurde mit 4,11 sehr positiv bewertet. Die Werte schwanken hierbei zwischen 3 und 5.

Daneben wurde zudem angemerkt, dass es für den Nutzer deutlicher erkennbar sein sollte, dass das Tool im Hintergrund am Auswerten des hochgeladenen Bildes oder der eingegebenen Webseite ist, indem beispielsweise eine Sanduhr angezeigt wird. Ebenso wurde gewünscht, dass eine Erklärung bereitgestellt wird, was das Tool macht und wie genau das Kontrastverhältnis berechnet wird. Einer der Probanden hat zudem mehrere Erweiterungsvorschläge geliefert und gewünscht. Darunter fallen zum Beispiel die Möglichkeit, dass die Farb-Verbesserungsvorschläge direkt in einer Vorschau angewendet betrachtet werden können oder auch, dass eine Auswahl an verschiedenen Farb-Verbesserungsvorschlägen geliefert wird. Ein letzter Punkt, der von vielen Probanden angemerkt wurde, ist dass die roten Boxen die Probleme nicht genau umranden. Dieser Aspekt wird auch in der Auswertung des Usertests zur Genauigkeit genauer beleuchtet.

Die Ergebnisse des Usertests zur Genauigkeit waren nicht so positiv, wie die des Usertests zur Nutzerfreundlichkeit. Das Tool weist im Gegensatz zum manuellen Test nur eine durchschnittliche Erkennungsrate von 55,6% auf. In Abbildung 6 sind die genauen Werte des durchschnittlichen Tool-Tests im Vergleich zum händischen Test zu sehen für jedes Bild und jede Webseite. Wichtig zu beachten hierbei ist jedoch, dass in den 55,6% auch False-Positive Probleme enthalten sind. Dabei handelt es sich um vom Tool erkannte Probleme, die in Wirklichkeit jedoch keine Barrierefreiheits-Farbkontrast-Probleme sind. Durchschnittlich liegt die Wahrscheinlichkeit für False-Positive-Ergebnisse bei 27,51%, jedoch gibt es hierbei große Unterschiede zwischen Bildern und Webseiten. Bei Bildern liegt der durchschnittliche Wert nur bei 17,26%, während er bei Webseiten bei 37,76% liegt.

Die bereits im Usertest zur Nutzerfreundlichkeit bemängelten roten Markierungen der gefundenen Probleme, wurden in diesem Usertest genau ausgewertet. Diese Auswertung ergab, dass die Markierungen nur mit einer Wahrscheinlichkeit von 1% exakt das zugehörige Problem umranden. In immerhin 25% der Fälle wird das zugehörige Problem exakt oder zumindest teilweise von der roten Markierung getroffen. Jedoch liegt die Markierung in 61% der Fälle komplett neben dem zugehörigen Problem und in 14% wird für das Problem überhaupt keine Markierung angezeigt. Dieses Ergebnis zeigt, dass Gemini Probleme hat auf Bildern die exakte Position der gefundenen Probleme zu bestimmen. Nur in einem Viertel aller Fälle wird das gefundene Problem mindestens teilweise von der roten Markierung umrandet.

Ein weiterer nicht idealer Wert ist die Wahrscheinlichkeit, mit welcher das Tool den korrekten Farbwert erkennt. Dieser liegt lediglich bei 32,26%, womit bei deutlich über der Hälfte der gefundenen Probleme, nicht der korrekte Farbwert erkannt wird.

Ein eher positiver Wert ist dagegen die WCAG-Konformität der Farb-Verbesserungsvorschläge. Lediglich 17,51% sind nicht WCAG-konform, was zu einer über 80-prozentigen WCAG-Konformität führt. In Abbildung 7 sind die genauen Werte für die einzelnen Bilder und Webseiten aufgeführt.

Ebenso positiv ist wie konsistent das Tool ist, was die Anzahl gefundener Probleme angeht. Dieser Wert liegt bei 76,58%, was für eine sehr gute Konsistenz spricht. Die Werte sind in Abbildung 8 aufgeführt.

Die Auswertung des Usertests für die Zeitersparnis fiel sehr gut aus. Bei den Bildern konnte eine durchschnittliche Zeitersparnis von 89,3% durch das Tool festgestellt werden und bei Webseite sogar eine durchschnittliche Zeitersparnis von 96,7%. Insgesamt gibt das eine durchschnittliche Zeitersparnis von 93,0%. Der spannendste Wert ist hierbei die Betrachtung von Webseite4. Für den händischen Test wurde hier eine Zeit von 54 Minuten und 42 Sekunden benötigt. Das Tool dagegen benötigt im Durchschnitt nur 0 Minuten und 53 Sekunden, was eine Zeitersparnis von 53 Minuten und 49 Sekunden ergibt.

Fazit

Wenn nun abschließend erneut die Forschungsfragen „Wie zuverlässig kann ein multimodales Sprachmodell wie Gemini die Farbkontraste und Farbgestaltung eines Bildes im Hinblick auf WCAG-Richtlinien bewerten und verbessern?“ und „Wie unterscheiden sich manuelle WCAG-Kontrastprüfungen von automatisierten, KI-basierten Analysen im Hinblick auf Genauigkeit, Zeitaufwand und Nutzerfreundlichkeit?“ betrachtet werden, können diese nach Durchführung der Usertests wie folgt beantwortet werden. Bezogen auf die Nutzerfreundlichkeit schneidet das Tool sehr positiv ab, da sowohl die Intuitivität als auch die Verständlichkeit der Problembeschreibung sehr gute Werte erzielten. Ausbaufähig ist das Tool jedoch im Hinblick auf die Genauigkeit. Die Zuverlässigkeit des Tools in diesem Aspekt ist nicht sehr hoch, da lediglich eine durchschnittliche Erkennungsrate von 55,6% besteht und sich darunter noch False-Positive-Probleme befinden. Der größte Schwachpunkt liegt jedoch in der Bestimmung der Position der gefundenen Probleme auf dem Bild. Die roten Markierungen liegen mit einer Wahrscheinlichkeit von 75% nicht mal teilweise auf dem tatsächlichen Problem oder werden sogar überhaupt nicht angezeigt. Da Gemini jedoch auf Texte und nicht auf Bilder spezialisiert ist, kann dies darauf zurückgeführt werden. Im Punkt der Zeitersparnis schneidet das Tool dagegen sehr gut ab mit einer durchschnittlichen Zeitersparnis von über 90%. Zusammenfassend lässt sich also sagen, dass automatisierte, KI-basierte Analysen von WCAG-Kontrastprüfungen mit Gemini im Hinblick auf Genauigkeit schlechter abschneiden als manuelle WCAG-Kontrastprüfungen. Auch im Hinblick auf die Zuverlässigkeit hat ein multimodales Sprachmodell wie Gemini noch Ausbaufähigkeit. Im Hinblick auf den Zeitaufwand schneidet das KI-Tool dagegen deutlich besser ab. Und auch in der Nutzerfreundlichkeit kann das KI-Tool punkten.

Literaturverzeichnis

Anhang

Usertest Genauigkeit

Welches Bild/Webseite wird getestet?

Händische Überprüfung:

• Wie viele Probleme wurden gefunden?
• Welche Probleme wurden gefunden und was sind ihre Koordinaten?

Tool Versuch 1:

• Wie viele Probleme wurden gefunden?
• Welche Probleme wurden gefunden und was sind ihre Koordinaten?
• Sind die erkannten Farbwerte korrekt?
• Sind die Farbverbesserungsvorschläge barrierefrei?

Tool Versuch 2:

• Wie viele Probleme wurden gefunden?
• Welche Probleme wurden gefunden und was sind ihre Koordinaten?
• Sind die erkannten Farbwerte korrekt?
• Sind die Farbverbesserungsvorschläge barrierefrei?

Tool Versuch 3:

• Wie viele Probleme wurden gefunden?
• Welche Probleme wurden gefunden und was sind ihre Koordinaten?
• Sind die erkannten Farbwerte korrekt?
• Sind die Farbverbesserungsvorschläge barrierefrei?

Usertest Nutzerfreundlichkeit

• Allgemeine Angaben:
  • Alter:
  • Geschlecht:
    ☐weiblich
    ☐männlich
    ☐divers
  • Einordnung:
    ☐Softwareentwickler
    ☐UX/UI Designer
    ☐Sonstiges
  • Wie vertraut bist du mit den WCAG-Richtlinien?
    • ☐1 (nicht vertraut)    ☐2     ☐ 3      ☐4       ☐5 (sehr vertraut)
  • Hast du beruflich/im Studium bereits mit Barrierefreiheit zu tun gehabt?
    • ☐ja    ☐nein

• 
  Aufgabe 1: Lade das vorgegebene Bild „Testbild.png“ hoch und sende es ab
  
  
  • Wie intuitiv fandest du die Aufgabe?
    • ☐1 (nicht intuitiv)    ☐2     ☐ 3      ☐4       ☐5 (sehr intuitiv)
  • Wie empfindest du das erhaltene Ergebnis?
    • ☐1 (schlecht/nicht hilfreich)    ☐2     ☐ 3      ☐4       ☐5 (gut/sehr hilfreich)
  • Fandest du die Problem-Beschreibung verständlich?
    • ☐1 (nicht verständlich)    ☐2     ☐ 3      ☐4       ☐5 (sehr verständlich)
  • Wie viele Probleme wurden erkannt?
    •  
  • Hättest du dir noch weitere Hinweise/Informationen in der Antwort gewünscht?
    •  
• Aufgabe 2: Gebe die URL der HdM-Moodle Seite (https://moodle.hdm-stuttgart.de/login/index.php) ein und sende sie ab
  • Wie intuitiv fandest du die Aufgabe?
    • ☐1 (nicht intuitiv)    ☐2     ☐ 3      ☐4       ☐5 (sehr intuitiv)
  • Wie empfindest du das erhaltene Ergebnis?
    • ☐1 (schlecht/nicht hilfreich)    ☐2     ☐ 3      ☐4       ☐5 (gut/sehr hilfreich)
  • Fandest du die Problem-Beschreibung verständlich?
    • ☐1 (nicht verständlich)    ☐2     ☐ 3      ☐4       ☐5 (sehr verständlich)
  • Wie viele Probleme wurden erkannt?
    •  
  • Hättest du dir noch weitere Hinweise/Informationen in der Antwort gewünscht?
    •  
• weitere Fragen:
  • Wie findest du das Design des Tools?
    • ☐1 (schlecht)    ☐2     ☐ 3      ☐4       ☐5 (sehr gut)
  • Würdest du das Tool verwenden?
    • ☐1 (sehr unwahrscheinlich)    ☐2     ☐ 3      ☐4       ☐5 (sehr wahrscheinlich)
  • Hast du Verbesserungswünsche?
    •