Der Accessibility Tree: So sehen Screenreader Ihre Webseite

Screenreader lesen nicht den HTML-Quellcode oder das visuelle Layout einer Webseite. Sie lesen den Accessibility Tree – eine parallele Baumstruktur, die der Browser aus dem DOM ableitet. Jeder Knoten im Accessibility Tree enthält Informationen über Name, Rolle, Wert und Zustand eines Elements. Wenn Ihre Webseite korrekt semantisches HTML und ARIA-Attribute verwendet, ist der Accessibility Tree vollständig und aussagekräftig. Fehlen diese Informationen, ist die Seite für Screenreader-Nutzer unbrauchbar. EN 301 549 und das BFSG setzen einen korrekten Accessibility Tree implizit voraus.

Wie der Accessibility Tree entsteht

Der Browser erstellt den Accessibility Tree in mehreren Schritten: 1. DOM-Parsing: Der HTML-Quellcode wird in den DOM-Baum umgewandelt. 2. Semantik-Extraktion: Aus den HTML-Elementen werden implizite ARIA-Rollen abgeleitet – <button> wird zu role="button", <nav> zu role="navigation". 3. ARIA-Overlay: Explizite ARIA-Attribute überschreiben oder ergänzen die implizite Semantik. 4. Namensberechnung: Der zugängliche Name wird nach dem W3C Accessible Name and Description Computation (AccName) Algorithmus berechnet – aus aria-labelledby, aria-label, <label>, alt-Text oder Textinhalt. 5. Pruning: Elemente mit aria-hidden="true", display: none, visibility: hidden oder rein dekorative Elemente (role="presentation") werden aus dem Baum entfernt. Das Ergebnis ist eine schlankere Version des DOM, die nur barrierefreiheitsrelevante Informationen enthält. WCAG 4.1.2 verlangt, dass dieser Baum vollständig und korrekt ist.

Name, Role, Value – die drei Säulen

Jeder Knoten im Accessibility Tree besteht aus drei Kerninformationen, die WCAG 4.1.2 verlangt: Name (Accessible Name): Der Text, der das Element identifiziert. Quellen sind (in Prioritätsreihenfolge): aria-labelledby, aria-label, <label>, alt-Attribut, title-Attribut, Textinhalt. Ein Element ohne Namen ist für Screenreader-Nutzer nicht identifizierbar. Role (Rolle): Die Funktion des Elements – Button, Link, Checkbox, Navigation, etc. Implizit durch das HTML-Element oder explizit durch role-Attribut. Die Rolle bestimmt, welche Interaktionen der Nutzer erwartet. Value (Wert): Der aktuelle Wert interaktiver Elemente – der Text eines Eingabefelds, die Position eines Sliders (aria-valuenow), der ausgewählte Eintrag einer Combobox. Zusätzlich kommunizieren States (Zustände) den aktuellen Zustand: aria-expanded, aria-checked, aria-selected, aria-disabled, aria-invalid. EN 301 549 Abschnitt 11.4.1.2 übernimmt diese Anforderung vollständig.

Der Accessibility Tree in Browser DevTools

Chrome DevTools: Öffnen Sie die DevTools (F12), wechseln Sie zum Reiter „Elemente", wählen Sie ein Element aus und klicken Sie auf den Reiter „Barrierefreiheit" im unteren Bereich. Dort sehen Sie den Accessibility-Tree-Knoten mit Name, Rolle und ARIA-Attributen. Seit Chrome 90 gibt es auch eine vollständige Baumansicht unter „Barrierefreiheit" → „Ganzen Barrierefreiheits-Baum anzeigen". Firefox: Firefox bietet einen eigenen Accessibility-Inspektor unter Entwickler-Werkzeuge → Barrierefreiheit. Er zeigt den gesamten Baum und markiert Probleme wie fehlende Namen oder Kontrastfehler farblich. Edge: Identisch mit Chrome DevTools (Chromium-Basis). Safari: Web Inspector → Elements → Node → Accessibility zeigt ARIA-Eigenschaften. Praxistipp: Klicken Sie im Accessibility Tree auf verschiedene Elemente und prüfen Sie: Hat jedes interaktive Element einen Namen? Stimmt die Rolle? Werden Zustandsänderungen reflektiert? Diese manuelle Prüfung ergänzt automatisierte Tests und ist für BFSG-Konformität unverzichtbar.

Häufige Probleme im Accessibility Tree

1. Fehlende Namen: Ein <button><svg>...</svg></button> ohne aria-label hat keinen zugänglichen Namen – der Screenreader sagt nur „Button". 2. Falsche Rollen: Ein <div onclick="..."> ohne role="button" erscheint als generischer Container – nicht interaktiv. 3. Nicht-aktualisierte Zustände: Ein Akkordeon-Button, dessen aria-expanded nicht per JavaScript aktualisiert wird, zeigt immer „zugeklappt". 4. Unsichtbare aber zugängliche Elemente: Ein Element mit opacity: 0 ist im Accessibility Tree vorhanden und per Tastatur erreichbar – verwirrend für Screenreader-Nutzer. 5. Redundante Informationen: Ein <button aria-label="Suchen"><img alt="Suchen">Suchen</button> liest dreifach „Suchen". 6. aria-hidden auf fokussierbaren Elementen: Das Element ist per Tastatur erreichbar, aber im Accessibility Tree unsichtbar – ein „Geisterelement". Alle diese Probleme verstoßen gegen WCAG 4.1.2 und gefährden die BFSG-Konformität.

Accessibility Tree und automatisierte Tests

Automatisierte Testing-Tools arbeiten intern mit dem Accessibility Tree: axe-core prüft, ob alle interaktiven Elemente einen zugänglichen Namen haben, ob Rollen korrekt sind und ob ARIA-Attribute valide Werte enthalten. Lighthouse (Chrome) führt axe-basierte Audits durch und zeigt den Accessibility Tree in der Ergebnisansicht. Pa11y prüft den Accessibility Tree gegen WCAG-Kriterien. bf-check analysiert den Accessibility Tree und erkennt fehlende Namen, falsche Rollen und Zustandsprobleme. Testing-Strategie: Automatisierte Tools erkennen nur strukturelle Probleme im Accessibility Tree (ca. 30-40% aller Barrieren). Semantische Korrektheit (z. B. ob ein Name sinnvoll ist) erfordert manuelle Prüfung. Für BFSG-Konformität empfiehlt EN 301 549 eine Kombination aus automatisierten Tests, manuellem Audit und Nutzertests. Integrieren Sie Accessibility-Tree-Prüfungen in Ihre CI/CD-Pipeline, um Regressionen frühzeitig zu erkennen.