Der Accessibility Tree ist der wichtigste Teil Ihrer Website, den niemand sieht. Denn ein Screenreader liest weder Ihre schönen Pixel noch Ihren rohen Quelltext – er liest diese vom Browser erzeugte, unsichtbare Struktur. Ist sie falsch, bekommt ein blinder Mensch falsche oder gar keine Informationen, egal wie perfekt die Seite aussieht. In diesem Ratgeber zeige ich Ihnen aus der Praxis, wie der Accessibility Tree entsteht, welche drei Angaben jeder Knoten trägt, warum eine als Button gestylte div darin schlicht verschwindet und wie Sie selbst in zwei Minuten sehen, was ein Screenreader tatsächlich vorgelesen bekommt.

Was ist der Accessibility Tree?

Der Accessibility Tree ist eine vom Browser erzeugte Datenstruktur, die als Schnittstelle zwischen Ihrem Code und der assistiven Technik dient. Der Browser leitet ihn aus dem DOM ab und reduziert ihn auf das, was für die Barrierefreiheit zählt: Rolle, Name, Zustand und Beziehungen jedes Bedienelements. Auf Deutsch könnte man ihn Barrierefreiheitsbaum nennen.

Entscheidend ist, was eine assistive Technik damit macht. Ein Screenreader, eine Sprachsteuerung oder eine Schalter-Steuerung greift nicht auf die sichtbare Seite zu, sondern genau auf diesen Baum. Er ist also die einzige Quelle, aus der diese Werkzeuge ihre Informationen ziehen.

Daraus folgt der zentrale Gedanke dieses Ratgebers. Was nicht korrekt im Accessibility Tree steht, existiert für einen blinden Menschen nicht. Die Optik einer Seite ist für ihn ohne Belang – nur der Baum zählt. Deshalb prüfen wir Barrierefreiheit immer auf der Ebene des Baums, nicht der Gestaltung.

Wer auf einen korrekten Baum angewiesen ist

Ein korrekter Accessibility Tree nützt einer ganzen Bandbreite von Menschen. Denn nicht nur Screenreader bauen darauf auf. Auch eine Sprachsteuerung und eine Schalter-Steuerung beziehen ihre Informationen ausschließlich aus diesem Baum.

Die Vielfalt der Nutzer ist groß. Ein blinder Mensch hört Rolle und Namen vorgelesen, ein motorisch eingeschränkter Nutzer steuert die Elemente per Sprache an, und mancher kombiniert eine Bildschirmlupe mit einem Screenreader. Sie alle scheitern an denselben Lücken, sobald der Baum unvollständig ist.

Hinzu kommt die rechtliche Ebene. Das Kriterium 4.1.2 Name, Rolle, Wert ist eine Anforderung der Stufe A und damit eine absolute Mindestvoraussetzung. Wer den Baum vernachlässigt, verfehlt also schon die unterste Stufe der WCAG. Und genau diese Stufe ist seit dem BFSG für viele Anbieter rechtlich verbindlich.

DOM, Accessibility Tree, assistive Technik: die Kette

Der Weg vom Code zum Nutzer verläuft über mehrere Stationen. Zuerst liest der Browser das HTML und baut daraus den DOM. Aus dem DOM berechnet er dann den Accessibility Tree, der nur die barrierefreiheitsrelevanten Informationen enthält. Diesen Baum reicht er über eine Schnittstelle des Betriebssystems an die assistive Technik weiter.

Am Ende dieser Kette steht das Hilfsmittel. Der Screenreader interpretiert den Baum und sagt dem Nutzer an, womit er es zu tun hat. Wichtig ist: Das Hilfsmittel kommuniziert mit dem Baum, nicht mit dem DOM und schon gar nicht mit den dargestellten Pixeln. Diese eine Einsicht erklärt, warum schöne Seiten trotzdem unzugänglich sein können.

Diese Trennung erklärt viele Barrieren. Eine Seite kann technisch funktionieren und optisch überzeugen – und trotzdem einen lückenhaften Baum erzeugen. Wie der DOM überhaupt aufgebaut ist, vertiefe ich im Ratgeber zur DOM-Struktur.

Rolle, Name, Zustand: die drei Angaben pro Element

Jeder Knoten im Accessibility Tree trägt einige wenige, entscheidende Angaben. Sie verraten dem Hilfsmittel, um was es sich handelt, wie es heißt und in welchem Zustand es ist. Genau das verlangt auch das Erfolgskriterium 4.1.2 Name, Rolle, Wert (Stufe A).

Angabe	Bedeutung	Beispiel
Rolle	Was ist das Element?	Button, Link, Überschrift, Kontrollkästchen
Name	Wie heißt es?	„Kommentar absenden“
Zustand / Wert	In welchem Zustand ist es?	aktiviert, aufgeklappt, deaktiviert

Diese Angaben entstehen unterschiedlich. Native HTML-Elemente bringen sie von selbst mit: Ein <button> hat automatisch die Rolle Button, ein Kontrollkästchen seinen Zustand. Fehlt eine dieser Angaben, weiß das Hilfsmittel nicht, was der Nutzer vor sich hat. Und im Zweifel sagt der Screenreader dann gar nichts oder etwas Falsches an.

Wie der Name berechnet wird

Der zugängliche Name eines Elements wird nicht beliebig gewählt, sondern nach einer festen Reihenfolge berechnet. Der Browser prüft mehrere mögliche Quellen und nimmt die mit der höchsten Priorität. Diese Reihenfolge zu kennen, erspart viel Rätselraten.

Die Rangfolge ist klar geregelt. Ganz oben steht ein aria-labelledby, danach ein aria-label, dann der native Bezug über eine Beschriftung, einen Alternativtext oder den sichtbaren Text, und ganz am Ende das title-Attribut. Ein aria-label übersteuert dabei das sichtbare Label – eine häufige Stolperfalle, wenn beide nicht übereinstimmen.

Hier lohnt ein genauer Blick. Steht im sichtbaren Text „Mehr erfahren“, im aria-label aber „Weiter“, hört ein blinder Mensch „Weiter“, während ein sehender „Mehr erfahren“ liest. Woher gute Namen kommen, vertiefe ich im Ratgeber zu Alternativtexten.

Warum CSS nichts ändert

Ein Grundsatz überrascht viele Entwickler: CSS hat keinerlei Einfluss auf den Accessibility Tree. Sie können ein Element noch so überzeugend gestalten – sein Aussehen ändert nichts an dem, was die assistive Technik bekommt. Der Baum kennt nur Semantik, keine Optik.

Das hat eine harte Konsequenz. Eine <div>, die per CSS exakt wie ein Button aussieht, ist im Baum trotzdem nur ein bedeutungsloser Knoten ohne Rolle und ohne Namen. Für das Auge ist sie ein Button, für den Screenreader ein Nichts.

Genau diese Lücke zwischen Sehen und Semantik ist die Wurzel vieler Barrieren. Wer Barrierefreiheit allein über das Design löst, übersieht den Baum vollständig. Und der Baum ist es, der zählt.

Versteckte Inhalte: was aus dem Baum verschwindet

Nicht alles aus dem DOM landet im Accessibility Tree. Der Browser entfernt nämlich bestimmte Elemente gezielt. Was mit display: none oder dem hidden-Attribut ausgeblendet ist, taucht im Baum gar nicht erst auf – für die assistive Technik existiert es nicht.

Bewusst steuern lässt sich das mit zwei Attributen. Mit aria-hidden="true" entfernen Sie ein Element aus dem Baum, obwohl es sichtbar bleibt – nützlich etwa für ein rein dekoratives Icon. Mit der Rolle presentation nehmen Sie einem Element dagegen nur seine Semantik, ohne es zu verstecken.

Hier lauert eine häufige Falle. Ein aria-hidden an der falschen Stelle blendet wichtige Inhalte für den Screenreader aus, während sie für das Auge sichtbar bleiben. Umgekehrt bleibt visuell verborgener, aber nicht ausgeblendeter Text im Baum erhalten – genau so funktionieren Hilfstexte nur für Screenreader. So lässt sich einem Icon eine unsichtbare, aber hörbare Beschriftung mitgeben.

Der häufigste Fehler: die div-Schaltfläche

Kein Fehler zeigt das Prinzip so deutlich wie die nachgebaute Schaltfläche. Vergleichen Sie eine <div onclick> mit einem echten <button>. Mit der Maus verhalten sich beide gleich, und optisch sind sie nicht zu unterscheiden.

Im Accessibility Tree aber liegen Welten dazwischen. Der echte Button erscheint als „Button“ mit seinem Namen, etwa „Kommentar absenden“. Die div hingegen erscheint als „generisch“, ohne Rolle und ohne Namen. Ein Screenreader sagt dazu schlicht nichts, und eine Sprachsteuerung kann sie nicht ansteuern. Für einen blinden Menschen ist die Schaltfläche damit unsichtbar.

Die Lösung ist denkbar einfach. Nutzen Sie das native Element, das es bereits gibt. Denn ein <button> bringt Rolle, Fokussierbarkeit und Tastaturbedienung von selbst mit – alles, was die div mühsam und fehleranfällig nachbilden müsste. Wie native Elemente die Tastaturbedienung sichern, zeige ich im Ratgeber zur Tastaturnavigation. Der einfachste Code ist hier zugleich der zugänglichste.

ARIA verändert nur den Accessibility Tree

Viele missverstehen, was ARIA eigentlich tut. ARIA verändert ausschließlich den Accessibility Tree – sonst nichts. Es ändert kein Aussehen, kein Verhalten und keine Tastaturbedienung, sondern nur die Rolle, den Namen, den Zustand oder die Eigenschaften eines Elements im Baum.

Daraus ergibt sich die erste Regel von ARIA. Nutzen Sie ARIA nur dann, wenn es kein passendes natives Element gibt. Denn ein <button> bringt sein korrektes Verhalten mit, während Sie es bei einer mit ARIA aufgewerteten div selbst per Skript nachbauen müssen – inklusive aller Tastatur- und Zustandslogik.

Falsch eingesetztes ARIA macht den Baum schlechter, nicht besser. Eine widersprüchliche Rolle oder ein überflüssiges Attribut verwirrt das Hilfsmittel mehr, als es hilft. Wann ARIA sinnvoll ist, vertiefe ich im Ratgeber zu ARIA in Webanwendungen.

Native HTML schlägt nachgebaute Elemente

Die verlässlichste Art, einen guten Baum zu erzeugen, ist erstaunlich einfach. Greifen Sie zu nativen HTML-Elementen, wo immer es eines gibt. Denn jedes von ihnen bringt seine korrekte Rolle, seinen Zustand und seine Tastaturbedienung bereits mit – ganz ohne Zusatzcode.

Die Liste ist überschaubar. Ein <button> liefert die Button-Rolle, ein <a href> den Link, ein <input> samt Typ das passende Feld, und <details> mit <summary> sogar ein aufklappbares Element. Auch Auswahllisten und Kontrollkästchen sind nativ vorhanden.

Der Gegenentwurf ist mühsam und fehleranfällig. Wer dasselbe aus einer div mit ARIA nachbaut, muss jede Rolle, jeden Zustand und jede Tastaturlogik selbst per Skript ergänzen. Meist bleibt dabei etwas auf der Strecke, und der Baum wird schlechter als das native Original. Deshalb ist weniger eigener Code hier fast immer die bessere Wahl.

Nicht nur Screenreader: auch die Sprachsteuerung

Der Accessibility Tree dient nicht allein dem Screenreader. Auch eine Sprachsteuerung greift auf dieselben Angaben zu. Sagt ein Nutzer „Klick Kommentar absenden“, sucht die Software im Baum nach einem Element mit der Rolle Button und dem Namen „Kommentar absenden“.

Das macht den korrekten Namen doppelt wichtig. Stimmt der zugängliche Name nicht mit der sichtbaren Beschriftung überein, findet die Sprachsteuerung das Element nicht. Der Nutzer ruft einen Befehl, und nichts geschieht – obwohl der Knopf direkt vor ihm liegt.

Auch Schalter-Steuerungen und andere Hilfsmittel bauen auf diesem Baum auf. Ein korrekter Accessibility Tree nützt also einer ganzen Bandbreite assistiver Technik gleichzeitig. Wie diese Werkzeuge im Detail arbeiten, zeige ich im Ratgeber zu Screenreadern. Ein sauberer Baum ist damit die gemeinsame Grundlage für sie alle.

Dynamische Inhalte: der Baum muss mitwachsen

Eine Seite steht heute selten still. Ändert sich der DOM durch JavaScript, aktualisiert der Browser auch den Accessibility Tree. Die assistive Technik erfährt von solchen Änderungen jedoch nur, wenn dabei die passenden Ereignisse ausgelöst werden.

Genau hier entstehen stille Fehler. Klappt ein Menü auf, ohne dass sich der Zustand im Baum ändert, bemerkt ein Screenreader-Nutzer davon nichts. Halten Sie deshalb Zustände wie aufgeklappt oder ausgewählt stets aktuell, etwa über aria-expanded.

Für eingeschobene Meldungen gilt dasselbe. Ein neuer Hinweis muss aktiv angekündigt werden, sonst geht er unter (4.1.3 Statusmeldungen). Der Baum spiegelt also nicht nur den Anfangszustand, sondern muss jede relevante Änderung nachvollziehen.

Den Accessibility Tree selbst ansehen

Sie müssen den Accessibility Tree nicht erraten – Sie können ihn direkt anschauen.

Aus der Praxis – sehen, was der Screenreader sieht: Öffnen Sie in Chrome die Entwicklertools und wechseln Sie zum Reiter „Accessibility“ (Barrierefreiheit). Wählen Sie nun ein beliebiges Bedienelement aus. Im Panel sehen Sie die berechnete Rolle, den zugänglichen Namen samt aller Quellen, die ihn beeinflussen, und den Zustand – also genau das, was eine assistive Technik bekommt. Prüfen Sie damit Ihre selbst gebauten Bedienelemente: Erscheint Ihr schicker Button als „Button“ mit klarem Namen? Oder steht dort „generisch“ und ein leerer Name? Im zweiten Fall hört ein Screenreader-Nutzer beim Fokussieren nichts Brauchbares. Wer es noch einfacher mag, nutzt eine Erweiterung wie WAVE, die Rollen und Namen direkt auf der Seite sichtbar macht. Dieser Blick verändert die Sicht auf die eigene Arbeit grundlegend.

Warum Overlays den Baum nicht reparieren

Jetzt wird klar, warum vorgeschaltete Overlay-Widgets das Problem nicht lösen. Denn ein Overlay arbeitet auf der sichtbaren Oberfläche oder schiebt nachträglich oberflächliches ARIA ein. Einen durchgängig korrekten Accessibility Tree kann es so nicht erzeugen.

Die falschen oder fehlenden Rollen und Namen bleiben im Kern bestehen. Ein Overlay kann eine fehlende Semantik nicht zuverlässig erraten, weil ihm der eigentliche Sinn der Elemente fehlt. Es übermalt das Symptom, statt die Ursache zu beheben. Und sobald sich die Seite ändert, beginnt das Spiel von vorn.

Die einzige verlässliche Lösung ist korrekter Code. Genau das ist der Grundgedanke von Access Code: Fehler dort beheben, wo sie entstehen – im Code, nicht im sichtbaren DOM. Ein Linter im Editor und ein Prüf-Gate im Pull Request sorgen dafür, dass schon der Quelltext einen sauberen Baum erzeugt.

Häufige Fehler im Accessibility Tree

Über viele Audits hinweg wiederholen sich dieselben Muster. Diese sieben sehe ich am häufigsten – und alle entstehen im Code:

• Interaktive div oder span: ein generischer Knoten ohne Rolle und Namen.
• Fehlender Name: ein Icon-Button, dessen zugänglicher Name leer bleibt.
• Falsche Rolle, die nicht zur Funktion des Elements passt.
• aria-hidden auf wichtigen Inhalten, die so aus dem Baum verschwinden.
• Widersprüchliches ARIA, das native Semantik überschreibt.
• Name aus der falschen Quelle, etwa ein übersteuerndes aria-label.
• Veralteter Zustand, der die echte Lage nicht mehr abbildet.

Auffällig ist dabei eines. Keiner dieser Fehler ist im Browser sichtbar. Genau deshalb fallen sie ohne einen Blick in den Baum oder einen Test mit assistiver Technik nie auf.

Der Baum und automatische Tests

Automatische Werkzeuge können einen Teil des Baums prüfen, aber nicht alles. Sie erkennen zuverlässig, wenn ein Button gar keinen Namen hat oder eine Rolle fehlt. Genau dort setzt Access Code an und meldet solche Fehler schon im Editor.

An ihre Grenzen stoßen Scanner jedoch beim Sinn. Ob ein zugänglicher Name wirklich passend ist, ob die gewählte Rolle der Funktion entspricht und ob ein Zustand im echten Gebrauch korrekt umschlägt, lässt sich nicht rein maschinell beurteilen. Das erfordert ein menschliches Urteil.

Deshalb braucht es beide Ebenen. Die automatische Prüfung fängt das Mechanische ab, die menschliche Prüfung beurteilt das Inhaltliche. Erst zusammen ergeben sie die Gewissheit, dass der Baum nicht nur formal vorhanden, sondern auch wirklich brauchbar ist. Diesen doppelten Weg gehen wir bei IFDB konsequent.

Häufige Fragen zum Accessibility Tree

Zum Abschluss die Fragen, die mir in der Praxis am häufigsten begegnen. Die Antworten fallen kurz und konkret aus.

Ist der Accessibility Tree dasselbe wie der DOM?

Nein. Der Browser leitet den Baum zwar aus dem DOM ab, reduziert ihn aber auf die barrierefreiheitsrelevanten Angaben. Der DOM ist für die Darstellung da, der Baum für die assistive Technik.

Beeinflusst CSS den Accessibility Tree?

Nein. Aussehen und Layout ändern den Baum nicht. Eine als Button gestylte div bleibt darin ein bedeutungsloser Knoten ohne Rolle und Namen.

Wozu dient ARIA im Accessibility Tree?

ARIA verändert ausschließlich den Baum – Rolle, Name, Zustand und Eigenschaften. Es ändert nichts Visuelles. Native HTML-Elemente sind aber meist die bessere Wahl.

So sorgen Sie für einen korrekten Accessibility Tree

Der Weg beginnt im Code und endet bei einem belastbaren Nachweis. Schon während der Entwicklung hilft Access Code: ein Linter im Editor und ein WCAG-Gate im Pull Request fangen falsche Rollen, fehlende Namen und überschriebene Semantik ab, bevor sie überhaupt live gehen. So entsteht von Anfang an ein sauberer Baum.

Ob der Baum am Ende wirklich stimmt, zeigt sich erst im Gebrauch. Hört ein blinder Mensch zu jedem Element die richtige Rolle und den richtigen Namen? Stimmt jeder Zustand? Das beurteilt kein automatischer Scanner allein. Mit Access Ready prüfen wir Ihre Anwendung mit echten Nutzern assistiver Technik und stellen ein rechtssicheres Zertifikat aus.

Ansatz	Setzt an	Korrekter Baum	Nachweis
Overlay-Widget	sichtbare Oberfläche	nein	nein
Reiner Scanner	messbare Code-Fehler	teils	nein
Access Code + Access Ready (IFDB)	Quelltext und echtes Erlebnis	ja	ja

Der Unterschied liegt im Ansatz. Ein Overlay übermalt die Oberfläche, wir reparieren die Quelle. So wird aus „sieht aus wie ein Button“ ein echtes „ist ein Button“ – im Baum, den der Screenreader wirklich liest. Und damit aus einer Seite, die nur aussieht wie barrierefrei, eine, die es im Kern ist.