Konzepte

Accessibility Tree

Auch: a11y tree, accessibility object model, AOM

Die interne Datenstruktur, die Browser und Betriebssysteme aus dem DOM aufbauen und dabei jedes Element einer Rolle, einem Namen, einem Zustand und Beziehungen zuordnet — die Daten, die Screenreader und andere assistive Technologien tatsächlich traversieren.

Der Accessibility Tree ist die betriebssystemseitige Datenstruktur, die Screenreader und andere assistive Technologien tatsächlich verarbeiten. Wird eine Seite im Browser geöffnet, baut der Browser zwei Bäume auf: den DOM-Baum (die reguläre HTML-Hierarchie) und den Accessibility Tree — eine parallele Struktur, die aus dem DOM abgeleitet wird, aber Barrierefreiheits-Metadaten enthält.

Das Verständnis des Accessibility Tree erklärt rund 80 % des sonst schwer nachvollziehbaren Verhaltens von ARIA, Screenreadern und Debugging-Sitzungen zu der Frage „Warum wird das nicht angekündigt?“.

Was er enthält

Jeder Knoten im Accessibility Tree besitzt:

  • Rolle — was das Element ist: Schaltfläche, Link, Überschrift, Navigation, Dialog. Abgeleitet aus dem HTML-Elementtyp oder einem expliziten ARIA-role="...".
  • Name — wie das Element bezeichnet wird. Aus Beschriftungstext, alt-Attribut, aria-label, aria-labelledby oder berechnetem Textinhalt.
  • Beschreibung — zusätzlicher Kontext. Aus aria-describedby- oder title-Attributen.
  • Zustand — aktueller Zustand: gedrückt, ausgeklappt, aktiviert, beschäftigt. Aus HTML-Attributen (disabled, required) oder ARIA (aria-pressed, aria-expanded).
  • Eigenschaften — Beziehungen und Metadaten: aria-controls, aria-owns, aria-haspopup.

Screenreader traversieren diesen Baum und kündigen jeden Knoten anhand dieser Felder an. Die Tab- und Pfeiltastennavigation erfolgt über den Baum, nicht über den DOM.

Warum rein visueller Inhalt verschwindet

Ein <div onclick="...">, das wie eine Schaltfläche aussieht, hat keine Rolle im Accessibility Tree — der Browser erkennt ein generisches <div> und trägt es als role="generic" ein (de facto unsichtbar für assistive Technologien). Der onclick-Handler wird nicht in den Accessibility Tree übernommen, weil dieser ausschließlich abbildet, was der Browser aus dem HTML-Elementtyp ableitet.

Deshalb ist semantisches HTML auf der grundlegendsten Ebene wichtig: nicht wegen Stil oder Konvention, sondern weil semantische HTML-Elemente den Accessibility Tree automatisch mit den richtigen Rollen befüllen. Nicht-semantisches Markup erzeugt einen Div-Baum, den Screenreader nicht sinnvoll verarbeiten können.

Die Aufgabe von ARIA im Baum

ARIA existiert speziell dazu, den Accessibility Tree in Fällen zu befüllen, in denen natives HTML kein passendes Element bietet. role="combobox" weist den Browser an, für ein Element, das sonst als generisch erscheinen würde, einen combobox-Knoten in den Baum einzutragen. aria-expanded="true" setzt eine Zustandseigenschaft auf diesem Knoten.

ARIA verändert nicht den DOM. Es verändert, was der Browser in den Accessibility Tree schreibt.

Wie man ihn inspiziert

Die Browser-DevTools legen den Accessibility Tree heute direkt offen:

  • Chrome / Edge DevTools — Im Elements-Panel zeigt der Accessibility-Tab (rechte Spalte) die berechneten Barrierefreiheitseigenschaften des ausgewählten Knotens. Das Umschalten auf „Vollständiger Accessibility Tree“ (Chrome-Flag in einigen Versionen) stellt den Baum als Seitenleiste dar.
  • Firefox DevTools — Das Accessibility-Panel (Symbol in der Symbolleiste) zeigt eine dedizierte Accessibility-Tree-Ansicht, ähnlich der Elements-Ansicht, aber in den Begriffen des Accessibility Tree dargestellt.
  • Safari Web Inspector — Der Audit-/Accessibility-Tab bietet eine vergleichbare Inspektionsmöglichkeit.

Sobald der Accessibility Tree sichtbar ist, lässt sich die Frage „Warum wird das nicht angekündigt?“ empirisch beantworten. Die Antwort lautet fast immer: Der Knoten im Accessibility Tree hat eine andere Rolle als erwartet, oder sein Name ist leer, oder sein Zustand ist falsch.

Warum „Accessibility Tree“ das bessere mentale Modell als „ARIA“ ist

Entwickler, die ARIA erlernen, ohne den Accessibility Tree zu verstehen, neigen dazu, ARIA-Attribute in der Hoffnung zu streuen, dass Screenreader sie aufgreifen. Entwickler, die den Accessibility Tree verstehen, wissen, dass ARIA’s Aufgabe darin besteht, spezifische Felder in spezifische Baumknoten zu schreiben — und dass die direkte Inspektion des Baums schneller ist als jedes Raten.