Der Accessibility Tree zeigt eine Webseite so, wie Software sie bedienen kann: nicht, wie etwas aussieht, sondern was es ist und wie es heißt. Ein Browser liest dazu zuerst den HTML-Code und baut daraus das Document Object Model (DOM) auf, eine Baumstruktur aus allen Elementen, Attributen und Texten der Seite. Aus dem DOM leitet er den Accessibility Tree ab und stellt ihn über die Schnittstellen des Betriebssystems assistiven Technologien zur Verfügung, etwa Screenreadern, die blinden und sehbehinderten Menschen eine Seite vorlesen. Ein Baum ist er, weil seine Elemente ineinander verschachtelt sind: Eine Navigation enthält eine Liste, die Liste enthält Links.
Rolle, Name und Zustand
Jedes Element im Accessibility Tree wird mit wenigen Angaben beschrieben:
- Rolle: was für ein Element es ist, etwa Schaltfläche, Link, Überschrift, Eingabefeld oder Navigation.
- Name: wie es heißt, etwa „Termin buchen“ bei einer Schaltfläche oder „E-Mail-Adresse“ bei einem Formularfeld.
- Zustand: ob ein Kontrollkästchen angehakt, ein Menü aufgeklappt oder eine Schaltfläche gerade deaktiviert ist.
Je nach Element kommen ein Wert, etwa der Text in einem Eingabefeld, und eine ergänzende Beschreibung hinzu. Ein Screenreader liest aus diesen Angaben zum Beispiel „Termin buchen, Schaltfläche“ vor.
Native HTML-Elemente, also die im HTML-Standard festgelegten Elemente, bringen ihre Rolle von selbst mit. Eine Zeile wie „<button>Termin buchen</button>“ erscheint im Accessibility Tree als Schaltfläche mit dem Namen „Termin buchen“. Ein div-Element dagegen ist ein allgemeiner Container ohne eigene Bedeutung: Sieht es nur durch Gestaltung und Skripte wie ein Knopf aus und reagiert wie einer, erscheint es im Accessibility Tree trotzdem nicht als Schaltfläche. Wie Seiten aus solchen passenden Elementen aufgebaut werden, beschreibt semantisches HTML.
Der Name eines Elements
Der Name, im Fachjargon Accessible Name, sagt, wofür ein Element da ist, und unterscheidet es von anderen Elementen auf der Seite. Der Browser ermittelt ihn nach festen Regeln aus dem Code:
- Links und Schaltflächen: meist aus ihrem sichtbaren Text.
- Formularfelder: aus der zugehörigen Beschriftung, dem label-Element.
- Bilder: aus dem Alternativtext im alt-Attribut.
- Elemente ohne sichtbaren Text: Eine Schaltfläche, die nur ein Symbol zeigt, kann ihren Namen über das Attribut aria-label erhalten. Das Attribut gehört zu WAI-ARIA, einem Standard des World Wide Web Consortium (W3C) für Rollen, Namen und Zustände von Elementen.
Der Leitfaden des W3C zu Namen empfiehlt, sichtbaren Text und native HTML-Mittel vorzuziehen und kurze, eindeutige Namen zu wählen, die den Zweck nennen: „Schließen“ statt „X“. Platzhaltertext in einem Feld oder den Hinweistext aus einem title-Attribut, der beim Überfahren mit der Maus erscheint, zieht der Browser nur ersatzweise heran, und der Leitfaden rät, sich nicht darauf zu verlassen. Fehlt ein Name ganz, zeigt der Accessibility Tree zum Beispiel nur, dass es ein Eingabefeld gibt, nicht, ob dort ein Name, eine E-Mail-Adresse oder eine Telefonnummer hingehört.
Wie KI-Agenten den Accessibility Tree nutzen
KI-Agenten erledigen im Auftrag von Menschen Aufgaben auf Websites, etwa Angebote vergleichen oder eine Anfrage absenden. Laut Google können solche Agenten dafür Screenshots auswerten, das DOM untersuchen und den Accessibility Tree lesen. In der Dokumentation zu seinem Prüfwerkzeug Lighthouse nennt Google den Accessibility Tree die wichtigste Datengrundlage von Agenten; auf web.dev beschreibt Google ihn als eine Art Karte, die das gestalterische Beiwerk ausblendet und zeigt, was sich bedienen lässt. Auch Anthropic dokumentiert diesen Weg: Das browser use tool, mit dem Entwickler Claude Websites in einem Browser bedienen lassen, liefert den Accessibility Tree einer Seite als Text. Jedes Element trägt darin eine Kennung, über die Claude es in weiteren Schritten anklicken oder ausfüllen kann; daneben arbeitet das Werkzeug mit Screenshots.
Was im Accessibility Tree fehlt oder falsch beschrieben ist, kann ein Agent nur schwer finden und einordnen. Google weist in der Lighthouse-Dokumentation darauf hin, dass fehlende Beschriftungen Menschen mit Sehbehinderung ebenso wie Agenten daran hindern können, eine Aufgabe abzuschließen. Ein vollständiger Accessibility Tree entscheidet so mit darüber, ob ein Agent auf einer Website etwas erledigen kann, etwa eine Anfrage absenden oder einen Termin buchen. Er ist damit ein Baustein einer agentenfreundlichen Website.
Der Accessibility Tree entsteht im Browser und betrifft deshalb Agenten, die eine Seite in einem Browser öffnen. Ein KI-Crawler, der nur den HTML-Code einer Seite abruft, baut keinen Accessibility Tree auf; für ihn zählt nur, was im ausgelieferten HTML steht, nicht, was erst beim JavaScript-Rendering im Browser hinzukommt.
Den Accessibility Tree ansehen und prüfen
Wie der Accessibility Tree einer Seite aussieht, zeigen die Entwicklertools von Chrome: Dort lässt sich die Ansicht der Seitenelemente vom DOM auf den Accessibility Tree der ganzen Seite umschalten, samt Rolle und Name jedes Elements. Googles Prüfwerkzeug Lighthouse prüft in seiner experimentellen Kategorie Agentic Browsing automatisch einen Teil davon: die Barrierefreiheitsprüfungen, die für Agenten besonders wichtig sind, etwa ob jedes bedienbare Element einen Namen hat und ob die Rollen und die Verschachtelung der Elemente stimmen.
Klare Namen und passende Elemente helfen Menschen mit Screenreader und KI-Agenten gleichermaßen. Hier überschneidet sich die Arbeit am Accessibility Tree mit der digitalen Barrierefreiheit, die Websites für Menschen mit Behinderungen nutzbar macht.