Der Accessibility Tree: Wie assistive Technik Ihre Website wirklich liest

Bevor es an den Accessibility Tree selbst geht, lohnt ein Schritt zurück: Wie werden Websites eigentlich gebaut, und wie arbeitet der Browser mit ihnen? Der Beitrag wird an manchen Stellen sehr technisch. Das lässt sich bei diesem Thema kaum vermeiden. Springen Sie an diesen Stellen einfach zum nächsten Abschnitt, das ist völlig in Ordnung.

Das DOM: Die Struktur hinter jeder Website

Um zu verstehen, was der Accessibility Tree ist und wie er entsteht, hilft ein Blick darauf, was der Browser aus dem Quellcode einer Website macht. Zentral ist hier das Document Object Model, kurz DOM.

Websites werden mit einer Auszeichnungssprache erstellt, in der Regel ist das HTML. Das gilt unabhängig davon, ob im Hintergrund eine serverseitige Sprache wie PHP dieses HTML erst generiert. Dieser fertige HTML-Code wird zusammen mit Styling (CSS) und Skripten (meist JavaScript) vom Server ausgeliefert und vom Browser interpretiert.

Aus diesem Quellcode baut der Browser das DOM: eine Baumstruktur, in der alle Elemente einer Website mit ihren Eigenschaften, Zuständen und Inhalten in ihrer hierarchischen Reihenfolge stehen. Dabei ist es egal, ob ein Element wirklich inhaltliche Bedeutung hat oder nur der Struktur bzw. dem Layout dient. Im DOM landet erstmal alles.

Über das DOM lässt sich mit der Website kommunizieren, gerade bei dynamischen Websites ein zentraler Baustein. In der Regel greift JavaScript auf das DOM zu und kann Informationen ergänzen, ändern oder löschen. Das DOM ist also die Schnittstelle.

Ein paar Beispiele, wo das im Alltag passiert: eine personalisierte Ansprache nach Eingabe des Namens, das Auswählen einer Checkbox, das direkte Ändern von Inhalt und Kontext oder die Auswahl einer Farbe, um das Design einer Website den eigenen Wünschen anzupassen. All das läuft in der Regel über JavaScript und endet in einer Änderung am DOM.

Aus dem DOM baut der Browser außerdem die tatsächliche Ansicht, die im Fenster erscheint. Dabei versucht er, Fehler im Code möglichst auszubügeln oder zumindest so darzustellen, dass nichts sichtbar kaputt wirkt: Fehlerhaftes oder unvollständiges HTML korrigiert der Browser in der Regel automatisch.

Vom DOM zum Accessibility Tree

Aus dem DOM bildet der Browser den sogenannten Accessibility Tree. Auch das ist (wie der Name schon sagt) eine Baumstruktur, die die technische Struktur einer Website abbildet. Assistive Technologien wie Spracheingabe, Screenreader oder Braillezeile nutzen ihn, um mit den Inhalten einer Website zu interagieren.

Bildet der Accessibility Tree eine Website nun eins zu eins ab, so wie der DOM? Nein. Und genau hier lohnt der genaue Blick. Während im DOM jedes Element einer Website erscheint, werden im Accessibility Tree reine Strukturelemente komplett ignoriert. Ein assistives Werkzeug kommuniziert ausschließlich mit dem Accessibility Tree, nicht mit dem DOM und schon gar nicht mit der grafischen Darstellung.

Nur was im Accessibility Tree steht, existiert z. B. für einen Screenreader, egal wie die gerenderte, grafische Darstellung im Browser aussieht. Mit diesen Elementen kann interagiert werden: Sie werden inhaltlich wiedergegeben, oder auf sie kann zugegriffen und sie können gesteuert werden, also z. B. ein Formular ausgefüllt oder die Seitennavigation bedient werden.

Ein wichtiger Unterschied zum DOM: Der Accessibility Tree besteht nur aus dem, was tatsächlich korrekt ausgezeichnet ist. Anders als der Browser beim Rendering versucht er nicht, fehlerhaftes oder unvollständiges Markup zu reparieren oder wohlwollend zu interpretieren.

Der Accessibility Tree ist also die technische und logische Auszeichnung einer Website, mit der assistive Technologie sie wiedergeben und mit ihr interagieren kann. Daran zeigt sich auch, warum die logische Reihenfolge im Code für die Bedienung wichtiger ist als die rein visuelle Darstellung, und warum man sich bei der Interaktion nicht auf visuelle Hinweise allein verlassen sollte.

Wie sieht das konkret aus? Generische Strukturelemente wie ein <div> werden in der Regel ignoriert. Sie tragen meist nur Klassen oder IDs, über die die grafische Darstellung gesteuert wird: zum Beispiel ein Container, der die visuelle Breite einer Website auf 2000 Pixel begrenzt und sie im Browser zentriert. Für assistive Technik ist das komplett irrelevant.

Der umgekehrte Fall zeigt sich am Beispiel von oben: <header>, <div class="wrapper"> und <footer> stehen im DOM als Geschwister auf derselben Ebene, und genau das bleibt auch im Accessibility Tree so. <header> wird zur Rolle banner, <footer> zur Rolle contentinfo, und das <main> aus dem <div class="wrapper"> zur Rolle main, alle drei gleichrangig und gleichzeitig als Landmarks nutzbar. Nur der <div> selbst fällt weg, die Geschwisterstruktur der semantischen Elemente bleibt erhalten.

Name, Rolle, Wert: Das WCAG-Erfolgskriterium 4.1.2

Andere Elemente wie Buttons, Formularfelder, Überschriften oder Absätze erscheinen dagegen als das, was sie sind: mit einem Namen, ggf. einer Beschreibung, einer Rolle und einem Status bzw. Wert, der sie beschreibt. Mit diesen Informationen baut assistive Technik dann die Ausgabe bzw. die Bedienbarkeit für die jeweiligen Nutzenden auf.

Wer sich mit den Erfolgskriterien der WCAG beschäftigt, kennt diese Begriffe vielleicht schon: „Name, Rolle, Wert“ ist das Erfolgskriterium 4.1.2 der Stufe A. Über den Accessibility Tree wird nochmal deutlicher, warum es existiert und wie zentral es ist. Wer diesen Baum vernachlässigt, verfehlt damit schon die unterste WCAG-Stufe, und die ist für private Anbieter seit dem BFSG sowie für öffentliche Stellen über die BITV bzw. die entsprechenden Landesgesetze rechtlich verbindlich.

Standard-HTML-Elemente wie <button>, <input>, Überschriften oder Landmark-Elemente wie <nav> bringen Rolle und Funktion von Haus aus mit und reichern den Accessibility Tree entsprechend an. Bei diesen Standardelementen braucht es also in der Regel keine zusätzlichen Anpassungen, damit sie im Accessibility Tree richtig ankommen. Trotzdem lohnt es sich mitunter, sie nach Best Practices zu optimieren oder bei Bedarf gezielt zu verfeinern, etwa mit einer präziseren Beschriftung.

Eine Überschrift dritter Ordnung wird über ein <h3>-Element genauso im Accessibility Tree verarbeitet. Formularelemente oder Buttons werden direkt als fokussierbar erkannt, ihr Wert wird ausgegeben und bei einer Eingabe entsprechend aktualisiert, und kann dann von der assistiven Technik entsprechend verarbeitet werden.

Das zeigt auch, warum man nach Möglichkeit immer natives HTML verwenden sollte, statt Elemente selbst nachzubauen. Ein Button gehört also als <button> ausgezeichnet, nicht optisch nachgebaut über ein gestyltes <div>. Wichtig ist außerdem, das System bei dynamischen Inhalten über Live-Änderungen zu informieren, damit assistive Technik mitbekommt, wenn sich etwas ändert, ohne dass die Seite neu geladen wird.

Custom-Elemente: Wenn Buttons unsichtbar werden

Ein häufiges Problem entsteht, wenn Elemente selbst gebaut werden, statt die vorhandenen HTML-Elemente zu nutzen: Buttons und Links werden nicht als solche ausgezeichnet, sondern nur als <div> oder <span>, über eine Klasse oder ID gestylt und per JavaScript bedienbar gemacht.

Diese Werte und Daten kommen dann nie im Accessibility Tree an, assistive Technik kann mit ihnen nichts anfangen. Oft fehlen zusätzlich das nötige JavaScript und/oder die ARIA-Attribute, um wirklich die komplette Funktionalität herzustellen: Tastaturbedienung, Fokus, korrekte Ansage und eine korrekte Beschriftung, die auch für Sprachsteuerung wichtig ist.

Übrigens: Genau darüber funktioniert auch die Sprachsteuerung, die die meisten von uns täglich am Smartphone oder anderen „smarten“ Geräten nutzen. Wenn Sie „Tippe auf Absenden“ sagen, muss die Sprachsteuerung im Accessibility Tree erst einen Knoten finden, der wirklich „Absenden“ heißt und als Button erkennbar ist, sonst passiert schlicht nichts.

Kurz im Code: Ein als Button gestylter <div> ist im Accessibility Tree schlicht nicht vorhanden: kein Name, keine Rolle, kein Fokus. Ein Blick auf beide Varianten macht den Unterschied konkret.

Die erste Variante sieht optisch nach einem Button aus, ist aber technisch nur ein anklickbarer Textblock:

<!-- Sieht aus wie ein Button, ist aber keiner -->
<div class="button" onclick="submitForm()">Absenden</div>

Weder das class="button" noch das onclick-Attribut sagen dem Browser, dass hier eine Bedienoberfläche existiert, sie steuern nur das Aussehen und einen Klick-Handler. Entsprechend mager fällt aus, was im Accessibility Tree ankommt: ein generischer Knoten ohne Namen, den kein Screenreader als Bedienelement ansagt und den auch die Tastatur nicht erreicht.

{
    "role": "generic",
    "name": ""
}

Die zweite Variante nutzt stattdessen das native <button>-Element:

<!-- Bringt Rolle, Fokus und Tastaturbedienung automatisch mit -->
<button type="submit">Absenden</button>

Ohne eine einzige Zeile ARIA oder JavaScript bringt der Browser hier von Haus aus alles mit, was für die Bedienung nötig ist: Rolle, Name, Fokussierbarkeit und Tastatursteuerung. Im Accessibility Tree zeigt sich das als vollständiges, sofort nutzbares Objekt:

{
    "role": "button",
    "name": "Absenden",
    "focusable": true
}

Genau dieser Unterschied entscheidet, ob ein Screenreader „Absenden, Schaltfläche“ ansagt oder gar nichts.

Den Accessibility Tree in den DevTools prüfen

Die gute Nachricht: Mit den Browser-Entwicklungswerkzeugen lässt sich der Accessibility Tree direkt einsehen, inklusive aller Werte, die ein einzelnes Element mitbringt.

Im sich öffnenden Fenster wechseln Sie (dort, wo auch „Styles“, „Computed“ und „Layout“ stehen) auf den Tab „Accessibility“. Mit „Show accessibility tree“ schalten Sie die Ansicht auf den Accessibility Tree anstelle des DOMs um; auch ohne diesen Schalter sehen Sie bereits die ARIA-Attribute und berechneten Werte des ausgewählten Elements.

In Firefox erreichen Sie den Baum direkt über den Tab „Barrierefreiheit“ in der Navigation der Entwicklerwerkzeuge, die Bedienung ist ansonsten analog zu Chrome. In Safari gibt es diese Ansicht nicht als eigenen Tab: Aktivieren Sie zunächst unter Einstellungen → Erweitert das Entwickler-Menü, öffnen Sie dann den Web-Inspector. Die Accessibility-Eigenschaften finden sich dort etwas versteckt im Node-Bereich, statt so prominent wie bei Chrome oder Firefox. Für den Arbeitsalltag empfiehlt sich deshalb Chrome, Firefox oder ein anderer Chromium-Browser, das spart gegenüber Safari ein paar Klicks und ist auch angenehmer in der Bedienung.

In dieser Ansicht lassen sich Rollen und Zustände der Elemente nachvollziehen. Es wird klar, warum manche Elemente nicht oder falsch angesagt werden oder gar nicht bedienbar sind. Auch fehlerhafte oder überschriebene Beschriftungen über aria-label oder aria-labelledby lassen sich hier identifizieren. Der Accessibility Tree zeigt genau die Basis, mit der assistive Technik tatsächlich arbeitet.

Ein Nebeneffekt 2026: Auch KI-Agenten lesen im Accessibility Tree

2026 ist der Accessibility Tree nicht mehr nur unter Barrierefreiheits-Expertinnen und -Experten ein Thema, sondern zunehmend auch bei Marketing- und SEO-Fachleuten, in dem Zusammenhang manchmal GEO genannt, Generative Engine Optimization. Der Grund: Immer mehr KI-Agenten sind selbstständig im Browser unterwegs. Browser-Agenten wie ChatGPT Atlas, Claude oder die zahlreichen Automatisierungs-Frameworks lesen eine Seite nicht wie ein Mensch über die Pixel, sondern greifen bevorzugt auf genau diese Struktur zu: Rolle, Name und Zustand jedes interaktiven Elements, kompakt als Text statt als Bild.

Das hat handfeste Gründe. Ein Screenshot kostet viele Tokens, weil ein Modell erst aus Pixeln erschließen muss, was überhaupt klickbar ist. Der Accessibility Tree sagt es direkt und ohne Rätselraten: Rolle, Name, Zustand pro Element. OpenAI schreibt in den eigenen Hinweisen für Website-Betreiber (öffnet in neuem Tab) offen, dass ChatGPT Atlas ARIA-Attribute nutzt, um Seitenstruktur und interaktive Elemente zu verstehen, und empfiehlt Betreibern ausdrücklich, ihre Website barrierefreier zu machen, damit der Agent sie besser versteht. Auch verbreitete Automatisierungs-Bibliotheken wie browser-use oder Microsofts Playwright greifen standardmäßig auf Accessibility-Tree-Snapshots zurück, wenn sie mit Websites interagieren, nicht auf Screenshots.

Barrierefreie Websites werden von diesen Agenten also spürbar wohlwollender „gelesen“ als solche mit lückenhaftem Markup. Trotzdem sollte klar bleiben: Am Ende sind es Menschen, die eine KI nach Informationen fragen oder einen Agenten eine Aufgabe erledigen lassen, und die genauso von einer barrierefreien Umsetzung profitieren wie die Menschen, die eine Website direkt mit Screenreader oder Tastatur nutzen. Für die KI zu optimieren, sollte deshalb nie das Ziel sein. Sie profitiert einfach mit, wie jede und jeder andere auch, der oder die auf einen sauberen Accessibility Tree angewiesen ist.