In den Chrome-Entwicklertools wird ein vollständiger Navigationsbaum für die Barrierefreiheit eingeführt, der Entwicklern einen besseren Überblick über den gesamten Baum bietet. In diesem Beitrag erfahren Sie, wie dieser Baum erstellt wird und wie Sie ihn in Ihrer Arbeit verwenden können.
Was ist der Navigationsbaum für Barrierefreiheit?
Hilfstechnologien wie Screenreader verwenden die Bedienungshilfen-API von Chromium, um mit Webinhalten zu interagieren. Das zugrunde liegende Modell dieser API ist der Bedienungshilfen-Baum: Ein Baum von Bedienungshilfenobjekten, bei denen Hilfstechnologien nach Attributen und Eigenschaften fragen und Aktionen ausführen können. Webentwickler gestalten und bearbeiten den Baum für Barrierefreiheit hauptsächlich über DOM-Eigenschaften wie ARIA-Attribute für HTML.
In den Chrome-Entwicklertools finden Entwickler den Bereich „Bedienungshilfen“, in dem sie sehen können, wie ihre Inhalte von Hilfstechnologien angezeigt werden. Wenn in der DOM-Baumanzeige ein Knoten ausgewählt wird, werden die Eigenschaften des entsprechenden Bedienungshilfenknotens im Bereich zusammen mit einer Ansicht der übergeordneten Knoten und der unmittelbaren untergeordneten Knoten angezeigt.
Wie wird der Baum erstellt?
Bevor wir uns damit befassen, wie diese neue vollständige Baumansicht in den DevTools aussieht, sehen wir uns kurz an, was der Baum für Barrierefreiheit genau ist. Der Baum für Barrierefreiheit ist eine Ableitung des DOM-Baums. Die Struktur ist ungefähr gleich, aber vereinfacht, um Knoten ohne semantischen Inhalt zu entfernen, z. B. ein <div>-Element, das nur zum Stilisieren verwendet wird. Jeder Knoten im Baum hat eine Rolle wie Button oder Heading und oft einen Namen, der entweder aus ARIA-Attributen oder aus dem Inhalt des Knotens abgeleitet werden kann. Sehen wir uns ein HTML-Dokument an:
<html>
<head>
<title>How old are you?</title>
</head>
<body>
<label for="age">Age</label>
<input id="age" type="number" name="age" value="42">
<div>
<button>Back</button>
<button>Next</button>
</div>
</body>
</html>
Der Renderer in Chromium, Blink genannt, leitet einen internen Bedienungshilfen-Baum ungefähr so ab:
role='rootWebArea' focusable name='How old are you?'
role='genericContainer' ignored
role='genericContainer' ignored
role='labelText'
role='staticText' name='Age'
role='spinButton' editable focusable name='Age' value='42'
role='genericContainer' editable
role='staticText' editable name='42'
role='genericContainer'
role='button' focusable name='Back'
role='staticText' name='Back'
role='button' focusable name='Next'
role='staticText' name='Next'
Diese Darstellung enthält mehrere überflüssige Knoten mit der Rolle genericContainer, was der obigen Aussage widerspricht, dass der Baum für Barrierefreiheit eine vereinfachte Ableitung des DOM-Baums ist. Die meisten dieser Knoten kommen jedoch nur im internen Baum vor und werden nicht von Hilfstechnologien angezeigt. Da die Entwicklertools ihre Informationen zur Barrierefreiheit direkt aus dem Rendering-Prozess erfassen, wird diese Baumdarstellung von den Entwicklertools verwendet.
Vollständige Baumansicht für Barrierefreiheit in den Entwicklertools
Der neue, vollständige Baum für Barrierefreiheit wird mit dem DOM-Baum synchronisiert, damit Entwickler zwischen den beiden Bäumen wechseln können. Wir hoffen, dass der neue Stammbaum aussagekräftiger, nützlicher und nutzerfreundlicher ist.
Nachdem Sie nun wissen, wie der Navigationsbaum für Barrierefreiheit funktioniert, können Sie mit den Entwicklertools sehen, wie die neue Baumansicht aussieht. Das folgende HTML-Dokument mit einem Titel, einer Überschrift und zwei Schaltflächen wird verwendet, um den Baum anzuzeigen.
<!DOCTYPE html>
<title>Test</title>
<h1>Heading for example page</h1>
<div>
<button>Back</button>
<button>Next</button>
</div>
In der vorherigen Strukturansicht konnten Sie nur einen einzelnen Knoten und seine übergeordneten Elemente untersuchen.
Wenn Sie jetzt die neue Struktur einblenden, wird die DOM-Baumansicht ersetzt und Sie sehen den vollständigen Baum für die Barrierefreiheit der Seite:
Lazy Tree-Bau
Damit der Baum auch bei größeren Websites leistungsfähig ist, wird er im Frontend bei der Navigation träge erstellt. Sobald ein Knoten im Baum maximiert wurde, werden die untergeordneten Elemente der Knoten über das Chrome DevTools Protocol (CDP) abgerufen und der Baum neu erstellt.
Live
Die neue Baumansicht ist live und wird dynamisch aktualisiert, wenn sich der Baum für die Barrierefreiheit im Renderer ändert. Es nutzt dieselben Mechanismen, die Hilfstechnologien über Änderungen am Baum informieren würden, und sendet damit Ereignisse mit aktualisierten Knoten an die DevTools-Frontend. In der Praxis überwacht das CDP-Backend Aktualisierungen des Baums, protokolliert, welche Knoten bereits angefordert wurden, und sendet Ereignisse an das DevTools-Frontend, wenn sich einer dieser Knoten ändert.
Die Geschichte vieler Bäume
In der Beschreibung des Barrierefreiheitsbaums haben Sie erfahren, wie Blink einen Barrierefreiheitsbaum für das gerenderte DOM erstellt und DevTools diesen Baum über CDP abruft. Das ist zwar richtig, aber wir haben einige Komplikationen in dieser Beschreibung weggelassen. Tatsächlich gibt es zahlreiche Möglichkeiten, den Bedienungshilfen-Baum in Chromium zu verwenden. Beim Entwerfen der neuen Strukturansicht für die DevTools haben wir einige Entscheidungen darüber getroffen, welche Teile der internen Barrierefreiheitsfunktionen von Chromium angezeigt werden sollten.
Plattformen
Jede Plattform hat eine andere API für Barrierefreiheit. Die Struktur des Baums ist zwar auf allen Plattformen gleich, aber die API für die Interaktion mit dem Baum ist unterschiedlich und die Namen der Attribute können sich unterscheiden. In den DevTools wird der interne Chromium-Baum angezeigt, in dem Rollen und Attribute in der Regel mit denen übereinstimmen, die in der ARIA-Spezifikation definiert sind.
Mehrere Frames und Website-Isolierung
Da Chromium nicht nur den Inhalt jedes Tabs in verschiedene Renderer-Prozesse verschiebt, sondern auch websiteübergreifende Dokumente in verschiedenen Renderer-Prozessen isoliert, müssen wir uns über CDP separat mit jedem untergeordneten Dokument außerhalb des Prozesses verbinden und seinen Baum für Barrierefreiheit abrufen. Diese untergeordneten Bäume werden dann im Frontend zusammengefügt, um den Anschein eines zusammenhängenden Baums zu erwecken, obwohl sie sich in verschiedenen Renderer-Prozessen in Chromium befinden.
Ignorierte und uninteressante Knoten
Einige Knoten werden standardmäßig ausgeblendet: ignorierte Knoten und Knoten mit der Rolle „generisch“ ohne Namen. Diese Knoten haben keine semantische Bedeutung und werden bei ignorierten Knoten nicht für Hilfstechnologien verwendet. Wir blenden diese Knoten aus, um die Strukturübersicht nicht zu überladen. Andernfalls würde der Baum für die Barrierefreiheit der meisten Webseiten in etwa so aussehen:
Der Nachteil dabei ist, dass wir im Grunde einen weiteren Baum erstellen müssen, der sich von dem im Backend unterscheidet. Angenommen, wir haben die Knoten A, B, C und X, wobei A die untergeordneten Knoten X und B hat und X den untergeordneten Knoten C. Wenn X ein ignorierter Knoten ist, entfernen wir ihn aus dem Baum und erstellen stattdessen einen Baum, in dem C ein untergeordnetes Element von A ist.
Im Frontend erstellen wir den vollständigen Baum einschließlich ignorierter Knoten und entfernen diese erst kurz vor dem Rendern der Knoten. Das hat zwei Gründe:
- Das erleichtert die Verwaltung von Knotenaktualisierungen aus dem Backend erheblich, da wir an beiden Endpunkten dieselbe Baumstruktur haben. Wenn beispielsweise Knoten B im Beispiel entfernt wird, erhalten wir eine Aktualisierung für Knoten X, da sich seine untergeordneten Elemente geändert haben. Wenn wir diesen Knoten jedoch entfernt hätten, wäre es schwierig zu ermitteln, was aktualisiert werden muss.
- Sie sorgt dafür, dass alle DOM-Knoten einen entsprechenden Knoten für die Barrierefreiheit haben. Wenn der Baum eingeblendet ist, wählen wir den Knoten aus, der dem Knoten entspricht, der derzeit im DOM-Baum ausgewählt ist. Wenn der Nutzer also im vorherigen Beispiel den Baum ein- und ausblendet, während der DOM-Knoten, der X entspricht, ausgewählt ist, wird X zwischen den Knoten A und B eingefügt und im Baum ausgewählt. So kann der Nutzer den Knoten „Zugänglichkeit“ für alle DOM-Knoten prüfen und herausfinden, warum der Knoten ignoriert wird.
Ideen für die Zukunft
Die Einführung des neuen Baums für Barrierefreiheit ist erst der Anfang. Wir haben bereits einige Ideen für zukünftige Projekte, die wir auf der neuen Ansicht aufbauen könnten. Wir freuen uns aber auch auf dein Feedback.
Alternative Filter
Wie oben erläutert, filtern wir derzeit Knoten heraus, die als uninteressant eingestuft werden. Wir könnten eine Möglichkeit anbieten, dieses Verhalten zu deaktivieren und alle Knoten anzuzeigen, oder alternative Filter wie Markierungsknoten anzeigen oder Überschriften anzeigen.
Probleme mit Bedienungshilfen hervorheben
Wir könnten eine Analyse der „Best Practices für Barrierefreiheit“ in den Baum einbinden und Probleme mit der Barrierefreiheit direkt an den betreffenden Knoten hervorheben.
Aktionen für Bedienungshilfen in den DevTools anzeigen
Der derzeit angezeigte Baum ist rein einseitig: Er gibt uns einen Eindruck davon, welche Informationen bei der Navigation auf einer bestimmten Webseite an Hilfstechnologien gesendet würden. Bedienungshilfen-Aktionen stellen die Kommunikation in die andere Richtung dar: Sie ermöglichen es Hilfstechnologien, auf die angezeigte Benutzeroberfläche zuzugreifen. Wir könnten solche Aktionen in den DevTools anzeigen lassen, um Aktionen wie „Klicken“, Scrollen oder Ändern von Werten auf der Seite über die API zu ermöglichen, die für Hilfstechnologien verfügbar ist.