{"id":27902,"date":"2025-07-31T23:58:24","date_gmt":"2025-07-31T21:58:24","guid":{"rendered":"https:\/\/blog.mi.hdm-stuttgart.de\/?p=27902"},"modified":"2025-07-31T23:58:26","modified_gmt":"2025-07-31T21:58:26","slug":"ki-gestutzte-ux-ui-implementierung","status":"publish","type":"post","link":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/2025\/07\/31\/ki-gestutzte-ux-ui-implementierung\/","title":{"rendered":"KI-gest\u00fctzte UX\/UI-Implementierung"},"content":{"rendered":"\n

Einleitung<\/a><\/h1>\n\n\n\n

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\u00fctzt. Als Zielgruppe wurden Softwareentwickler und UX\/UI-Designer gew\u00e4hlt. 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\u00e4rkungsgesetz (BFSG), welches den European Accessibility Act (EAA) in das nationale Recht \u00fcberf\u00fchrt. Mit dem BFSG ist festgelegt, welche Barrierefreiheitsanforderungen Produkte und Dienstleistungen, die ab dem 28.06.2025 auf den Markt kommen zu erf\u00fcllen haben. [1] Doch auch innerhalb der Barrierefreiheit gibt es verschiedene Aspekte, die beachtet werden m\u00fcssen. Einer davon sind ausreichende Farbkontraste zwischen beispielsweise der Schriftfarbe eines Textes und dem zugeh\u00f6rigen 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\u00fcssen.<\/p>\n\n\n\n

Im Verlauf des Innovationsprojektes wurde daher ein Tool entwickelt, welches mit Hilfe von Gemini die Farbkontraste von Bildern und Webseiten auf Barrierefreiheit \u00fcberpr\u00fcft. Um die Aussagekraft und Korrektheit des Tools zu validieren wurden zwei Forschungsfragen festgelegt, welche durch Usertests des Tools beantwortet werden. Als Forschungsfragen wurden \u201eWie zuverl\u00e4ssig kann ein multimodales Sprachmodell wie Gemini die Farbkontraste und Farbgestaltung eines Bildes im Hinblick auf WCAG-Richtlinien bewerten und verbessern?\u201c und \u201eWie unterscheiden sich manuelle WCAG-Kontrastpr\u00fcfungen von automatisierten, KI-basierten Analysen im Hinblick auf Genauigkeit, Zeitaufwand und Nutzerfreundlichkeit?\u201c festgelegt.<\/p>\n\n\n\n

Im folgenden Paper wird zuerst auf den theoretischen Hintergrund des Themas eingegangen, bevor die Konzeption und Entwicklung des Tools beschrieben werden. Anschlie\u00dfend folgt die Durchf\u00fchrung und Auswertung der Usertests, bevor das Paper mit der Beantwortung der Forschungsfragen endet.<\/p>\n\n\n\n

Theoretischer Hintergrund und verwandte Tools<\/a><\/h1>\n\n\n\n

In diesem Kapitel werden wichtige theoretische Hintergr\u00fcnde erl\u00e4utert, die ben\u00f6tigt werden, um die folgende Arbeit zu verstehen. Ebenso werden verwandte Tools aufgef\u00fchrt.<\/p>\n\n\n\n

Digitale Barrierefreiheit<\/a><\/h2>\n\n\n\n

Die digitale Barrierefreiheit beschreibt, wie digitale Inhalte und Benutzeroberfl\u00e4chen dargestellt werden sollen, so dass sie f\u00fcr alle Menschen erkennbar und nutzbar sind. Dies umschlie\u00dft sowohl Menschen ohne Beeintr\u00e4chtigungen als auch Menschen mit tempor\u00e4ren und dauerhaften Beeintr\u00e4chtigungen. Bei den Farbkontrasten betrifft die Einhaltung der Barrierefreiheitsstandards vor allem Menschen mit Sehbeeintr\u00e4chtigungen. [4]<\/p>\n\n\n\n

Barrierefreiheits-Richtlinien<\/a><\/h3>\n\n\n\n

Im Rahmen der Barrierefreiheit von Farbkontrasten sind die Richtlinien 1.4.3 Kontrast (Minimum) und 1.4.11 Nicht-Text-Kontrast relevant.<\/p>\n\n\n\n

In der Richtlinie 1.4.3 Kontrast (Minimum) wird festgelegt, dass Texte und Text in Bildern ein Kontrastverh\u00e4ltnis von mindestens 4,5:1 haben muss. Eine Ausnahme hiervon bildet gro\u00dfer Text, der lediglich ein Kontrastverh\u00e4ltnis von mindestens 3:1 ben\u00f6tigt. Ebenso als Ausnahme z\u00e4hlt Text oder Text in Bildern, welcher rein dekorativ oder f\u00fcr niemanden sichtbar oder Teil einer inaktiven Benutzerschnittstelle ist, da hierf\u00fcr keine Kontrastanforderungen herrschen. Ebenso keine Kontrastanforderungen gibt es f\u00fcr die dritte Ausnahme, welche Wortbildmarken bilden, also Text, welcher Part eines Logos oder Markennamen ist. [2]<\/p>\n\n\n\n

Die Richtlinie 1.4.11 Nicht-Text-Kontrast besagt, dass alle Bestandteile der Benutzerschnittstelle und alle grafischen Objekte zu benachbarten Farben mindestens ein Kontrastverh\u00e4ltnis von 3:1 ben\u00f6tigen. Als Bestandteil der Benutzerschnittstelle z\u00e4hlen alle sichtbaren Bedienelemente, wie beispielweise Buttons, Eingabefelder und Links, und auch deren Zustandsanzeigen, wenn deren Erkennbarkeit relevant ist f\u00fcr die Bedienbarkeit. Hierzu z\u00e4hlen aktiv, fokussiert und ausgew\u00e4hlt. Auch hierbei gibt es wieder eine Ausnahme, welche kein Kontrastverh\u00e4ltnis vorgibt, wenn die Bestandteile der Benutzerschnittstelle deaktiviert sind oder wenn die unver\u00e4nderte Standarddarstellung des Browsers genutzt wird. Zu den grafischen Objekten z\u00e4hlen alle Bildbestandteile, welche ben\u00f6tigt werden, um den Inhalt zu verstehen. Beispiele hierf\u00fcr 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\u00fcr sind Heatmaps, in denen mit Farbabstufungen die verschiedenen Daten dargestellt werden. [3]<\/p>\n\n\n\n

Barrierefreiheits-Gesetz<\/a><\/h3>\n\n\n\n

In der Einleitung wurde bereits das Barrierefreiheitsst\u00e4rkungsgesetz (BFSG) erw\u00e4hnt. Dieses Gesetz wurde am 15.06.2022 verabschiedet und \u00fcberf\u00fchrt den European Accessibility Act (EAA) ins nationale Recht. Das BFSG besagt, welche Barrierefreiheitsanforderungen f\u00fcr Produkte und Dienstleistungen, welche entweder nach dem 28.06.2025 auf den Markt gebracht werden oder f\u00fcr Verbraucher erbracht werden, zu erf\u00fcllen sind. Zu den Produkten, f\u00fcr die das BFSG gilt, z\u00e4hlen Hardwaresysteme einschlie\u00dflich ihrer Betriebssysteme, Selbstbedienungsterminals, Verbraucherendger\u00e4te, die einen interaktiven Leistungsumfang haben und f\u00fcr Telekommunikationsdienste oder den Zugang zu audiovisuellen Mediendiensten verwendet werden und E-Book-Leseger\u00e4te. Zu den Dienstleistungen geh\u00f6ren Telekommunikationsdienste, verschiedene Elemente von Personenbef\u00f6rderungsdiensten, wie Webseiten, Apps, elektronische Tickets und die Bereitstellung von Verkehrsinformationen, Bankdienstleistungen f\u00fcr Verbraucher, E-Books mit zugeh\u00f6riger Software und Dienstleistungen im elektronischen Gesch\u00e4ftsverkehr. [1]<\/p>\n\n\n\n

Verwandte Tools<\/a><\/h2>\n\n\n\n

Neben der Theorie zur Barrierefreiheit ist es zudem wichtig zu wissen, welche \u00e4hnlichen Tools bereits existieren. Ein Beispiel daf\u00fcr ist das  Stark-Plugin, welches in verschiedenen Anwendungen und Browsern aktiviert werden kann. Hierzu z\u00e4hlen Figma und Chrome. Als Browser-Plugin bietet das Tool einen automatischen WCAG-Audit, der die aktuelle Webseite auf WCAG-Kriterien pr\u00fcft und in einer \u00dcbersicht die Ergebnisse zur Verf\u00fcgung stellt. Welche WCAG-Kriterien genau gepr\u00fcft werden ist auf der Webseite nicht dokumentiert. [5] Ebenso bietet das Tool die M\u00f6glichkeit h\u00e4ndisch den Kontrast verschiedener Farben zu \u00fcberpr\u00fcfen und bietet hierzu Verbesserungsvorschl\u00e4ge an, die direkt auf die Webseite oder das Design angewendet werden k\u00f6nnen. Das bietet die M\u00f6glichkeit die neuen Farben tempor\u00e4r direkt im aktuellen Design begutachten zu k\u00f6nnen, bevor sie dann h\u00e4ndisch \u00fcbernommen werden. [6] In einem manuellen Test des Tools konnten jedoch vereinzelte M\u00e4ngel festgestellt werden. So gab es Probleme die richtigen Farben auszuw\u00e4hlen und es wurden nicht immer Farb-Verbesserungsvorschl\u00e4ge geliefert. Zudem wichen die Farb-Verbesserungsvorschl\u00e4ge teilweise deutlich von den originalen Farben ab.<\/p>\n\n\n\n

Ein weiteres Tool ist das ARC Toolkit, welches als Browser-Erweiterung verwendet werden kann. Mit dem ARC Toolkit kann eine Barrierefreiheitspr\u00fcfung auf Basis von WCAG 2.0, WCAG 2.1, WCAG 2.2, EN 301 549 und Section 508 durchgef\u00fchrt werden. Ein Teil der \u00dcberpr\u00fcfung ist hierbei auch die \u00dcberpr\u00fcfung auf barrierefreie Farbkontraste. Das Tool liefert hierbei die Information dar\u00fcber an welcher Stelle das Problem liegt und welche Richtlinie nicht erf\u00fcllt wird. Es liefert jedoch keinen Farbverbesserungsvorschlag. [7]<\/p>\n\n\n\n

Es l\u00e4sst sich somit sagen, dass es zwar bereits Tools gibt, die bei der \u00dcberpr\u00fcfung von barrierefreien Farbkontrasten helfen, jedoch gibt es kein Tool, welches sowohl browser- und designtool-unabh\u00e4ngig Farbkontraste analysiert und zus\u00e4tzlich automatisierte Farb-Verbesserungsvorschl\u00e4ge liefert. Daher wird dies im Folgenden mit Hilfe von Gemini umgesetzt.<\/p>\n\n\n\n

Konzeption und Entwicklung<\/a><\/h1>\n\n\n\n

Im Folgenden wird zuerst die Konzeption des Tools beschrieben, bevor auf einzelne Komponenten der Entwicklung eingegangen wird.<\/p>\n\n\n\n

<\/a><\/a>Konzeption<\/h2>\n\n\n\n

Im Laufe der Konzeption wurden verschiedene grundlegende Details der Anwendung festgelegt, wie beispielsweise was f\u00fcr eine Art von Anwendung entwickelt werden soll, wie sie aufgebaut sein soll und welche Gemini Version verwendet wird.<\/p>\n\n\n\n

In einem ersten Schritt wurde festgelegt, was f\u00fcr eine Art von Anwendung entwickelt werden soll und welche Komponenten im Frontend ben\u00f6tigt werden. Auf Grund der \u00dcbersichtlichkeit der dargestellten Informationen wurde sich gegen eine mobile Anwendung und f\u00fcr eine Desktop Anwendung entschieden, um somit eine gr\u00f6\u00dfere Bildschirmfl\u00e4che zur Verf\u00fcgung zu haben. Um jedoch m\u00f6glichst viele Nutzer erreichen zu k\u00f6nnen, wurde festgelegt, dass es sich um eine plattformunabh\u00e4ngige Anwendung handeln soll. Bei der Analyse welche Komponenten im Frontend ben\u00f6tigt werden, wurde unterschieden zwischen dem Zustand vor der Analyse und dem Zustand nach der Analyse. F\u00fcr den Zustand vor der Analyse war das Ergebnis, dass eine Upload-Fl\u00e4che f\u00fcr Bilder ben\u00f6tigt wird, durch welche auf das Dateisystem zugegriffen werden kann, um Bilder hochzuladen. Zu diesem Zeitpunkt war die Konzeptidee ausschlie\u00dflich auf zu untersuchende Bilder ausgelegt, bevor sp\u00e4ter auch Webseite-URLs hinzukamen. F\u00fcr nach der Analyse wurde festgelegt, dass sowohl das hochgeladene Bild oder ein Bild der eingegebenen Webseite angezeigt werden soll als auch eine \u00fcbersichtliche Darstellung des von Gemini zur\u00fcckgelieferten Feedbacks. Als Eingabeformat der Bilder sollten sowohl PNG als auch JPG m\u00f6glich sein. Bei der \u00fcbersichtlichen Darstellung des zur\u00fcckgelieferten 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\u00e4ge. Um den Designern und Entwicklern eine m\u00f6glichst einfache Nutzung der Farb-Verbesserungsvorschl\u00e4ge zu erm\u00f6glichen, sollte sowohl der Farbcode der aktuellen Farbe angegeben werden als auch der Farbcode des Verbesserungsvorschlags.<\/p>\n\n\n\n

Als einzusetzendes KI-Modell im Hintergrund wurde Gemini gew\u00e4hlt. Gemini wurde gew\u00e4hlt, da es sich mit Hilfe von Vertex AI, einem Teil der Google Cloud Platform, sehr einfach nutzen l\u00e4sst. [8] Zus\u00e4tzlich 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\u00fcr dieses Projekt qualifiziert. [9]<\/p>\n\n\n\n

Da es bei der Analyse der Bilder und Webseiten wichtig ist, dass das KI-Modell die enthaltenen Farben m\u00f6glichst genau erkennt und m\u00f6glichst zuverl\u00e4ssig in der Erkennung der Farben und der Bestimmung von Farb-Verbesserungsvorschl\u00e4gen ist, wurde die Gemini Version 2.5 Pro gew\u00e4hlt. Gemini 2.5 Pro ist das zurzeit \u201eleistungsst\u00e4rkste[s] Denkmodell mit h\u00f6chstm\u00f6glicher Antwortgenauigkeit und modernster Leistung\u201c [10]. Zudem bietet diese Version die M\u00f6glichkeit von strukturierten Ausgaben, was n\u00fctzlich ist f\u00fcr die Darstellung des erhaltenen Feedbacks im Tool. Ebenso hat es die F\u00e4higkeit interne Denkprozesse durchzuf\u00fchren vor der Antwort, was hilfreich ist f\u00fcr eine genauere Aussage in der erhaltenen Antwort. [10]<\/p>\n\n\n\n

Im zweiten Schritt wurden die Komponenten aus Schritt 1 in einem Paper-Prototyp dargestellt, als Grundlage f\u00fcr 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\u00f6glichkeit f\u00fcr eine Webseiten-URL noch nicht mitber\u00fccksichtigt, jedoch wird sie sp\u00e4ter 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\u00e4ndlichkeit 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\u00e4rken und Schw\u00e4chen unterteilt wird, wird im sp\u00e4teren Verlauf des Projektes als Kurzer Flie\u00dftext angegeben. Bei der Auflistung der einzelnen Probleme ist es wichtig, dass immer das genaue Problem inklusive der Problemstelle benannt wird, ebenso wie der zugeh\u00f6rige Farb-Verbesserungsvorschlag.<\/p>\n\n\n\n

\"\"<\/a><\/figure>\n\n\n\n
Abbildung 1: Paper-Prototyp vor der Analyse<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
\"\"<\/a><\/figure>\n\n\n\n
Abbildung 2: Paper-Prototyp nach der Analyse in Version 1<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

Die Version 2 baut auf die Version 1 auf und f\u00fcgt dieser ein weiteres Feature hinzu. Neben der schriftlichen Ausgabe des Feedbacks erfolgt nun zus\u00e4tzlich 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\u00fcr den Nutzer f\u00fchren.<\/p>\n\n\n\n

\"\"<\/a><\/figure>\n\n\n\n
Abbildung 3: Paper-Prototyp nach der Analyse in Version 2<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

Auch wenn nur Version 1 und Version 2 als relevant im Zusammenhang mit dem Umfang dieses Innovationsprojektes gez\u00e4hlt werden, ist auch Version 3 der Vollst\u00e4ndigkeit halber aufgef\u00fchrt 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\u00f6rige farbliche Umrandung ausw\u00e4hlt.<\/p>\n\n\n\n

\"\"<\/a><\/figure>\n\n\n\n
Abbildung 4: Paper-Prototyp nach der Analyse in Version 3<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

Entwicklung<\/a><\/h2>\n\n\n\n

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.<\/p>\n\n\n\n

Screenshot erstellen<\/a><\/h3>\n\n\n\n

In Kapitel Konzeption<\/a> 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\u00f6glich. Um hier trotzdem ein Bild darstellen zu k\u00f6nnen, muss ein Screenshot der Webseite erstellt werden. Daf\u00fcr wurde Selenium verwendet. Mit Hilfe von Selenium WebDriver kann ein Chrome-Browser gestartet werden und dank der guten Integration mit Python ist es f\u00fcr dieses Projekt besonders geeignet.<\/p>\n\n\n\n

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\u00e4rdaten im Arbeitsspeicher zur\u00fcckgegeben. Da der Screenshot nur in der laufenden Verarbeitung ben\u00f6tigt wird und nicht gespeichert werden soll, ist bewusst diese Methode gew\u00e4hlt worden anstatt driver.get_screenshot_as_file(). [11]<\/p>\n\n\n\n

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\u00f6he der kompletten Webseite ermittelt. Diese wird dann in driver.set_window_size() als Fensterh\u00f6he gesetzt, damit der Screenshot \u00fcber die gesamte Seitenl\u00e4nge erstellt wird. [12]<\/p>\n\n\n\n

CSS extrahieren<\/a><\/h3>\n\n\n\n

Der Screenshot kann jedoch nicht nur zur Darstellung in der Ausgabe genutzt werden, sondern kann auch dem Prompt, der an Gemini gesendet wird, hinzugef\u00fcgt werden. Der genaue Aufbau des Prompts wird im n\u00e4chsten Absatz beschrieben. Jedoch wird neben dem Screenshot auch das CSS der Webseite dem Prompt hinzugef\u00fcgt, da Gemini dieses nicht selbstst\u00e4ndig aus der URL rauslesen kann.<\/p>\n\n\n\n

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\u00dfend gezielt auf die <style>- und <link>- Elemente zugegriffen werden. Zuerst werden alle Inline-CSS-Styles \u00fcber das <style>-Tag extrahiert und in einem String gesammelt. Anschlie\u00dfend werden alle externen CSS-Dateien \u00fcber den <link>-Tag in Kombination mit dem Attribut rel=\u201cstylesheet\u201c identifiziert, heruntergeladen und ebenso dem String hinzugef\u00fcgt.<\/p>\n\n\n\n

<\/a><\/a>Prompt<\/h3>\n\n\n\n

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.<\/p>\n\n\n\n

Insgesamt werden in diesem Projekt drei verschiedene statische Prompts verwendet f\u00fcr drei unterschiedliche Usecases. Der erste Usecase ist der Fall, wenn der Nutzer ein Bild hochl\u00e4dt. 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\u00fcr das Bild abgebildet, bevor anschlie\u00dfend sowohl der Prompt beschrieben als auch die Unterschiede der drei Usecases hervorgehoben werden.<\/p>\n\n\n\n

Der Prompt des Bildes ist sieht folgenderma\u00dfen aus:<\/p>\n\n\n\n

\u201eAnalysiere das Farbkonzept der Webseite gem\u00e4\u00df WCAG 2.2 AA und gib das Ergebnis ausschlie\u00dflich im folgenden JSON-Format zur\u00fcck. Keine weiteren Erkl\u00e4rungen oder Texte. Schreibe deine Antwort auf Deutsch.<\/em><\/p>\n\n\n\n

Das Bild hat eine Aufl\u00f6sung von {width} Pixel in der Breite und {height} Pixel in der H\u00f6he.<\/em><\/p>\n\n\n\n

{{
“general_feedback”: “Maximal 3 kurze S\u00e4tze allgemeines Feedback zum Farbkonzept.”,
“problems”: [<\/em><\/p>\n\n\n\n

{{
“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]
}}<\/em><\/p>\n\n\n\n

]
}}<\/em><\/p>\n\n\n\n

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\u00f6glich um das betroffene Element an (z. B. nur um den Text, nicht den ganzen Button oder Bereich).<\/em><\/p>\n\n\n\n

Wenn keine Lokalisierung m\u00f6glich ist, setze bounding_box auf null.
F\u00fclle das X bei title mit der Problem-Nummerierung aus der Liste der Probleme.<\/em><\/p>\n\n\n\n

Wenn keine Probleme existieren, gib eine leere Liste bei “problems” zur\u00fcck.\u201c<\/em><\/p>\n\n\n\n

Diesem Prompt wird im Usecase 1 zudem noch das hochgeladene Bild hinzugef\u00fcgt. Im Usecase 2 wird der erstellte Screenshot und das extrahierte CSS hinzugef\u00fcgt und im dritten Usecase wird nur das extrahierte CSS angeh\u00e4ngt.<\/p>\n\n\n\n

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\u00fcckgegeben werden soll. Dadurch wird von der im Kapitel Konzeption erw\u00e4hnten M\u00f6glichkeit 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\u00fcgt, dass au\u00dferhalb der JSON-Antwort keine weiteren Erkl\u00e4rungen gew\u00fcnscht sind.<\/p>\n\n\n\n

Der zweite Absatz ist nur in Usecase 1 und 2 zu finden. Hierbei wird die exakte Gr\u00f6\u00dfe des hochgeladenen Bildes bzw des erstellten Screenshots in Pixeln angegeben.<\/p>\n\n\n\n

Der dritte Absatz gibt das im ersten Absatz bereits angesprochene JSON-Format vor. Hierbei werden die Schl\u00fcssel vorgegeben und was als zugeh\u00f6riger Wert erwartet wird. Dabei l\u00e4sst sich gut die Unterteilung in das allgemeine Feedback unter dem Schl\u00fcssel \u201egeneral_feedback\u201c und die Liste mit den gefundenen Problemen unter dem Schl\u00fcssel \u201eproblems\u201c erkennen. Jedes Problem wird mit einem Titel versehen, der eine Nummerierung der gefundenen Probleme enth\u00e4lt. Dazu erh\u00e4lt jedes Problem eine Problembeschreibung und die Information, wo das Problem auftritt. F\u00fcr 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\u00fcssel \u201ebounding_box\u201c. Hierbei handelt sich es um die Koordinaten des gefundenen Problems. Wie diese ermittelt werden sollen, wird im vierten Absatz genauer beschrieben. Durch die R\u00fcckgabe der Antwort von Gemini als JSON-Format kann im Tool einfach Textoutput im f\u00fcr die Ausgabe gew\u00fcnschten Format erzeugt werden, da davon ausgegangen werden kann, dass immer dieselbe Form von Antwort erhalten wird.<\/p>\n\n\n\n

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\u00f6\u00dfe das mitgelieferte Bild hat, nun wird zus\u00e4tzlich definiert, dass die obere linke Ecke des Bildes die Koordinaten (0,0) hat. Ebenso wird angegeben, dass die Werte x1 und y1 f\u00fcr die obere linke Ecke stehen und x2 und y2 die untere rechte Ecke der Bounding Box angeben. Zudem erh\u00e4lt Gemini die Vorgabe die Bounding Box m\u00f6glichst eng, um das betroffene Element zu legen. Ben\u00f6tigt wird die Bounding Box f\u00fcr die farbliche Markierung in Version 2<\/a>.<\/p>\n\n\n\n

In den Abs\u00e4tzen f\u00fcnf und sechs werden noch zus\u00e4tzliche Informationen angegeben, die besagen welche Werte zur\u00fcckgegeben werden sollen, wenn keine Bounding Box ermittelt werden kann oder wenn keine Barrierefreiheits-Farbprobleme gefunden werden k\u00f6nnen.<\/p>\n\n\n\n

<\/a><\/a>Farbliche Markierungen der Version 2<\/h3>\n\n\n\n

In vorherigen Kapiteln wurde bereits erw\u00e4hnt das ein in Version 2 des Tools hinzukommendes Feature eine farbliche Markierung der gefundenen Probleme auf dem angezeigten Bild bzw Screenshot ist. Daf\u00fcr wird zuerst das Bild an die Klasse ImageDraw aus der Pillow-Bibliothek \u00fcbergeben, um ein Zeichenobjekt zu erstellen. Darauffolgend wird f\u00fcr jedes gefundene Problem \u00fcberpr\u00fcft, ob eine vollst\u00e4ndige Bounding Box vorhanden ist. Falls dies der Fall ist, wird ein rotes Rechteck um die betroffene Stelle gezeichnet.<\/p>\n\n\n\n

Usertests<\/a><\/h1>\n\n\n\n

Zur \u00dcberpr\u00fcfung der zu anfangs festgelegten Forschungsfragen \u201eWie zuverl\u00e4ssig kann ein multimodales Sprachmodell wie Gemini die Farbkontraste und Farbgestaltung eines Bildes im Hinblick auf WCAG-Richtlinien bewerten und verbessern?\u201c und \u201eWie unterscheiden sich manuelle WCAG-Kontrastpr\u00fcfungen von automatisierten, KI-basierten Analysen im Hinblick auf Genauigkeit, Zeitaufwand und Nutzerfreundlichkeit?\u201c, wurden im Anschluss an die Entwicklung drei verschiedene Usertests durchgef\u00fchrt. Im Folgenden werden diese beschrieben und ihre Durchf\u00fchrung ausgewertet.<\/p>\n\n\n\n

Beschreibung<\/a><\/h2>\n\n\n\n

Um die Forschungsfragen beantworten zu k\u00f6nnen wurde ein Usertest f\u00fcr die Genauigkeit des Tools durchgef\u00fchrt, ein Weiterer um die Zeitersparnis des Tools gegen\u00fcber einer h\u00e4ndischen \u00dcberpr\u00fcfung zu ermitteln und ein dritter Usertest f\u00fcr die Nutzerfreundlichkeit.<\/p>\n\n\n\n

Mit dem Usertest f\u00fcr die Genauigkeit sollten die folgenden Fragen beantwortet werden:<\/p>\n\n\n\n