Definition: Der Accessibility Tree ist eine Struktur, die der Browser parallel zum DOM aufbaut. Für jedes relevante Element enthält er die Rolle, den Namen, den Zustand und gegebenenfalls eine Beschreibung. Screenreader und andere assistive Technologien lesen diese Struktur über die Barrierefreiheits-Schnittstelle des Betriebssystems – nicht das, was auf dem Bildschirm zu sehen ist [1][2].
Englisch: Accessibility tree · Zuletzt geprüft: 27. September 2026
Wie er entsteht
Der Browser liest das HTML und ordnet jedem Element eine Rolle zu: <button> wird zur Schaltfläche, <nav> zur Navigation, <h2> zur Überschrift der Ebene 2. Welches Element welche Rolle bekommt, legt die W3C-Spezifikation HTML-AAM fest [2]. ARIA-Attribute können diese Rollen ergänzen oder überschreiben. Den Namen berechnet der Browser nach eigenen Regeln – mehr dazu unter zugänglicher Name.
Auch CSS wirkt mit. Was display: none oder visibility: hidden hat, fehlt im Baum. Mit CSS erzeugter Text aus ::before und ::after kann dagegen darin auftauchen. Reine Layout-Elemente ohne Bedeutung, etwa viele <div>s, bleiben ohne Rolle.
Der Browser gibt den Baum über eine Schnittstelle des Betriebssystems weiter – unter Windows zum Beispiel UI Automation, unter macOS die Accessibility API. Dort greift der Screenreader zu [3].
Ein Beispiel
| HTML | Im Accessibility Tree |
|---|---|
<button>Senden</button> | Schaltfläche, Name „Senden“ |
<a href="/kontakt/">Kontakt</a> | Link, Name „Kontakt“ |
<h2>Versand</h2> | Überschrift, Ebene 2, Name „Versand“ |
<input type="checkbox" checked> mit <label> AGB | Kontrollkästchen, Name „AGB“, aktiviert |
<div class="btn">Senden</div> | nur Text, keine Rolle, nicht bedienbar |
Die letzte Zeile ist der Kern vieler Barrieren: Optisch sind der erste und der letzte Eintrag gleich. Im Baum hat nur einer eine Rolle.
So sehen Sie ihn
In Chrome öffnen Sie die Entwicklerwerkzeuge, wählen ein Element und den Bereich „Accessibility“. Dort stehen Rolle, Name und Eigenschaften, auf Wunsch auch der ganze Baum der Seite [4]. Firefox hat dafür einen eigenen Barrierefreiheits-Inspektor [5]. Ein Blick dort zeigt oft in Sekunden, warum ein Button stumm bleibt.
Häufige Missverständnisse
- „Was man sieht, steht auch im Baum.“ Nein. Ein gestyltes
<div>sieht aus wie ein Button und ist im Baum nur Text. - „Versteckt ist versteckt.“ Visuell ausgeblendeter Text (etwa mit einer
sr-only-Klasse) bleibt im Baum und wird vorgelesen.aria-hidden="true"entfernt ein Element aus dem Baum, aber nicht aus der Tab-Reihenfolge. - „ARIA repariert alles.“ ARIA ändert nur den Eintrag im Baum, nicht das Verhalten. Mehr dazu unter ARIA.
Wie Reviseberg damit umgeht
axe-core berechnet Rollen und Namen nach denselben Regeln wie der Browser. Reviseberg meldet damit unter anderem Bedienelemente ohne Namen, ungültige Rollen und Elemente, die mit aria-hidden aus dem Baum genommen, aber noch fokussierbar sind. Das Protokoll des Tastatur-Agenten nennt bei jedem Schritt Rolle und Namen des fokussierten Elements. Was ein bestimmter Screenreader daraus tatsächlich vorliest, prüft Reviseberg nicht. Ein Screenreader-Agent ist heute nicht Teil von Reviseberg. Dafür gibt es die manuelle Prüfung mit NVDA oder VoiceOver.
Verwandte Begriffe
Zugänglicher Name · ARIA · Semantisches HTML · Screenreader · Assistive Technologie