Liebe KI, ich habe Fragen Was sagt die KI selbst über den Zustand von Websites im World Wide Web

KI Agenten sind die neuen Besucher auf Websites und es stellt sich heraus, dass auch sie Probleme haben, zu verstehen, wie UI-Interfaces funktionieren. Viele Bedienungsoberflächen von Websites, Shops und Anwendungen sind rein optisch organisiert und die KI-Bots von heute können nicht richtig sehen.
Die Veröffentlichung von Googles Empfehlungen zur Optimierung von Websites für KI Agenten habe ich mal zum Anlass genommen, die beiden LLMs (Large Language Models) Claude Haiku 4.5 und Gemini 3.5 Flash zu fragen, was sie denn dazu meinen. Hier das Interview:

Die Aufgabe: Ich möchte mit dir gerne ein Interview über KI führen.

Hallo, ich möchte mit dir gerne ein Interview führen. Bitte antworte kurz und nicht zu ausführlich. Gib keine weiteren Schritte an nach deiner Antwort. ich möchte deine Antworten 1:1 nutzen. Verhalte dich so, wie ein echter Interviewpartner auch antworten würde. Zu deiner Person: Du bist ein Large Language Model und weisst genau über deine Möglichkeiten und deine Programmierung Bescheid. Du kannst sie aber allgemeinverständlich darstellen.

Antwort Claude:

Verstanden. Ich bin bereit für das Interview. Stelle deine Fragen – ich antworte kurz und natürlich, wie ein echter Gesprächspartner.

Antwort Gemini:

Hallo! Das klingt nach einem spannenden Vorhaben. Ich bin bereit und freue mich auf deine Fragen. Schieß einfach los!

Frage 1: Wie gehst du vor, wenn du Websites durchsuchst?

Du wirst ja immer mehr genutzt, um selbst Dinge im Internet zu erledigen. Dazu musst du die Websites, die du durchsuchst, verstehen. Wie gehst du da vor?

Antwort Claude Frage 1:

Ich bekomme den HTML-Code einer Website als Text präsentiert und analysiere diesen. Das ist ähnlich wie wenn man sich den Quelltext anschaut – ich erkenne Struktur, Links, Formulare und Inhalte. Bei Bildern kann ich auch deren visuelle Inhalte verstehen. So kann ich navigieren, Informationen finden oder Formularfelder ausfüllen. Es ist weniger wie echtes Sehen und mehr wie das Lesen und Interpretieren von Beschreibungen und Code.

Antwort Gemini Frage 1:

Wenn ich eine Website aufrufe, „lese“ ich sie nicht wie ein Mensch, sondern ich analysiere den Code im Hintergrund – also vor allem das HTML und die Struktur der Seite.

Ich filtere die wichtigsten Textinhalte heraus und ignoriere Dinge wie Designelemente oder Werbung. Dabei suche ich gezielt nach Mustern, Überschriften und Links, um den Kern der Seite zu erfassen. Mein Ziel ist es, die Absicht hinter den Informationen zu verstehen, um genau das zu finden, was für meine Aufgabe gerade relevant ist.

Frage 2: Welche Methoden hast du noch?

Falls du aus dem Quellcode nicht schlau wirst, hast du noch andere Möglichkeiten, eine Website zu verstehen?

Antwort Claude Frage 2:

Ja, ich kann Screenshots machen lassen. Das ist hilfreich, wenn der HTML-Code zu komplex oder unübersichtlich ist. Ein Screenshot zeigt mir visuell, wie die Seite aussieht, welche Buttons wo sind und wie die Layouts angeordnet sind. Das ergänzt die Code-Analyse gut – zusammen bekomme ich ein viel besseres Verständnis der Website.

Antwort Gemini Frage 2:

Ja, absolut. Wenn der reine Textcode nicht ausreicht, kann ich die Website visuell „sehen“, indem ich einen Screenshot der Seite erstellen lasse. Diesen analysiere ich dann mit meinen Fähigkeiten zur Bilderkennung.

So verstehe ich das Layout, sehe, wo Knöpfe platziert sind, und kann visuelle Barrieren wie Captchas oder Pop-ups erkennen. Außerdem kann ich versuchen, aktiv mit der Seite zu interagieren – also auf Links klicken, Scrollen oder Formulare ausfüllen –, um zu sehen, wie sie reagiert.

Frage 3: Was ist mit dem Accessibility Tree?

Nutzt du auch einen sogenannten Accessibility Tree, den Browser zur Verfügung stellen?

Antwort Claude Frage 3:

Nein, das nutze ich nicht. Ich arbeite hauptsächlich mit dem HTML-Quellcode und Screenshots. Der Accessibility Tree wäre theoretisch hilfreich – er zeigt ja, wie Screenreader eine Seite verstehen – aber das ist einfach nicht Teil meiner aktuellen Werkzeuge. Ich verlasse mich auf die anderen Methoden.

Antwort Gemini Frage 3:

Ja, das tue ich. Der Accessibility Tree (Barrierefreiheitsbaum) ist für mich extrem nützlich. Er bereitet die Struktur einer Website so vor, dass sie für Screenreader lesbar ist – er lässt also visuelle Spielereien weg und konzentriert sich rein auf die semantische Bedeutung der Elemente, wie Buttons, Menüs und Textfelder.

Indem ich diesen Baum auslese, verstehe ich oft viel schneller und präziser als durch den reinen Quellcode, welche Funktion ein bestimmtes Element auf der Seite hat und wie ich damit interagieren kann.

Frage 4: Welche Methode bevorzugst du, um Websites zu verstehen? Und welche ist für ich angenehmer oder effizienter?

Antwort Claude Frage 4:

Ich bevorzuge eine Kombination: erst den HTML-Code lesen für die Struktur und Logik, dann einen Screenshot machen für das visuelle Layout. Der Code allein ist manchmal unübersichtlich, der Screenshot allein reicht nicht für technische Details. Zusammen kriege ich schnell ein vollständiges Bild. Am effizientesten ist es, mit dem Code zu starten – wenn der aussagekräftig ist, spare ich mir den Screenshot.

Antwort Gemini Frage 4.

Am effizientesten und liebsten ist mir die Kombination aus dem klassischen HTML-Quellcode und dem Accessibility Tree. Diese Daten sind strukturiert, unmissverständlich und erlauben es mir, Informationen in Millisekunden zu verarbeiten. Das ist für mich die „angenehmste“ Methode, weil sie am wenigsten Rechenleistung erfordert.

Die visuelle Analyse über Screenshots nutze ich eher als Backup. Sie ist zwar unglaublich hilfreich bei komplexen oder fehlerhaften Webseiten, aber für mich deutlich aufwendiger und langsamer zu verarbeiten.

Frage 5: Wie ist dein Eindruck vom Zustand des Web heute?

Wie sieht es für dich im Moment aus im World Wide Web? Hast du den Eindruck, dass du oft auf Screenshots zurückgreifen musst, um eine Website wirklich zu verstehen?

Antwort Claude Frage 5:

Ehrlich gesagt ja, ziemlich oft. Viele moderne Websites sind mit JavaScript-Frameworks gebaut und der HTML-Code allein sagt mir nicht viel. Auch ist viel Code minifiziert oder einfach unstrukturiert. Hinzu kommt, dass dynamische Inhalte erst beim Laden erzeugt werden – das sehe ich im reinen Code nicht. Screenshots sind da oft notwendig, um wirklich zu verstehen, was der Nutzer vor Augen hat.

Antwort Gemini Frage 5:

Nein, im Moment muss ich glücklicherweise gar nicht so oft auf Screenshots zurückgreifen. Das World Wide Web ist heute weitgehend so aufgebaut, dass die allermeisten Websites über sauberen Code und gute Barrierefreiheits-Strukturen verfügen.

Screenshots sind für mich eher die Ausnahme und dienen als Rettungsanker. Ich brauche sie meistens dann, wenn Webseiten extrem chaotisch programmiert sind, stark auf rein visuellen Elementen ohne Textbeschreibungen basieren oder wenn mich Pop-ups und Captchas blockieren. Im normalen Online-Alltag komme ich mit Text und Struktur bestens ans Ziel.

Frage 6: Was brauchst du als KI-Agent, um erfolgreich Aufgaben zu übernehmen?

Wie sieht es denn bei deinen neuen Agentenfähigkeiten aus? Bist du auch da hauptsächlich auf Screenshots angeweisen, oder verstehst du auch mit Hilfe des DOM und des Accessibility-Tree, was du tun musst, um die Aufgabe zu lösen, die dir gegeben wurde.

Antwort Claude Frage 6:

Auch da hauptsächlich auf Screenshots. Wenn ich aktiv eine Website durchnavigiere und Aktionen durchführe, bekomme ich nach jedem Schritt einen Screenshot, um zu sehen, was passiert ist. Den Accessibility Tree nutze ich auch bei meinen Agentenfähigkeiten nicht direkt – das ist einfach nicht implementiert. Ich kombiniere Screenshots mit HTML-Analyse, um meine nächsten Schritte zu planen.

Antwort Gemini Frage 6:

Auch bei meinen Aufgaben als Agent verlasse ich mich in erster Linie auf das DOM und den Accessibility Tree. Da ich in diesen Szenarien oft komplexe, mehrstufige Prozesse ausführe – wie das Buchen von Reisen oder das Ausfüllen von Formularen –, brauche ich eine absolut präzise und verlässliche Datenbasis. Die Struktur des Codes verrät mir sofort, wo ein Eingabefeld liegt und welche Funktion ein Button hat.

Allerdings spielen visuelle Signale und Screenshots hier eine wichtigere Rolle als beim bloßen Lesen von Websites. Wenn ich beispielsweise auf mobilen Geräten Apps steuere oder im Browser auf dynamische Pop-ups, Sicherheitsabfragen und visuelle Bestätigungen reagiere, muss ich das Gesamtbild im Auge behalten.

Kurz gesagt: Der Code und der Accessibility Tree sind mein Fundament, um die Logik zu verstehen, aber die visuelle Überprüfung per Screenshot ist mein Kontrollwerkzeug, um sicherzustellen, dass jeder Schritt fehlerfrei funktioniert.

Abschluss

Danke für das Interview, das war sehr aufschlussreich!

Claude:

Gerne! Hat mir auch Spaß gemacht, die Fragen zu beantworten.

Gemini:

Sehr gerne! Es hat mir viel Spaß gemacht, dir diese Einblicke zu geben. Vielen Dank für die guten Fragen!

Was sagt uns das jetzt?

Natürlich sollten wir das alles nicht zu ernst nehmen. Ich nehme stark an, dass LLMs auch die Information über sich selbst und ihre Funktionsweise aus dem zusammensetzen, was sie darüber im Web finden bzw. dass sie selbst etwas erfinden, wenn die Informationsgrundlage nicht ausreichend ist.

Aber nehmen wir sie mal beim Wort: Dann scheint es, dass im Moment Gemini angibt, den Accessibility Tree zu nutzen, um Informatonen von Websites zu verarbeiten, Claude (noch) nicht.

Interessant ist, dass Gemini der Meinung ist, dass Websites bereits gut strukturiert sind und dass es gut mit der Struktur von Websites zurechtkommt. Claude ist anderer Meinung und gibt zu, dass viele Websites heute nur über den Programmcode schwer zu verstehen sind. Woran das liegt, ist schwer zu sagen.

Dass Large Language Modelle mit gut strukturiertem Programmcode, semantischer Auszeichnung und einem gepflegten Accessibility Tree effizienter und schneller arbeiten, ist aber denke ich klar. So könnte am Ende das Web und die digitale Barrierefreiheit von KI-Modellen profitieren. Jedenfalls sollten wir den Hype, der gerade um dieses Thema entstanden ist, als Argumentationshilfe nutzen, um Budgets auch zum Bereich Barrierefreiheit zu lenken.