Browser DevTools: Der Accessibility Tab in Chrome und Firefox

Jeder Browser erstellt aus dem DOM einen Accessibility Tree – ein vereinfachtes Modell der Seite, das Screenreadern und anderen assistiven Technologien als Grundlage dient. Die DevTools machen diesen Baum sichtbar und debuggbar. Für Entwickler ist das der direkteste Weg zu verstehen, was ein Screenreader "sieht" – ohne selbst einen Screenreader bedienen zu müssen.

Der Accessibility Tree: Was Screenreader sehen

Der Accessibility Tree ist eine parallele Darstellung des DOMs, die nur barrierefreiheits-relevante Informationen enthält. Jedes Element im Tree hat: einen Role (z.B. button, link, heading, navigation), einen Name (den zugänglichen Text, z.B. aus dem Label oder aria-label) und einen State (z.B. checked, expanded, disabled).

In Chrome öffnet man den Accessibility Tree über: DevTools > Elements > Accessibility Pane (rechte Seitenleiste). Alternativ kann man seit Chrome 90 die vollständige Tree-Ansicht aktivieren: DevTools > Experiments > "Enable full accessibility tree view in the Elements panel". Dann erscheint ein Toggle-Button im Elements-Panel, der zwischen DOM und Accessibility Tree umschaltet.

Firefox zeigt den Accessibility Tree unter: DevTools > Accessibility Tab. Dort ist der gesamte Baum navigierbar, mit Filteroptionen für bestimmte Rollen und Probleme.

Computed Properties: Name, Role, Value

Das Herzstück der Accessibility-Inspektion sind die Computed Accessibility Properties. Für jedes ausgewählte Element zeigen die DevTools:

Accessible Name: Der Text, den ein Screenreader als Namen des Elements vorliest. Berechnet aus: aria-label, aria-labelledby, -Element, Textinhalt, title-Attribut oder alt-Attribut – in dieser Prioritätsreihenfolge.

Role: Die semantische Rolle des Elements (native HTML-Rolle oder per role-Attribut überschrieben).

Accessible Description: Zusätzlicher Beschreibungstext (aus aria-describedby oder title).

In Chrome erscheinen diese Informationen im Accessibility Pane des Elements-Panels. In Firefox im Accessibility Tab unter "Properties". Wenn ein Element keinen zugänglichen Namen hat, wird das als Problem markiert – ein direkter Hinweis auf einen WCAG-Verstoß.

Chrome DevTools: Lighthouse und Contrast Overlay

Chrome integriert mehrere Barrierefreiheits-Features direkt in die DevTools:

Lighthouse Accessibility Audit: Unter DevTools > Lighthouse kann ein vollständiger A11y-Audit gestartet werden. Das Ergebnis ist ein Score von 0-100 mit detaillierten Befunden und Verbesserungsvorschlägen.

Kontrast-Anzeige: Beim Inspizieren eines Text-Elements zeigen die DevTools das Kontrastverhältnis und ob AA/AAA bestanden wird. Ein Klick auf die Kontrastanzeige öffnet einen Farbwähler mit Kontrastlinien.

CSS Overview: Unter DevTools > More Tools > CSS Overview werden alle Farbkombinationen der Seite aufgelistet, einschließlich Kontrastwarnungen. Ideal für einen schnellen Überblick über potenzielle Kontrastprobleme.

Rendering: Unter DevTools > Rendering lässt sich Farbfehlsichtigkeit simulieren – ähnlich wie beim Colour Contrast Analyser, aber direkt im Browser.

Firefox DevTools: Accessibility Inspector

Firefox bietet einen eigenständigen Accessibility Tab mit einigen Vorteilen gegenüber Chrome:

Vollständiger Tree-Browser: Der gesamte Accessibility Tree ist in einer Baumansicht navigierbar. Man kann Elemente anklicken, um sie auf der Seite zu markieren – und umgekehrt.

Check-Funktion: Firefox kann automatisch nach bestimmten Problemkategorien filtern: Kontrast, Tastaturfokus, Text-Labels. Bei aktivierter Prüfung werden problematische Elemente im Tree markiert.

Tab-Order-Visualisierung: Firefox kann die Tab-Reihenfolge der Seite visuell darstellen, indem nummerierte Markierungen an jedem fokussierbaren Element angezeigt werden. Das ist extrem hilfreich für die Prüfung der Tastaturbedienbarkeit.

Simulation: Auch Firefox bietet eine Simulation von Farbfehlsichtigkeit im Accessibility Tab.

Debugging-Workflow mit DevTools

Ein effektiver Barrierefreiheits-Debugging-Workflow mit den DevTools:

1. Element inspizieren: Rechtsklick > Untersuchen. Im Accessibility Pane prüfen: Hat das Element einen sinnvollen Namen? Stimmt die Rolle? Sind ARIA-Attribute korrekt?

2. Accessibility Tree vergleichen: Zwischen DOM- und Tree-Ansicht wechseln. Elemente, die im DOM vorhanden, aber im Tree fehlen, sind für Screenreader unsichtbar (z.B. durch aria-hidden).

3. Live-Editing: ARIA-Attribute direkt im DOM ändern und die Auswirkung im Accessibility Pane beobachten. So lassen sich Fixes testen, bevor man den Code ändert.

4. Tab-Reihenfolge testen: Tab drücken und beobachten, welche Elemente fokussiert werden. In Firefox die Tab-Order-Visualisierung nutzen.

Die DevTools ersetzen keinen Screenreader-Test, aber sie machen 80 % des Debuggings effizienter. Sie zeigen exakt, was die Accessibility-API an assistive Technologien weitergibt.