Shadow DOM – die Kapselung von HTML Elementen und die Barrierefreiheit

Trends gibt es nicht nur beim visuellen Design – auch Entwickler folgen gerne der aktuelle Mode beim Programmieren. Doch nicht jeder Trend bringt wirklich etwas Neues oder macht die Dinge besser.
Alan Kay und Adele Goldberg definierten schon Ende der 1960er Jahre die Kapselung (englisch Encapsulation) der Programmlogik, das ‚information hiding‚, als zentrales Konzept für objektorientierte Programmiersprachen. Ungefähr 2010 tauchte das Konzept der Kapselung bei HTML-Elementen auf und wurde mit dem Namen ‚Web Components‚ beschrieben. Mit diesen Web Komponenten eng verknüpft ist das Konzept des Shadow DOM öffnet sich in einem neuen Tab.

Das DOM (Document Object Model) ist das Ergebnis der Interpretation eines HTML Dokuments und repräsentiert dieses Dokument als hierarchischen Baum aus einzelnen Knoten (Nodes). Jeder Knoten repräsentiert ein Element, Attribut, Text oder andere Bestandteile des Dokuments. Der Elemente des DOM werden vom World Wide Web Consortium (W3C) standardisiert. Dieses DOM ist nun die Grundlage für die Interaktion mit Webseiten in Sprachen wie JavaScript und es ist die Basis für eine barrierefreie digitale Benutzerschnittstelle. Der sogenannte Accessibility Tree ist eine speziell aufbereitete, vereinfachte und semantisch angereicherte Version des DOM. Dieser Accessibility Tree wird von assistiven Technologien wie Screenreadern genutzt. Aber zurück in das Reich der Schatten.

Normalerweise liefert mir Javascript mit ‚document.querySelectorAll(„*“)‘ alle Elemente im DOM. Beim Shadow DOM läuft das allerdings anders – die Elemente darin sind nämlich gekapselt und lassen sich folglich nicht ohne Weiteres erreichen. Ich erhalte zum Beispiel ein Formular, aber keine Informationen über den Aufbau des Formulars.
Wenn wir nochmal ‚document.querySelectorAll(„*“)‘ betrachten: der Befehl schnappt sich einfach alle Elemente im DOM (das „Schnappen“ nennt sich „Tiefensuche“) und das in der Reihenfolge, in der eine Nutzerin oder ein Nutzer mit dem TAB-Key durch die Seite laufen würden. Das Shadow DOM sprengt dieses Verhalten. Ein Knoten im DOM kann echte Kinder (untergeordnete Knoten) und Kinder im Shadow DOM haben. Letztere sitzen in der Regel nicht an der gleichen Stelle im DOM, den die „echten“ Kinder einnehmen würden.
Ein Objekt aus dem Shadow DOM wird praktisch nachträglich an das existieren DOM angehängt (my-dom-element.attachShadow({ mode: „closed“ })). Es wird eine fertige Web-Komponente erstellt und dieses fertige Modul wird dann in die Seite kopiert. Ich will es hier nicht noch technischer werden lassen und verzichte auf längere Code-Beispiele. Wichtig ist, dass der Browser und damit die assistiven Technologien, von dieser nachträglichen Änderung am DOM nicht unbedingt etwas mitbekommen.

Mit dem Shadow DOM kann ich also meine Module von dem DOM abkapseln. So bleibt für die Entwickler alles schön übersichtlich und getrennt. Ich kann das Formular nutzen, ohne mich für den Aufbau zu interessieren. Für die Barrierefreiheit wird es in der Folge aber häufig weniger schön. ARIA (Accessible Rich Internet Applications öffnet sich in einem neuen Tab) Rollen und Attribute sind ein grundlegendes Hilfsmittel für die Barrierefreiheit einer Website. ARIA stellt uns Attribute wie „aria-labelledby“ oder „aria-describedby“ zur Verfügung. Mit diesen Attributen lassen sich andere Elemente per ID referenzieren – superpraktisch für so manche barrierefreie Lösung. Nur sind die IDs der Elemente aus dem Shadow DOM leider nicht ohne Probleme erreichbar. Versteckt ist halt versteckt. Es ist auch völlig regelgerecht, wenn zwei Elemente im Shadow DOM identische IDs benutzen – was leider wieder die Nutzung in ARIA Attributen verhindert.

Jetzt könnte man statt „aria-labelledby“ einfach „aria-label“ nutzen. Problem gelöst. Nur: verliert man mit dieser Strategie mehr als die Hälfte alle ARIA-Attribute und bestehender Code muss entsprechend verändert werden. Dazu kommt, dass viele der existierenden Javascript Bibliotheken nicht für die Nutzung eines Shadow DOMs ausgelegt sind. Die scheitern dann genau auf die gleiche Weise.
Eine sehr unschöne und schon vor der Nutzung des Shadow DOMs ausgesprochen beliebte Strategie ist, dass man auf native HTML Elemente wie <input /> verzichtet und gleich generische Elemente wie ein <div> mühsam aufpeppt. Es gibt Bestrebungen, diese Probleme in neuen Browser-Varianten zu lösen (ARIA-Mixins, cross-root ARIA und andere), aber aktuell funktioniert davon nichts wirklich.

Praktisch führt die Nutzung des Shadow DOMs, insbesondere bei komplexeren Websites von größeren Unternehmen, gerade zu erheblichen Problemen bei einer barrierefreien Umsetzung. Dinge, die schon ganz selbstverständlich funktioniert haben, stellen uns nun vor erhebliche Probleme. Parallel melden viele der automatisierten Test-Werkzeuge (ARC Toolkit, AXE und andere) hier viele Fehler. Dabei sind einige Fehler, die sich in der praktischen Nutzung, zum Beispiel mit einem Screenreader, nicht bemerkbar machen. Diese Werkzeuge erkennen einfach die finale Struktur der Seite nicht. Im Hinblick auf die Gefahr von Abmahnungen stellt dies ein nicht zu unterschätzendes Problem dar.

Nicht jedem Trend zu folgen, ist wohl eine zu pauschale Empfehlung. Die Nutzung des Shadow DOMs hat unbestreitbar Vorteile – so man dabei die Barrierefreiheit im Blick behält. Im ersten Moment bringt sie aber viele neue Probleme mit und kann die Barrierefreiheit in Windeseile massiv verschlechtern.