NCA Social Media
Erstellt:
Aktualisiert:
Autor:
Roland Golla
Grüner Knotenbaum mit gelbem DOM Wegweiser und Kopfhörern für Screenreader

Was ist das Document Object Model (DOM)?

Das Document Object Model (DOM) ist die Baumstruktur, in die der Browser jedes HTML Dokument übersetzt. Aus diesem Baum baut der Browser den Accessibility Tree, den Screenreader und andere assistive Technologien auslesen, deshalb entscheidet das DOM darüber, ob eine Seite barrierefrei ist.
Jedes Element, jedes Attribut und jeder Text wird im DOM zu einem Knoten. JavaScript liest und ändert diese Knoten, Frameworks wie React, Vue oder Astro erzeugen sie. Was Nutzer auf dem Bildschirm sehen, ist nur eine Darstellung dieses Baums. Was ein Screenreader vorliest, ist eine andere. Beide Darstellungen stammen aus derselben Quelle.
Für die digitale Barrierefreiheit heißt das: Sauberes Markup, eine logische Reihenfolge und korrekt gemeldete Änderungen im DOM sind die Grundlage. Die WCAG 2.2 prüfen genau das, etwa mit den Kriterien 1.3.1 Info und Beziehungen, 1.3.2 Bedeutungstragende Reihenfolge und 4.1.2 Name, Rolle, Wert. Über das BFSG sind diese Kriterien in Deutschland für viele Onlineshops und Dienste verbindlich.
Inhalt

DOM und Barrierefreiheit mit NCA: Schnelle Hilfe vom Experten

Wir schauen bei Barrierefreiheit zuerst in den gerenderten Baum, nicht in das Design. Unsere Frontends entstehen mit Astro, React und Vue, und jedes davon erzeugt DOM auf eigene Weise. Deshalb prüfen wir den Accessibility Tree im Browser, testen mit Screenreadern und sichern das Ergebnis mit axe-core in Cypress ab. Die Tests laufen in GitHub Actions oder GitLab CI, die Ergebnisse landen in Cypress Cloud. So fällt ein kaputter Button auf, bevor er live geht.
Dazu passen unsere Leistungen rund um Accessibility Webdesign und Frontend, automatisiertes Accessibility Testing mit axe DevTools und Cypress, Lighthouse Accessibility Audits, die Analyse mit den Firefox Accessibility Testing Tools und unsere Frontend Development Beratung für Komponenten, die sauberes DOM erzeugen.
Lass uns sprechen
Finde das passende Angebot für dein Projekt
Anfrage-Konfiguration
Starten Sie Ihre Anfrage
Projektart
Infos
Nachricht

Eliminierung technischer Schulden mit PHPStan, Rector PHP und PHPUnit. Über 20 Jahre Praxiserfahrung in skalierbaren Backends.

CORE EXPERTISE

Gesetzliche Konformität & Inklusion. Optimierung von Performance und Conversion durch radikal nutzerzentriertes, universelles Design.

BFSG COMPLIANT

Skalierbare KI-Systeme mit echtem Code Ownership. CI/CD, Backup-Strategien und Infrastruktur, die mit deinem Team wächst.

ENTERPRISE READY

Vom DOM zum Accessibility Tree

Sobald der Browser eine Seite lädt, baut er das DOM. Parallel dazu entsteht ein zweiter Baum: der Accessibility Tree. Er ist eine gefilterte Sicht auf das DOM. Rein dekorative Elemente fallen heraus, alles Bedeutungstragende bleibt drin. Über die Accessibility Schnittstelle des Betriebssystems fragen Screenreader wie NVDA, JAWS, VoiceOver oder TalkBack diesen Baum ab.
Jeder Knoten im Accessibility Tree trägt vier Informationen:
  • Rolle: Was ist das Element? Button, Link, Überschrift, Checkbox, Liste.
  • Name: Wofür ist es da? Der Text im Button, das Label am Feld, der Alternativtext am Bild.
  • Zustand: Ist die Checkbox aktiviert, ist das Menü aufgeklappt, ist das Feld ungültig?
  • Beziehungen: Welches Label gehört zu welchem Feld, welche Fehlermeldung beschreibt welche Eingabe?
Diese Kernkonzepte beschreibt unser Eintrag Name, Rolle, Zustand ausführlich. Den Namen berechnet der Browser nach festen Regeln. Mit ANDI oder dem Accessibility Panel in den DevTools lässt sich prüfen, was am Ende ankommt.
Der wichtigste Punkt: Der Screenreader sieht nicht die Seite, er hört den Baum. Steht im DOM ein Element ohne Rolle, gibt es für ihn keinen Button. Ist ein Menü nur optisch aufgeklappt, ohne dass sich ein Zustand im DOM ändert, bleibt es für ihn zu. Mehr zur Sprachausgabe steht unter Text to Speech.

Semantisches HTML: Das DOM richtig füttern

Die meisten Barrieren im DOM entstehen durch das falsche Element. Ein div mit Klick Handler sieht aus wie ein Button, verhält sich aber nicht so. Es hat keine Rolle, ist nicht per Tab erreichbar und reagiert nicht auf Enter oder Leertaste. Ein natives button Element bringt all das kostenlos mit.
Code: 
          
<!-- Nicht barrierefrei: keine Rolle, kein Fokus, keine Tastatur -->
<div class="btn" onclick="save()">Speichern</div>

<!-- Barrierefrei: Rolle, Fokus und Tastatur kommen vom Browser -->
<button type="button" onclick="save()">Speichern</button>
Dasselbe gilt für den Rest der Seite. Überschriften mit h1 bis h6 statt fetter Absätze, Listen mit ul und li, Formularfelder mit label, Seitenbereiche mit header, nav, main und footer. Jedes dieser Elemente landet mit der richtigen Rolle im Accessibility Tree. Screenreader Nutzer springen damit gezielt durch die Seite, statt sie Zeile für Zeile anzuhören.
ARIA ergänzt das DOM dort, wo HTML nicht reicht, etwa bei Tabs, Comboboxen oder aufklappbaren Menüs. ARIA ändert aber nur, was im Accessibility Tree steht. Verhalten wie Fokus und Tastatursteuerung muss JavaScript liefern. Deshalb gilt: erst natives HTML, dann ARIA. Die Grundlagen stehen im Eintrag Semantic HTML.

Dynamische DOM Änderungen: Live Regions und Fokus

Moderne Webseiten ändern ihr DOM ständig. Ein Artikel landet im Warenkorb, ein Filter lädt neue Ergebnisse, eine Fehlermeldung erscheint. Sehende Nutzer bemerken das sofort. Ein Screenreader bleibt stumm, solange ihm niemand Bescheid gibt. Genau dafür gibt es Live Regions und das WCAG Kriterium 4.1.3 Statusmeldungen.
Code: 
          
<!-- Die Region steht schon beim Laden im DOM, zunächst leer -->
<div id="cart-status" role="status"></div>

<script>
  const status = document.getElementById('cart-status');

  function addToCart(count) {
    status.textContent = `${count} Artikel im Warenkorb`;
  }
</script>
Zwei Regeln machen den Unterschied. Erstens muss die Live Region bereits im DOM stehen, bevor sich ihr Inhalt ändert. Wird sie zusammen mit dem Text eingefügt, melden viele Screenreader nichts. Zweitens gilt: role status oder aria-live polite für normale Hinweise, role alert nur für dringende Fehler, weil alert den Nutzer unterbricht.
Das zweite Werkzeug ist Fokusmanagement. Öffnet sich ein Dialog, muss der Fokus hinein. Schließt er sich, muss der Fokus zurück zum Auslöser. Das native dialog Element nimmt mit showModal() viel Arbeit ab: Es setzt den Fokus in den Dialog und macht den Rest der Seite inert.
Code: 
          
const dialog = document.querySelector('#settings-dialog');
const opener = document.querySelector('#open-settings');

opener.addEventListener('click', () => dialog.showModal());

// Fokus zur Sicherheit explizit zurück zum Auslöser
dialog.addEventListener('close', () => opener.focus());
Bei Single Page Anwendungen kommt ein dritter Fall dazu: der Seitenwechsel ohne Neuladen. Das DOM tauscht den Inhalt, der Browser meldet aber keine neue Seite. Hier setzt ihr den Fokus auf die neue h1 oder kündigt den Seitentitel über eine Live Region an. Mehr zur Bedienung ohne Maus steht unter Keyboard Navigation.

DOM Reihenfolge, Lesereihenfolge und Tastatur

Screenreader lesen in DOM Reihenfolge vor. Die Tab Taste springt in DOM Reihenfolge durch Links und Buttons. Was per CSS optisch verschoben wird, bleibt im DOM an seiner alten Stelle. Genau hier entstehen Barrieren, die im Design niemand sieht.
Typische Auslöser:
  • CSS order und flex-direction: row-reverse: Die Optik zeigt A, B, C, das DOM liefert C, B, A.
  • Grid mit expliziter Platzierung: Kacheln wandern optisch nach oben, im DOM stehen sie am Ende.
  • Absolute Positionierung: Ein Button erscheint oben rechts, steht im DOM aber hinter dem Footer.
  • Positiver tabindex: Werte über 0 zerstören die natürliche Fokus Reihenfolge fast immer.
Die Regel ist einfach: Die DOM Reihenfolge muss der Lesereihenfolge entsprechen. CSS darf das Layout gestalten, aber nicht die Bedeutung umsortieren. Die WCAG Kriterien 1.3.2 Bedeutungstragende Reihenfolge und 2.4.3 Fokus Reihenfolge prüfen genau das. Details dazu stehen in Lesereihenfolge und Barrierefreiheit, Logische Reihenfolge und CSS und Barrierefreiheit.
Der schnellste Test braucht kein Tool: Maus weglegen, mit Tab durch die Seite gehen und beobachten, ob der Fokus der Leserichtung folgt. Springt er quer über die Seite, stimmt das DOM nicht.

Typische DOM Fehler und ihre Wirkung auf Screenreader

DOM Fehler Wirkung im Accessibility Tree Lösung
div mit Klick Handler als Button Keine Rolle, kein Fokus, Screenreader liest nur den Text Natives button Element nutzen
Inhalt per JavaScript nachgeladen ohne Live Region Änderung wird nicht angesagt, Nutzer bemerken nichts role status oder aria-live polite, Region vorab im DOM
CSS order oder absolute Positionierung Vorlesen und Tab Reihenfolge folgen dem DOM, nicht der Optik DOM Reihenfolge an die Lesereihenfolge anpassen
Modal ohne Fokusmanagement Fokus bleibt hinter dem Dialog, Inhalt dahinter bleibt erreichbar dialog Element mit showModal(), Fokus beim Schließen zurücksetzen
aria-hidden auf fokussierbarem Element Element bekommt Fokus, ist für Screenreader aber leer inert nutzen oder Element aus der Tab Reihenfolge nehmen

DOM Barrierefreiheit testen mit DevTools, axe-core und Cypress

Den Accessibility Tree zeigt jeder moderne Browser. In Chrome gibt es in den DevTools im Elements Panel eine Ansicht für den gesamten Accessibility Tree. Firefox bringt den Accessibility Inspector mit, der Rolle, Name und Zustand für jedes Element anzeigt und Probleme direkt markiert. Das ist der erste Blick, bevor ein Screenreader ins Spiel kommt.
Für die Pipeline nutzen wir axe-core in Cypress. axe prüft das gerenderte DOM, also genau das, was auch der Browser an den Accessibility Tree weitergibt. Dazu kommen gezielte Tests für dynamisches Verhalten, das kein Scanner allein erkennt:
Code: 
          
describe('DOM und Barrierefreiheit', () => {
  it('hat keine axe Verstöße nach WCAG AA', () => {
    cy.visit('/');
    cy.injectAxe();
    cy.checkA11y(null, {
      runOnly: { type: 'tag', values: ['wcag2a', 'wcag2aa', 'wcag22aa'] },
    });
  });

  it('meldet den Warenkorb über eine Live Region', () => {
    cy.visit('/produkt');
    cy.get('[data-cy=add-to-cart]').click();
    cy.get('[role=status]').should('contain.text', 'im Warenkorb');
  });

  it('setzt den Fokus in den Dialog', () => {
    cy.get('#open-settings').click();
    cy.focused().closest('dialog').should('exist');
  });
});
Der erste Test findet fehlende Namen, falsche Rollen und ungültige ARIA Attribute. Der zweite prüft, ob eine DOM Änderung angesagt wird. Der dritte prüft das Fokusmanagement. Alle drei laufen bei uns in jeder Pipeline mit GitHub Actions oder GitLab CI.
Grenzen gibt es trotzdem. Ob die DOM Reihenfolge Sinn ergibt oder ob ein Name verständlich ist, erkennt kein Tool zuverlässig. Dafür bleibt der manuelle Test mit Tastatur und Screenreader Pflicht. Den Überblick geben Accessibility Testing Tools 2026 und Accessibility Testing.

Frameworks, Shadow DOM und Web Components

Kaum jemand schreibt DOM heute noch von Hand. React und Vue erzeugen es über ein virtuelles DOM, Astro rendert HTML auf dem Server und lädt JavaScript nur dort, wo eine Komponente interaktiv sein muss. Für die Barrierefreiheit zählt am Ende nur eins: das DOM, das im Browser ankommt. Deshalb prüfen wir Komponenten nie im Quellcode, sondern immer gerendert.
Drei Stellen, an denen Frameworks gerne Barrieren erzeugen:
  • Fragment und Wrapper: Ein zusätzliches div zwischen ul und li bricht die Listenstruktur. Fragments in React und Vue verhindern das.
  • IDs in wiederverwendeten Komponenten: Doppelte IDs lassen label for und aria-describedby ins Leere laufen. Generierte IDs, etwa mit useId in React, lösen das.
  • Client Rendering ohne Fallback: Solange JavaScript lädt, ist das DOM leer oder unvollständig. Serverseitiges Rendering, wie Astro es standardmäßig macht, liefert sofort einen vollständigen Baum.
Beim Shadow DOM von Web Components wird es knifflig. Der Accessibility Tree sieht durch die Shadow Grenze hindurch, ID Referenzen tun das aber nicht. Ein aria-labelledby im Light DOM findet keine ID im Shadow DOM und umgekehrt. Wer Web Components baut, plant Label und Beschreibung deshalb innerhalb derselben Grenze. Wie sich das auf robuste Umsetzung auswirkt, zeigt der Eintrag Robustheit. Zum Thema entkoppelter Frontends passt außerdem Headless.
Übrigens: Das WCAG Kriterium 4.1.1 Syntaxanalyse ist in WCAG 2.2 als veraltet gestrichen. Browser reparieren fehlerhaftes Markup inzwischen einheitlich. Was bleibt, ist 4.1.2 Name, Rolle, Wert, und das prüft genau den Weg vom DOM in den Accessibility Tree.

Think 'what does this expose to the accessibility tree?'

Hidde de Vries, Web Accessibility Spezialist und Blogger – via hidde.blog, The accessibility tree

DOM und Barrierefreiheit in NCA Projekten

Bei uns beginnt Barrierefreiheit in der Komponente. Jede Komponente in Astro, React oder Vue bekommt einen Cypress Test, der das gerenderte DOM mit axe-core prüft. Buttons sind Buttons, Links sind Links, Dialoge nutzen das native dialog Element. Das klingt banal, verhindert aber den Großteil der Fehler, die sonst erst im Accessibility Audit auffallen.
Bei bestehenden Projekten schauen wir zuerst in den Accessibility Tree der wichtigsten Seiten. Fehlende Namen und falsche Rollen sind schnell gefunden und gut zu priorisieren. Aufwendiger sind DOM Reihenfolge und dynamische Änderungen, weil sie oft tief in Layout und JavaScript stecken. Dazu prüfen wir, wie die Seite die vier Grundprinzipien POUR erfüllt, und arbeiten die Punkte nach Wirkung ab.
Wir helfen Teams, sauberes DOM zur Gewohnheit zu machen: mit Komponenten, die korrekte Semantik mitbringen, mit Tests in der Pipeline und mit einem gemeinsamen Blick auf den Accessibility Tree im Review. Ziel ist eine Seite, die die Anforderungen aus BFSG und European Accessibility Act dauerhaft erfüllt. Wie das im gesamten Entwicklungsprozess aussieht, beschreibt Entwicklung barrierefreier digitaler Inhalte. Alle Begriffe findet ihr im NCA Glossar für Barrierefreiheit.
CYPRESS.IO Ambassador und IT Consultant für QA Engenieering und Qualität in PHP Projekten.
Erreichen Sie unsere Spezialisten zu barrierefreien Webdesign

Wir sind hier, um Ihnen zu helfen. Gemeinsam meistern wir Ihre digitalen Herausforderungen und fördern die Inklusion im Internet. Lassen Sie uns Ihre Projekte mit barrierefreiem Webdesign erfolgreich machen.

Kostenlose Demo Jetzt anrufen

Häufige Fragen zum DOM und zur Barrierefreiheit

Die wichtigsten Fragen zu Document Object Model, Accessibility Tree und Screenreadern kurz beantwortet.
Was ist das DOM 2026 einfach erklärt?

Das Document Object Model ist die Baumstruktur, in die der Browser eine HTML Seite übersetzt. Jedes Element, jedes Attribut und jeder Text wird darin zu einem Knoten. JavaScript liest und ändert diese Knoten, Frameworks wie React, Vue oder Astro erzeugen sie. Gepflegt wird das DOM als Living Standard von der WHATWG.

Warum ist das DOM 2026 wichtig für die Barrierefreiheit?

Aus dem DOM baut der Browser den Accessibility Tree. Genau diesen Baum lesen Screenreader, Sprachsteuerung und andere assistive Technologien aus. Fehlt im DOM eine Rolle, ein Name oder ein Zustand, fehlt diese Information auch für den Nutzer. Die WCAG 2.2 Kriterien, die über das BFSG verbindlich sind, prüfen deshalb vor allem das DOM.

Was ist der Unterschied zwischen DOM und Accessibility Tree 2026?

Das DOM enthält alle Knoten einer Seite. Der Accessibility Tree ist eine gefilterte Sicht darauf mit Rolle, Name, Zustand und Beziehungen jedes bedeutungstragenden Elements. Dekorative Elemente fehlen dort. Der Browser erzeugt den Accessibility Tree automatisch aus dem DOM, ARIA Attribute können ihn ergänzen oder überschreiben.

Welche WCAG 2.2 Kriterien betreffen 2026 das DOM?

Vor allem 1.3.1 Info und Beziehungen, 1.3.2 Bedeutungstragende Reihenfolge, 2.4.3 Fokus Reihenfolge, 4.1.2 Name, Rolle, Wert und 4.1.3 Statusmeldungen. Sie verlangen semantisches Markup, eine sinnvolle Reihenfolge, korrekte Namen und Rollen sowie angesagte Änderungen. Das frühere Kriterium 4.1.1 Syntaxanalyse ist in WCAG 2.2 gestrichen.

Wie teste ich das DOM 2026 auf Barrierefreiheit?

Erst im Browser: Accessibility Tree in den Chrome DevTools oder im Firefox Accessibility Inspector ansehen. Dann automatisiert mit axe-core, etwa über cypress-axe in der CI Pipeline. Dynamisches Verhalten wie Live Regions und Fokus deckt ihr mit eigenen Cypress Tests ab. Zum Schluss folgt der manuelle Test mit Tastatur und Screenreader.

Was ist eine ARIA Live Region?

Eine Live Region ist ein Bereich im DOM, dessen Änderungen Screenreader automatisch ansagen. Ihr markiert ihn mit role status, aria-live polite oder für dringende Meldungen mit role alert. Wichtig ist, dass die Region schon beim Laden im DOM steht und erst danach Inhalt bekommt. Sonst melden viele Screenreader nichts.

Warum sollte ich button statt div verwenden?

Ein natives button Element bringt Rolle, Fokus und Tastatursteuerung automatisch mit. Ein div mit Klick Handler hat nichts davon: Es erscheint im Accessibility Tree nicht als Button, ist per Tab nicht erreichbar und reagiert nicht auf Enter oder Leertaste. Das alles nachzubauen kostet Zeit und ist fehleranfällig.

Verändert CSS die Reihenfolge im DOM?

Nein. CSS verschiebt Elemente nur optisch, etwa mit order, row-reverse, Grid Platzierung oder absoluter Positionierung. Screenreader und die Tab Taste folgen weiter der DOM Reihenfolge. Weicht die Optik davon ab, springt der Fokus quer über die Seite. Deshalb gehört die Lesereihenfolge ins DOM und nicht ins Stylesheet.

Ist das virtuelle DOM von React oder Vue ein Problem für Barrierefreiheit?

Nicht grundsätzlich. Das virtuelle DOM ist nur ein Zwischenschritt, am Ende entsteht echtes DOM im Browser. Probleme entstehen durch die Komponenten selbst, etwa durch überflüssige Wrapper, doppelte IDs oder fehlendes Fokusmanagement bei Seitenwechseln. Deshalb prüft ihr immer das gerenderte Ergebnis und nicht den Quellcode.

Wie funktioniert Barrierefreiheit im Shadow DOM?

Der Accessibility Tree schaut durch die Shadow Grenze hindurch, Rollen und Namen innerhalb einer Web Component werden also erkannt. ID Referenzen wie aria-labelledby oder label for funktionieren aber nicht über die Grenze hinweg. Label, Beschreibung und Feld sollten deshalb innerhalb derselben Shadow Root liegen.

Was bewirkt aria-hidden im DOM?

aria-hidden true entfernt ein Element samt Kindern aus dem Accessibility Tree. Im DOM und auf dem Bildschirm bleibt es erhalten. Das ist sinnvoll für dekorative Icons. Gefährlich wird es bei fokussierbaren Elementen: Sie bekommen weiter den Fokus, sind für Screenreader aber leer. Für ganze Bereiche ist das inert Attribut die bessere Wahl.

Reicht ein automatisierter Test für ein barrierefreies DOM?

Nein. Automatisierte Tools finden fehlende Namen, falsche Rollen und ungültige ARIA Attribute zuverlässig. Ob die Reihenfolge Sinn ergibt, ob ein Name verständlich ist oder ob eine Änderung zur richtigen Zeit angesagt wird, erkennen sie nicht. Dafür braucht es den manuellen Test mit Tastatur und Screenreader zusätzlich zur Pipeline.