Agent-Readiness: Kann eine KI Ihre Website benutzen?

Ein Programm, das den Text einer Seite liest, die Schaltfläche darauf aber nicht als Schaltfläche erkennt, steht davor wie ein Besucher vor einer Tür ohne Klinke. Es weiß, was drinsteht, und kommt trotzdem nicht hinein. Genau diese Lücke beschreibt ein Erfolgskriterium der Web Content Accessibility Guidelines in der Fassung 2.2: Für alle Bedienelemente der Benutzeroberfläche — genannt sind unter anderem Formularelemente, Links und von Skripten erzeugte Komponenten — müssen Name und Rolle maschinell bestimmbar sein, vom Nutzer setzbare Zustände, Eigenschaften und Werte müssen sich programmatisch setzen lassen, und Änderungen daran müssen für User Agents einschließlich Hilfstechnologien erkennbar sein. Das ist Erfolgskriterium 4.1.2 der Stufe A.

Die Norm ordnet dieses Kriterium selbst ein, und die Einordnung wird gern überlesen. Es richte sich in erster Linie an Autorinnen und Autoren, die eigene Bedienelemente entwickeln oder skripten; Standard-HTML-Steuerelemente erfüllten es bereits, wenn man sie spezifikationsgemäß verwendet. Der aufwendige Teil entsteht also dort, wo eine Schaltfläche kein Schaltflächenelement ist, sondern ein nachgebautes.

Diese Anforderungen stammen nicht aus der KI-Welt. Die WCAG 2.2 sagt von sich, sie definiere, wie Webinhalte für Menschen mit Behinderungen zugänglicher werden, und zählt dabei ein breites Feld auf — visuelle, auditive, körperliche, sprachliche, kognitive, sprachbezogene, lernbezogene und neurologische Behinderungen. Wer diese Kriterien erfüllt, tut das zuerst für Menschen. Ob ein Programm davon etwas hat, steht in dem Dokument nicht.

1. 01 · Lesen

   Was steht auf der Seite?

   Erfolgskriterium 1.3.1 der Stufe A verlangt, dass Information, Struktur und Beziehungen, die über die Darstellung vermittelt werden, entweder programmatisch bestimmbar sind oder in Textform verfügbar. Die beiden Wege stehen gleichrangig nebeneinander, verbunden durch ein Oder — wer nur den ersten nennt, gibt die Norm strenger wieder, als sie ist. Eine Reihenfolge gegenüber den Bedienkriterien stellt das Dokument dabei nicht auf; dass hier die erste Stufe steht, ist unsere Sortierung.

2. 02 · Erkennen

   Was davon ist ein Bedienelement?

   Erfolgskriterium 4.1.2 der Stufe A verlangt für jedes Bedienelement einen maschinell bestimmbaren Namen und eine maschinell bestimmbare Rolle. Ein Feld, das aussieht wie ein Auswahlfeld, aber keines ist, hat für ein Programm keinen Namen und keine Rolle. Für den Menschen an der Tastatur ist das dieselbe Hürde: Auch ein Screenreader kann nur ansagen, was ausgezeichnet ist.

3. 03 · Handeln

   Lässt sich das Element betätigen?

   Erfolgskriterium 2.1.1 der Stufe A verlangt, dass die Funktionalität des Inhalts über eine Tastaturschnittstelle bedienbar ist, ohne dass es auf die Zeitabstände einzelner Anschläge ankommt. Das Kriterium führt dazu eine Ausnahme für Eingaben, die vom Bewegungspfad abhängen. Und es verbietet die Maus nicht: Eine eigene Anmerkung hält ausdrücklich fest, dass Mauseingabe und andere Eingabearten zusätzlich zur Tastaturbedienung weder untersagt noch entmutigt werden sollen.

4. 04 · Zurücklesen

   Ist es passiert?

   Erfolgskriterium 4.1.3 der Stufe AA verlangt, dass in Inhalten, die mit Auszeichnungssprachen umgesetzt sind, Statusmeldungen über Rolle oder Eigenschaften programmatisch bestimmbar sind — und zwar so, dass Hilfstechnologien sie darstellen können, ohne dass der Fokus dorthin springt. Ein grüner Balken ohne Text erfüllt das nicht. Wer den Abschluss nur zeigt und nicht benennt, lässt die letzte Stufe offen.

Anthropics Dokumentation zum Browser-Werkzeug beschreibt eine Arbeitsweise, die genau zwischen Struktur und Bild unterscheidet. Das Werkzeug — in der Dokumentation unter der Kennung browser_toolset_20260801 geführt — arbeite mit einer Seite sowohl über deren Struktur, also Barrierefreiheitsbaum, Elemente, Formulare und Tabs, als auch über Pixel, also Screenshots und Koordinaten im sichtbaren Ausschnitt. Der Aufruf read_page gebe den Barrierefreiheitsbaum als Text zurück und markiere jedes Element mit einer Referenz, auf die sich später klicken lässt.

Ausschließlich über den Baum arbeitet dieses Werkzeug damit nicht. Dieselbe Seite formuliert die Struktur als Vorzug und empfiehlt Referenzen dort, wo eine Seite einen brauchbaren Barrierefreiheitsbaum hat; für alles andere nennt sie Koordinaten. Und die Werkzeugtabelle richtet sich an die Anwendung, die das Werkzeug einbindet — sie beschreibt, was deren Ausführungsschicht leisten soll, und sagt nicht zu, dass Anthropic den Baum selbst erzeugt.

Daneben, nicht dagegen, steht OpenAIs API-Werkzeug für die Rechnerbedienung. OpenAI beschreibt es bildschirmbasiert: Die aufrufende Anwendung stelle die Umgebung bereit und führe die Anfragen des Modells aus, und das Modell entscheide anhand von Screenshots und weiteren Werkzeugergebnissen, was als Nächstes zu tun sei. Eine vergleichende Aussage über andere Anbieter trifft diese Seite nicht. Dass hier zwei Arbeitsweisen nebeneinanderstehen, ist unsere Gegenüberstellung und keine Aussage von OpenAI.

Ein betätigter Knopf ist noch kein Ergebnis. Die vierte Stufe fehlt genau dann, wenn eine Seite Erfolg oder Fehler nur zeigt und nicht benennt: eine grüne Fläche ohne Wort, eine rote Umrandung ohne Meldung. Für ein Programm ist das nicht schwerer zu lesen als für den Menschen, der nichts sieht — es ist dieselbe fehlende Angabe.

Drei Anforderungen der WCAG 2.2 betreffen die Orientierung auf einer Website unmittelbar. Wiederkehrende Navigationsmechanismen, die auf mehreren Seiten eines Seitensatzes vorkommen, müssen jedes Mal in derselben relativen Reihenfolge erscheinen, solange die Änderung nicht vom Nutzer ausgelöst wird — Erfolgskriterium 3.2.3 der Stufe AA. Überschriften und Beschriftungen müssen Thema oder Zweck beschreiben — Erfolgskriterium 2.4.6 derselben Stufe. Und darüber steht eine eigene Leitlinie mit dem Namen Vorhersehbarkeit: Webseiten sollen auf vorhersehbare Weise erscheinen und funktionieren.

Eine Feinheit gehört zu 2.4.6 dazu. Das Kriterium verlangt, dass vorhandene Überschriften und Beschriftungen Thema oder Zweck beschreiben. Dass eine Seite überhaupt Überschriften haben muss, steht dort nicht. Sinnvolle Beschriftung ist damit eine normative Anforderung und keine Stilfrage — die Gliederung selbst bleibt eine Empfehlung.

Für wen diese Anforderungen geschrieben sind, entscheidet, was man aus ihnen ableiten darf. In den unten genannten W3C-Dokumenten zu WCAG 2.2, zu ARIA in HTML und zu WAI-ARIA 1.2 kommen KI-Agenten nicht vor. Sie sprechen von Menschen mit Behinderungen, von Hilfstechnologien, von User Agents und von Konformitätsprüfern. Wer semantische Struktur mit dem Nutzen für KI-Systeme begründet, verlässt damit die Norm. Belegen lässt sich dieser Nutzen nur produktbezogen — und dafür stehen unten zwei Anbieterdokumente.

Die normativen Regeln für ARIA in HTML stehen in der W3C-Empfehlung „ARIA in HTML“ mit dem Stand 11. August 2026. Die Statuszeile weist sie als Recommendation aus, veröffentlicht von der Arbeitsgruppe für Accessible Rich Internet Applications auf dem Recommendation-Track. Bei einer Norm ist der Status Teil der Aussage: Eine Recommendation ist nach der Selbstbeschreibung des W3C eine Spezifikation, die nach ausführlicher Konsensbildung von W3C und Mitgliedern getragen wird. Ein Entwurf ist etwas anderes.

Zwei Regeln dieses Dokuments betreffen die Praxis direkt. Autorinnen und Autoren dürfen ARIA-Rollen und ARIA-Attribute nicht so einsetzen, dass sie den Semantiken der beiden Konformitätstabellen der Spezifikation widersprechen — das Dokument schreibt dafür ein Muss-nicht in Großbuchstaben. Und es ist nicht empfohlen, Rolle und ARIA-Attribute auf Werte zu setzen, die der impliziten ARIA-Semantik des Elements entsprechen; das sei unnötig und könne zu unbeabsichtigten Folgen führen. Zu einem Verbot härten sollte man das nicht: Dieselbe Spezifikation hält an anderer Stelle fest, dass ein ausdrückliches Setzen in manchen Situationen hilfreich sein kann, etwa für User Agents, die implizite ARIA-Semantik nicht offenlegen.

Der Vorrang des vorhandenen Mittels vor dem nachgerüsteten steht in einem zweiten Dokument. WAI-ARIA in der Fassung 1.2 ist eine W3C-Empfehlung vom 6. Juni 2023; in ihrem Abschnitt zu Konflikten mit der Semantik der Wirtssprache steht eine Soll-Regel: Steht in der Wirtssprache eine Funktion mit identischer Rollensemantik und identischen Werten zur Verfügung und hat der Autor keinen zwingenden Grund, sie zu meiden, soll er diese Funktion nutzen, statt andere Elemente per WAI-ARIA umzuwidmen. Die Regel spricht von der Wirtssprache allgemein und nicht nur von HTML.

Die griffige Merkregel, die zu diesem Thema meist zitiert wird, steht in keinem der beiden Dokumente. Sie stammt aus dem Autorenleitfaden der Web Accessibility Initiative, wird dort anders geschrieben, als sie üblicherweise kursiert, und ist kein normativer Text. In „ARIA in HTML“ trägt sich dieselbe Sache über das Muss-nicht und das Nicht-empfohlen. Wer die Merkregel der Empfehlung zuschreibt, zitiert eine Quelle für einen Satz, der nicht in ihr steht.

Was falsch gesetztes ARIA anrichtet, zeigt derselbe Autorenleitfaden an einem kleinen Beispiel: Eine Aufzählungsliste, der man die Rolle einer Navigationsregion gibt, ist danach eine Navigationsregion und keine Liste mehr — die Listenpunkte darin stehen in keiner Liste. Der Abschnitt stellt beide Seiten nebeneinander. ARIA könne verdecken und ergänzen zugleich; manche Verwendungen wirkten wie Hosenträger oder Gürtel und fügten Bedeutung hinzu, die den ursprünglichen Inhalt trägt. Das Verdecken ist der Fall des falsch gesetzten ARIA, nicht die Regel.

Dass ein Anbieter ARIA tatsächlich auswertet, steht in einer Hilfeseite von OpenAI für Publisher und Entwickler. ChatGPT Atlas nutze ARIA-Tags — dieselben Beschriftungen und Rollen, die Screenreader stützen —, um Seitenstruktur und interaktive Elemente zu deuten. Dieselbe Seite empfiehlt Betreibern, den WAI-ARIA-Best-Practices zu folgen und interaktiven Elementen wie Schaltflächen, Menüs und Formularen beschreibende Rollen, Beschriftungen und Zustände zu geben. Die Aufzählung ist als Beispiel formuliert, nicht als abschließende Liste, und die Seite nennt einen Zweck, keine Leistungszusage. Sie spricht von ChatGPT Atlas und vom ChatGPT-Agenten darin — nicht von ChatGPT allgemein und nicht von anderen Anbietern.

Aus Anthropics Dokumentation lässt sich zur Struktur einer Website nur eine technische Nebenwirkung ablesen, und die ist bescheidener, als sie klingt. Elementreferenzen seien an den Tab gebunden, der sie erzeugt hat, und blieben nur gültig, bis dieser Tab navigiert oder sein DOM sich wesentlich ändert; die Schnittstelle könne eine veraltete oder unbekannte Referenz selbst nicht erkennen. Das ist eine Regel für die einbindende Anwendung. Eine Anforderung an die Website — etwa vorhersehbare Navigation — steht auf den unten genannten Anbieterseiten nicht.

Semantische Elemente empfehlen wir trotzdem, und zwar als eigene Empfehlung. Ein Navigationsbereich, ein Hauptbereich, eine Schaltfläche, die auch ein Schaltflächenelement ist: Das trägt vier Dinge gleichzeitig — die Bedienbarkeit mit der Tastatur, die Ansage im Screenreader, die Prüfbarkeit gegen die Norm und, nach der oben genannten OpenAI-Seite, die Deutung durch ein benanntes Produkt. Auf den unten genannten Anbieterseiten werden diese Elemente allerdings nicht namentlich empfohlen. ARIA allein macht eine Seite nicht agent-ready. Es ergänzt Semantik, wo sie fehlt, und verdeckt sie, wo sie schon da war.

Vor dieser Frage steht eine andere: Semantik kann ein System nur auswerten, wenn sie beim Abruf überhaupt vorhanden ist. Ob eine Schaltfläche schon im ausgelieferten Dokument steht oder erst durch Client-JavaScript entsteht, entscheidet die Auslieferungsarchitektur — nachzulesen in Wie moderne Websites gebaut und ausgeliefert werden.

Am Formular wird sichtbar, wofür Barrierefreiheit gemacht ist. Wo ein Inhalt eine Eingabe verlangt, müssen Beschriftungen oder Anweisungen vorhanden sein — Erfolgskriterium 3.3.2 der Stufe A. Wird ein Eingabefehler automatisch erkannt, muss das fehlerhafte Element benannt und der Fehler in Textform beschrieben werden — Erfolgskriterium 3.3.1, ebenfalls Stufe A. Eine rote Umrandung ist kein Text. Und sind Korrekturvorschläge bekannt, müssen sie genannt werden, es sei denn, das gefährdet Sicherheit oder Zweck des Inhalts — Erfolgskriterium 3.3.3 der Stufe AA, mit der Ausnahme im selben Satz.

Diese Kriterien sind für Menschen mit Behinderungen geschrieben und für sie begründet. Wer sie erfüllt, baut ein Formular, das jemand mit Screenreader, jemand ohne Maus und jemand mit eingeschränkter Aufmerksamkeit tatsächlich zu Ende bringt. Dass ein Programm von derselben Auszeichnung etwas hat, ist plausibel, aber aus den Normdokumenten nicht belegbar — dort steht dazu nichts. Barrierefreiheit ist damit kein KI-Trick. Sie ist zuerst ein Nutzen für Menschen, und der Nebeneffekt für Maschinen ist Folge, nicht Zweck.

Wie eine Beschriftung technisch an ihr Feld kommt, regelt der HTML-Standard der WHATWG. Ein label-Element stellt danach eine Beschriftung in der Benutzeroberfläche dar, und die Verknüpfung mit dem Formularfeld entsteht entweder über das for-Attribut oder dadurch, dass das Feld im label-Element selbst steht. Das for-Attribut kann gesetzt werden; ist es gesetzt, muss sein Wert die Kennung eines beschriftbaren Elements im selben Baum sein. Von genau einem zugehörigen Feld spricht die Spezifikation dabei nicht wörtlich: Sie formuliert im Singular und wählt das erste passende Element in Baumreihenfolge — und ein label ganz ohne zugehöriges Feld ist ebenfalls vorgesehen.

• Beschriftung

  Weiß man, was in das Feld gehört?

  Ein Feld, dessen Beschriftung nur daneben steht und nicht mit ihm verknüpft ist, sieht richtig aus und ist es nicht. Der HTML-Standard kennt dafür zwei Wege: das for-Attribut oder das Feld innerhalb des label-Elements. Die WCAG verlangen mit 3.3.2, dass Beschriftung oder Anweisung überhaupt da ist. Für ARIA gilt dabei eine Grenze: aria-label und aria-labelledby dürfen nicht auf Elementen stehen, deren implizite ARIA-Rolle keine Benennung zulässt — das Wort implizit gehört dazu, denn wo die Rolle Benennung zulässt, erlaubt dieselbe Spezifikation beide Attribute ausdrücklich.

• Bedienbarkeit

  Kommt man ohne Zeigegerät durch?

  Erfolgskriterium 2.1.1 verlangt Bedienbarkeit über eine Tastaturschnittstelle, mit einer Ausnahme für Eingaben, die vom Bewegungspfad abhängen. Eine Anmerkung derselben Norm hält fest, dass Mauseingabe zusätzlich weder untersagt noch entmutigt ist. Der Autorenleitfaden der Web Accessibility Initiative erklärt, warum das bei nachgebauten Elementen Arbeit macht: Eine ARIA-Rolle sei ein Versprechen. Anders als HTML-Eingabeelemente veranlassten ARIA-Rollen den Browser nicht dazu, Tastaturverhalten oder Gestaltung bereitzustellen — wer ein Element zur Schaltfläche erklärt, muss das Verhalten selbst schreiben.

• Zustand und Fehler

  Sagt die Seite, was passiert ist?

  Erfolgskriterium 3.3.1 verlangt, dass ein automatisch erkannter Eingabefehler das betroffene Element benennt und den Fehler in Textform beschreibt; 3.3.3 ergänzt bekannte Korrekturvorschläge, sofern das nicht Sicherheit oder Zweck des Inhalts gefährdet. Und 4.1.3 verlangt für Statusmeldungen, dass sie über Rolle oder Eigenschaften programmatisch bestimmbar sind, ohne den Fokus zu ziehen. Welche technischen Mittel man dafür wählt, sagen die unten genannten Anbieterseiten nicht — dort kommen Live-Regionen und Statusrollen nicht vor. Die Empfehlung dazu ist unsere Ableitung aus der Norm.

Eine Regel wird in diesem Zusammenhang oft als geltender Standard zitiert, ist aber keiner mehr. Die klassische erste ARIA-Regel — lieber ein vorhandenes HTML-Element mit der gewünschten Bedeutung und dem gewünschten Verhalten als ein umgewidmetes Element mit nachgerüsteter Rolle — steht in einem W3C-Dokument, das sich selbst seit dem 24. Februar 2026 als eingestellten Entwurf führt und von sich sagt, es sei nur informativ. Als geltende Vorgabe trägt sich dieselbe Sache über die beiden Dokumente aus dem vorigen Abschnitt. Für die dritte Regel desselben Entwurfs — jedes interaktive ARIA-Bedienelement muss mit der Tastatur bedienbar sein — haben wir in den unten genannten Dokumenten kein normatives Gegenstück gefunden.

Auch für das label-Element selbst gibt es eine Konformitätsregel. Ist ein label-Element implizit oder explizit mit einem beschriftbaren Element verknüpft, darf ihm keine ARIA-Rolle gegeben werden; die Einleitung des Abschnitts sagt dazu, dass die implizite ARIA-Semantik oder die native Semantik des HTML-Elements nicht überschrieben werden darf. Ist das label mit keinem Element verknüpft, ist jede Rolle zulässig — die generische Rolle allerdings soll nicht verwendet werden.

Wie ein Werkzeug so ein Formular tatsächlich anfasst, beschreibt Anthropic für sein Browser-Werkzeug. Der Aufruf form_input setze den Wert eines Formularelements direkt: ein Wahrheitswert für Kontrollkästchen, für Auswahlfelder der Wert oder der sichtbare Text einer Option. Vorher muss das Element allerdings adressiert sein — der Aufruf arbeitet auf einer Referenz, die zuvor aus read_page oder aus find stammt. Der Aufruf find wiederum sucht Elemente anhand einer natürlichsprachlichen Beschreibung wie „search field“ oder „add to cart button“. Wie er eine solche Beschreibung auflöst, sagt die Seite nicht; von Beschriftungen oder zugänglichen Namen ist dort keine Rede.

Zum Zurücklesen hält dieselbe Seite eine Beobachtung bereit, die man nicht überdehnen sollte. Claude schließe eine Folge von Aufrufen typischerweise mit einem beobachtenden Aufruf ab — einem Screenshot, einem read_page oder einem get_page_text. Derselbe Absatz beginnt allerdings mit dem Hinweis, dass nach jedem Aufruf kein Screenshot nötig ist, und stellt es der einbindenden Anwendung frei, die Beobachtung selbst anzuhängen. Ein „jede Handlung endet mit einem Nachlesen“ steht dort nicht.

Und ein Teil des Themas ist in den unten genannten Dokumenten schlicht nicht behandelt. Zu Pflichtfeldern, zur Verknüpfung einer Fehlermeldung mit ihrem Feld, zu Fehlerzuständen, zum Ausfüllhinweis für Browser und zur Rückmeldung nach dem Absenden steht dort nichts, was sich hier belegen ließe. Wer diese Punkte umsetzt, tut das nach guter Praxis — nicht nach einer Stelle, die dieser Beitrag zitieren könnte.

Für die Anmeldung hat die WCAG 2.2 ein eigenes, neues Erfolgskriterium bekommen. Nach 3.3.8 der Stufe AA darf kein Schritt eines Authentifizierungsvorgangs einen kognitiven Test verlangen — die Norm nennt als Beispiele das Merken eines Passworts und das Lösen eines Rätsels —, wenn dieser Schritt nicht mindestens eine von vier genannten Möglichkeiten bietet. Zwei davon sind Ausweichwege: eine Alternative ohne kognitiven Test und ein Mechanismus, der beim Bestehen hilft. Die anderen beiden sind erlaubte Arten des Tests selbst: dass der Test im Wiedererkennen von Objekten besteht, oder darin, Nicht-Text-Inhalte zu erkennen, die der Nutzer der Website selbst überlassen hat. Wer nur von Ausweichwegen spricht, stellt die Norm strenger dar, als sie ist.

Für die Transaktion selbst gilt ein zweites Kriterium. Bei Seiten, die rechtliche Verpflichtungen oder Finanztransaktionen für den Nutzer auslösen, die vom Nutzer kontrollierbare Daten in Datenspeichern ändern oder löschen oder die Testantworten einreichen, muss mindestens eines von drei Dingen zutreffen — die Eingabe ist umkehrbar, sie wird auf Fehler geprüft, oder sie lässt sich vor dem Abschluss bestätigen. Das ist Erfolgskriterium 3.3.4 der Stufe AA.

Ein drittes, ebenfalls neues Kriterium betrifft die Wiederholung. Nach 3.3.7 der Stufe A müssen Angaben, die im selben Vorgang schon einmal eingegeben wurden, entweder vorausgefüllt oder zur Auswahl angeboten werden. Der Satz bricht dort aber nicht ab: Er führt unmittelbar drei Ausnahmen an — wenn die erneute Eingabe wesentlich ist, wenn sie der Sicherheit des Inhalts dient oder wenn die früheren Angaben nicht mehr gültig sind. Gerade die Sicherheitsausnahme ist bei Anmeldeformularen einschlägig. Ein „darf nicht noch einmal abgefragt werden“ steht in diesem Kriterium nicht.

Was Anthropic, OpenAI und Google ihren eigenen Produkten an dieser Stelle erlauben, steht in fünf Dokumenten — und keines davon spricht über die beiden anderen Anbieter. Anthropic führt für Claude in Chrome eine Liste von Handlungen, die unabhängig von der gewählten Berechtigungsstufe untersagt sind; darin stehen Käufe und Finanztransaktionen, das Anlegen von Konten und der Umgang mit sensiblen Kreditkarten- oder Ausweisdaten, dazu sieben weitere Punkte. In einem zweiten Hilfeartikel steht, dass Claude vor dem Zugriff auf Finanzseiten um Erlaubnis fragt — Finanzseiten stehen dort also nicht auf der Sperrliste, sondern sind erlaubnispflichtig. Was als Finanzseite gilt, definiert Anthropic nicht und schränkt selbst ein, dass vermutlich nicht alle Seiten dieser Kategorien erfasst sind.

OpenAI trennt dieselbe Sache in zwei Dokumenten. Die Empfehlungen zur Einbindung des Computer-use-Werkzeugs führen einen Abschnitt mit der Überschrift, unmittelbar vor der Handlung zu bestätigen; genannt sind dort unter anderem das Senden, Veröffentlichen oder Einreichen gegenüber Dritten im Namen des Nutzers, das An- und Abmelden von Benachrichtigungen und das Bestätigen von Finanztransaktionen. Die Liste ist ausdrücklich als Beispielliste formuliert und richtet sich an Integratoren, nicht an Endnutzer. Für den Agenten in ChatGPT Atlas beschreibt eine Hilfeseite etwas anderes: Er halte bei bestimmten sensiblen Seiten wie Finanzinstituten an, um sicherzugehen, dass der Nutzer zusieht.

Google beschreibt für die selbsttätige Browsernutzung von Gemini in Chrome eine Aufforderung mit dem Namen „Take over task“. Gemini in Chrome könne den Nutzer bitten, die Aufgabe für bestimmte Schritte selbst zu übernehmen — genannt sind das Abschließen von Finanztransaktionen, das Akzeptieren von Nutzungsbedingungen und das Anlegen eines Kontos. Formuliert ist das als Kann und als offene Beispielliste. Und Google entwertet die eigene Aufzählung im selben Text zweimal ausdrücklich: Diese Vorkehrungen garantierten keinen Schutz vor allen Risiken.

Ein Risiko benennt Anthropic in der Dokumentation zum Computer-use-Werkzeug so deutlich, dass es hierher gehört. Unter Umständen befolge Claude Anweisungen, die es in Inhalten findet, auch wenn sie den Vorgaben des Auftraggebers widersprechen; Anweisungen auf Webseiten oder in Bildern könnten die eigenen Vorgaben überschreiben oder Fehler auslösen. Der Folgeabsatz derselben Seite nennt dazu Gegenmaßnahmen — Training, Klassifikatoren und eine Rückfrage beim Nutzer. Wer nur den Risikosatz zitiert, gibt die Seite verkürzt wieder.

Belegt ist damit, was diese fünf Dokumente aussparen oder an eine menschliche Bestätigung binden — die Reifestufe ist unsere Einordnung. Zur Weitergabe von Zugangsdaten, zur Bot-Abwehr und zur Haftung bei automatisiert ausgelösten Transaktionen steht in der unten genannten WCAG 2.2 nichts; belegbar sind dort die drei Erfolgskriterien oben. Für einen Betrieb, der heute plant, heißt das: Der Weg bis zum abgeschickten Kontaktformular ist der Teil, für den dieser Beitrag Belege nennen kann. Alles hinter der Anmeldung ist ein zweiter Schritt — und Anthropic, OpenAI und Google haben ihn für ihre eigenen Produkte jeweils selbst eingeschränkt.

Was gilt, hängt am Datum des Dokuments, in dem es steht. Die WCAG 2.2 ist eine W3C-Empfehlung vom 12. Dezember 2024, und die Seite vermerkt selbst, dass Errata existieren. Sie erweitert die Fassung 2.1 von Juni 2018, und wer 2.2 erfüllt, erfüllt damit auch 2.0 und 2.1. Wo dieser Beitrag ein Datum nennt, ist das keine Formalie, sondern Teil der Aussage.

Auch ein W3C-Dokument kann seinen Status verlieren. „Using ARIA“ ist seit dem 24. Februar 2026 ein eingestellter Entwurf; die vier ARIA-Regeln würden dort aus historischen Gründen und zur leichteren Bezugnahme aufbewahrt, eine Weiterarbeit sei nicht geplant. Wer sich auf diese Regeln beruft, beruft sich auf einen Text, dessen eigene Statuszeile das ausschließt. Für die erste der vier Regeln steht das lebende Gegenstück in „ARIA in HTML“ und in WAI-ARIA 1.2; für die dritte haben wir keines gefunden.

Selbst innerhalb eines geltenden Dokuments ist nicht alles verbindlich, und die Grenze steht dort ausdrücklich. „ARIA in HTML“ hält in seinem Konformitätsabschnitt fest: Neben den als nicht-normativ gekennzeichneten Abschnitten sind auch sämtliche Autorenhinweise, Diagramme, Beispiele und Notizen nicht-normativ; alles Übrige ist normativ. Und die Schlüsselwörter wie „muss“ oder „soll“ gelten nur dann als solche, wenn sie in Großbuchstaben stehen. Wer eine Norm zitiert, zitiert damit auch immer eine Verbindlichkeitsstufe.

Wie weit die Norm überhaupt reicht, sagt sie ebenfalls selbst. Der Begriff der unterstützten Barrierefreiheit ist im W3C-Dokument an eine nachgewiesene Zusammenarbeit mit den Hilfsmitteln der Nutzer gebunden: Die Art, wie eine Webtechnologie verwendet wird, muss auf Interoperabilität mit den Hilfsmitteln der Nutzer in der Sprache des Inhalts geprüft worden sein — und das ist ausdrücklich nur die erste von zwei Bedingungen, die beide erfüllt sein müssen. Wie viel Unterstützung dafür nötig ist, legt das W3C in einer eigenen Anmerkung ausdrücklich nicht fest.

• nachlesbar

  Kennungen und robots.txt

  Google führt eine Liste nutzerausgelöster Abrufer und schreibt in deren Einleitung, solche Abrufer missachteten robots.txt-Regeln in der Regel, weil der Abruf von einem Nutzer angefordert wurde; die Liste bezeichnet sich selbst als nicht abschließend. Die Kennung Google-Agent verbindet dieselbe Seite mit Agenten, die auf Google-Infrastruktur im Web navigieren und auf Nutzeranfrage Handlungen ausführen — worauf sich diese Handlungen richten, sagt sie nicht. OpenAI führt vier Kennungen und schreibt zu ChatGPT-User, diese werde nicht für selbsttätiges Crawlen verwendet und robots.txt-Regeln gälten für diese nutzerausgelösten Handlungen möglicherweise nicht; für Suchergebnisse könne es nach einer Änderung der robots.txt etwa 24 Stunden dauern, bis die eigenen Systeme sie nachvollziehen. Anthropic führt drei Kennungen und sagt zu, „do not crawl“-Signale zu beachten, indem branchenübliche robots.txt-Direktiven eingehalten werden — mit dem Hinweis im selben Dokument, dass andere Wege wie das Sperren von IP-Adressen möglicherweise nicht richtig wirken. Perplexity schreibt auf seiner Crawler-Seite zur nutzerausgelösten Kennung Perplexity-User, dieser Abrufer missachte robots.txt-Regeln in der Regel, weil ein Nutzer den Abruf angefordert habe; die Nachbarzeile zu PerplexityBot trägt die gegenteilige Empfehlung, diesen in der robots.txt der eigenen Website zuzulassen — beides gehört nicht vermischt. Dieselbe Seite schreibt im Einleitungsabsatz, es könne bis zu 24 Stunden dauern, bis die eigenen Systeme Änderungen an der robots.txt abbilden.

• an Produkt gebunden

  Was ein benanntes Werkzeug kann

  OpenAI benennt für den Agenten in ChatGPT Atlas ausdrückliche Grenzen: Er könne im Browser keinen Code ausführen, keine Dateien herunterladen und keine Erweiterungen installieren. Anthropic beschreibt für Claude in Chrome hinterlegtes Wissen über die Navigation namentlich genannter Plattformen — Slack, Google Calendar, Gmail, Google Docs und GitHub — und nennt diese Fähigkeiten selbst plattformspezifisch; die Aufzählung ist ausdrücklich nicht abschließend und sagt etwas über hinterlegtes Wissen, nicht über Bedienbarkeit überhaupt. Dieselbe Erweiterung liest, klickt und navigiert Websites nach Anthropics Beschreibung an der Seite des Nutzers, und derselbe Einleitungsblock hält fest, dass ein direktes Handeln auf Websites im Auftrag des Nutzers weiterhin riskant ist. Perplexity beschreibt in der Entwicklerdokumentation zum Perplexity Computer MCP Server einen vollständigen Cloud-Browser: Verlange eine Aufgabe das Bedienen einer Website, das Ausfüllen von Formularen oder den Zugriff auf angemeldete Inhalte, starte Computer automatisch eine Browsersitzung. Was dieser Browser tut, führt dieselbe Seite in einer Fähigkeitentabelle auf — zu einer beliebigen Adresse navigieren, Elemente anklicken, Formulare ausfüllen und strukturierte Daten entnehmen. Das beschreibt eine Fähigkeit; dass es auf jeder Seite geschieht, sagt die Zeile nicht.

• Experiment

  Signierter Agentenverkehr

  Google testet für einen Teil der Agentenzugriffe ein kryptografisches Verfahren: Ein Teil der Anfragen von Google-Agent sei signiert und weise sich dann unter einer eigenen Adresse aus. Google bezeichnet die eigene Umsetzung als derzeit experimentell, schreibt, dass nicht alle Google-Kennungen das Verfahren verwenden, und empfiehlt, zusätzlich weiterhin auf IP-Adressen, Reverse DNS und User-Agent-Zeichenketten zu setzen, solange signierter Verkehr schrittweise ausgerollt wird. Den Schluss zieht die Seite selbst: Man solle sicherstellen, auf die etablierten Methoden der Bot-Prüfung zurückzufallen. Ob andere Anbieter dasselbe Verfahren einsetzen, sagt diese Seite nicht.

Wie zuverlässig das im Alltag ist, sagt keines dieser Dokumente in Zahlen. Anthropic formuliert für das Computer-use-Werkzeug immerhin eine Möglichkeit: Claude könne bei der Auswahl von Werkzeugen Fehler machen oder halluzinieren und unerwartete Handlungen ausführen; die Zuverlässigkeit könne bei Nischenanwendungen oder bei mehreren Anwendungen gleichzeitig geringer ausfallen. Das ist eine Möglichkeit und keine Feststellung — und eine Erfolgsquote für das Bedienen fremder Websites steht in keinem der unten genannten Dokumente.

Deshalb steht in diesem Beitrag keine Prozentzahl. Auch nicht zu Websites kleiner Unternehmen: Zu deutschsprachigen Seiten, zu Handwerks- oder Praxisauftritten und zu branchentypischen Buchungsstrecken sagt keines der unten genannten Anbieterdokumente etwas. Wer Ihnen dazu eine Quote nennt, sollte sagen, woher sie stammt — aus den unten genannten Anbieterdokumenten stammt sie nicht.

Praktikabel ist heute vor allem das, was ohnehin gute Arbeit ist. Eine Seite, die ihre Inhalte in Text liefert, ihre Bedienelemente auszeichnet, ihre Formulare beschriftet und ihre Zustände benennt, ist für Menschen mit Hilfsmitteln besser bedienbar, gegen eine veröffentlichte Norm prüfbar und — nach der im zweiten Abschnitt genannten OpenAI-Seite — für ein benanntes Produkt besser deutbar. Das ist ein handfester Gewinn, und er hängt an keiner Anbieterzusage.

Experiment ist alles, was darüber hinausgeht. Wer Ihnen zusagt, dass KI-Agenten heute Ihre Website zuverlässig bedienen, verspricht etwas, das Google, OpenAI und Anthropic in den unten genannten Dokumenten für ihre eigenen Produkte nicht versprechen: Google entwertet die eigenen Schutzvorkehrungen ausdrücklich, OpenAI zählt Funktionsgrenzen auf, und Anthropic nennt Fehler und geringere Zuverlässigkeit als Möglichkeit. Der Teil, den Sie in der Hand haben, ist die Seite. Was ein Agent daraus macht, ist der Teil, zu dem die unten genannten Dokumente keine Zusage geben.

W3C — WCAG 2.2

Die WCAG 2.2 enthält sämtliche Erfolgskriterien dieses Beitrags: 1.3.1, 4.1.2 und 2.1.1 im ersten Abschnitt, 3.2.3, 2.4.6 und Leitlinie 3.2 im zweiten, 3.3.1, 3.3.2, 3.3.3 und 4.1.3 im dritten, 3.3.4, 3.3.7 und 3.3.8 im vierten sowie Datum, Version und den Begriff der unterstützten Barrierefreiheit im fünften.

Web Content Accessibility Guidelines (WCAG) 2.2 W3C Recommendation vom 12. Dezember 2024; die Seite vermerkt, dass Errata existieren. Ohne Browser antwortet sie mit HTTP 403. Abgerufen am 4. September 2026

W3C — ARIA in HTML

Die Spezifikation nennt die normativen ARIA-Regeln im zweiten Abschnitt, die Grenze für aria-label und aria-labelledby sowie die Konformitätszeile zum label-Element im dritten und die Abgrenzung von normativ und nicht-normativ im fünften. Normative Spezifikation der Arbeitsgruppe für Accessible Rich Internet Applications, kein Entwurf und kein Leitfaden.

ARIA in HTML W3C Recommendation vom 11. August 2026. Ohne Browser antwortet die Seite mit HTTP 403. Abgerufen am 4. September 2026

W3C — WAI-ARIA 1.2

WAI-ARIA 1.2 weist im zweiten Abschnitt den Status als verabschiedete Empfehlung aus und nennt die Soll-Regel aus dem Abschnitt zu Konflikten mit der Semantik der Wirtssprache: die Funktion der Wirtssprache vor der Umwidmung anderer Elemente.

Accessible Rich Internet Applications (WAI-ARIA) 1.2 W3C Recommendation vom 6. Juni 2023 — der Stand ist ausdrücklich nicht neuer. Ohne Browser antwortet die Seite mit HTTP 403. Abgerufen am 4. September 2026

W3C — Using ARIA

Der Entwurf gibt im dritten Abschnitt den historischen Wortlaut der ersten und der dritten ARIA-Regel wieder und zeigt im fünften, dass ein W3C-Dokument seinen Status verlieren kann. Ausdrücklich ein eingestellter, nur informativer Entwurf — die geltenden Regeln stehen in „ARIA in HTML“ und in WAI-ARIA 1.2.

Using ARIA W3C Discontinued Draft vom 24. Februar 2026. Ohne Browser antwortet die Seite mit HTTP 403. Abgerufen am 4. September 2026

W3C WAI — Autorenleitfaden ARIA

Der Leitfaden bringt im zweiten Abschnitt das Beispiel der Liste, die durch eine Navigationsrolle keine Liste mehr ist, und die Gegenüberstellung von Verdecken und Ergänzen; im dritten den Grundsatz, dass eine Rolle ein Versprechen ist. Autorenleitfaden der Web Accessibility Initiative, nicht normativ.

Read Me First — ARIA Authoring Practices Guide Ohne Datumsangabe auf der Seite. Ohne Browser antwortet sie mit HTTP 403. Abgerufen am 4. September 2026

WHATWG — HTML Standard, Formulare

Der HTML-Standard legt im dritten Abschnitt die Regeln für Formularbeschriftungen fest: was ein label-Element ist, wie die Verknüpfung mit dem Feld entsteht und welche Anforderung für das for-Attribut gilt.

HTML Standard — 4.10 Forms Living Standard, zuletzt aktualisiert am 3. September 2026, abgerufen am 4. September 2026

Anthropic — Browser-Werkzeug

Anthropic beschreibt im ersten Abschnitt die Arbeitsweise über Struktur und Pixel und den Aufruf zum Auslesen der Seite, im zweiten den Verfall von Elementreferenzen und im dritten das Setzen von Formularwerten, die Suche über eine natürlichsprachliche Beschreibung und den beobachtenden Abschlussaufruf. Entwicklerdokumentation des Anbieters.

Browser use tool Ohne Datumsangabe auf der Seite; einziger Versionshinweis ist die Kennung des Werkzeugsatzes. Abgerufen am 4. September 2026

Anthropic — Computer-Werkzeug

Anthropic nennt im vierten Abschnitt das dokumentierte Risiko, dass Anweisungen aus Seiteninhalten die Vorgaben des Auftraggebers überschreiben, samt der im Folgeabsatz genannten Gegenmaßnahmen, und im fünften die Möglichkeitsaussage zu Fehlern und geringerer Zuverlässigkeit. Entwicklerdokumentation des Anbieters.

Computer use tool Ohne Datumsangabe auf der Seite, abgerufen am 4. September 2026

Anthropic-Hilfe — Claude in Chrome

Das Hilfecenter führt im vierten Abschnitt die unabhängig von der Berechtigungsstufe untersagten Handlungen und die Erlaubnisabfrage vor Finanzseiten samt Anthropics eigener Einschränkung dazu auf, im fünften das plattformspezifisch hinterlegte Navigationswissen und die Beschreibung der Erweiterung, die an der Seite des Nutzers liest, klickt und navigiert. Hilfecenter-Artikel für Endnutzer, keine Entwicklerdokumentation.

Claude in Chrome permissions guide · Use Claude in Chrome safely · Get started with Claude in Chrome Nur relative Datumsangaben auf den Seiten, abgerufen am 4. September 2026

Anthropic-Hilfe — Crawler

Anthropic nennt im fünften Abschnitt die drei Kennungen des Anbieters, die Zusage zu branchenüblichen robots.txt-Direktiven und den im selben Dokument genannten Vorbehalt zu anderen Sperrwegen. Help-Center-Artikel aus der Sammlung zu Datenschutz und Recht.

Does Anthropic crawl data from the web, and how can site owners block the crawler? Seitenstand 7. April 2026, abgerufen am 4. September 2026

OpenAI — Computer use

OpenAI beschreibt im ersten Abschnitt die bildschirmbasierte Arbeitsweise und die Rollenverteilung zwischen Modell und aufrufender Anwendung, im vierten die Liste der Handlungen, vor denen unmittelbar zu bestätigen ist. Entwicklerdokumentation des Anbieters; die zweite Seite richtet sich ausdrücklich an Integratoren.

Computer use · Computer use integration recipes Ohne Datumsangabe auf den Seiten, abgerufen am 4. September 2026

OpenAI-Hilfe — Atlas und Publisher

Das OpenAI-Hilfecenter beschreibt im zweiten Abschnitt die Auswertung von ARIA-Tags durch ChatGPT Atlas und die Empfehlung, den WAI-ARIA-Best-Practices zu folgen, im vierten das Anhalten bei sensiblen Seiten und im fünften die Funktionsgrenzen des Agenten in Atlas. Hilfecenter-Artikel.

Publishers and Developers — FAQ · Using Ask ChatGPT sidebar and ChatGPT Agent on Atlas Nur relative Datumsangaben auf den Seiten; ohne Browser antworten sie mit HTTP 403. Abgerufen am 4. September 2026

OpenAI — Crawler-Kennungen

OpenAI nennt im fünften Abschnitt die vier Kennungen des Anbieters, die Beschreibung von ChatGPT-User samt dem Vorbehalt, dass robots.txt-Regeln möglicherweise nicht gelten, und die Vorlaufzeit von etwa 24 Stunden für Suchergebnisse. Produkt- und Entwicklerdokumentation, kein Blogbeitrag.

Overview of OpenAI Crawlers Ohne Datumsangabe auf der Seite, abgerufen am 4. September 2026

Google-Hilfe — Gemini in Chrome

Die Google-Hilfe fordert im vierten Abschnitt dazu auf, bestimmte Schritte selbst zu übernehmen — Finanztransaktionen abschließen, Nutzungsbedingungen akzeptieren, ein Konto anlegen — und spricht zweimal den Vorbehalt aus, dass die beschriebenen Vorkehrungen keinen Schutz vor allen Risiken garantieren. Hilfecenter-Artikel für Endnutzer.

Ask Gemini in Chrome to complete tasks for you with auto browse Ohne Datumsangabe auf der Seite, abgerufen am 4. September 2026

Google — nutzerausgelöste Abrufer

Google stellt im fünften Abschnitt einleitend fest, dass nutzerausgelöste Abrufer robots.txt-Regeln in der Regel missachten, bezeichnet die Liste selbst als nicht abschließend und beschreibt die Kennung Google-Agent. Herstellerseitige Referenzdokumentation, kein Blogbeitrag.

List of Google user-triggered fetchers Seitenstand 19. August 2026, abgerufen am 4. September 2026

Google — Web Bot Auth

Google beschreibt im fünften Abschnitt das Experiment mit signiertem Agentenverkehr: den signierten Teil der Anfragen, die ausdrückliche Kennzeichnung als experimentell, den Hinweis, dass nicht alle Kennungen das Verfahren verwenden, und die Empfehlung, weiterhin auf IP-Adressen, Reverse DNS und User-Agent-Zeichenketten zu setzen. Entwicklerdokumentation von Google, keine Ankündigung.

Authenticate requests with Web Bot Auth (experimental) Seitenstand 4. Mai 2026, abgerufen am 4. September 2026

Perplexity — Computer MCP Server

Perplexity beschreibt im fünften Abschnitt den vollständigen Cloud-Browser, den Perplexity Computer bei Bedarf automatisch startet, und die Zeile der Fähigkeitentabelle zum Navigieren, Anklicken, Ausfüllen und Entnehmen. Entwicklerdokumentation des Anbieters, kein Blogbeitrag und kein Änderungsprotokoll.

Perplexity Computer MCP Server Ohne sichtbares Datum auf der Seite, abgerufen am 4. September 2026

Perplexity — Crawler-Kennungen

Perplexity beschreibt im fünften Abschnitt die nutzerausgelöste Kennung Perplexity-User, die gegenteilige Empfehlung in der Nachbarzeile zu PerplexityBot und die Vorlaufzeit von bis zu 24 Stunden für Änderungen an der robots.txt. Produkt- und Entwicklerdokumentation, keine Richtlinienseite.

Perplexity Crawlers Ohne sichtbares Datum auf der Seite, abgerufen am 4. September 2026

Stand dieses Beitrags: 4. September 2026. Anbieterangaben können sich ohne Ankündigung ändern; eine Messung bleibt an ihr Datum gebunden. Wo dieser Beitrag ein Datum nennt, ist das keine Formalie, sondern Teil der Aussage. Sieben der hier genannten Seiten antworten Abrufen ohne Browser mit HTTP 403 — die fünf Adressen beim W3C und die beiden im Hilfebereich von OpenAI. Wer nachprüfen möchte, braucht dafür einen Browser.