In den Chrome-Entwicklertools wird eine vollständige Barrierefreiheitsstruktur eingeführt, die es Entwicklern erleichtert, sich einen Überblick über den gesamten Baum zu verschaffen. In diesem Beitrag erfahren Sie, wie dieser Baum erstellt wird und wie Sie ihn für Ihre Arbeit nutzen können.
Was ist der Baum für Barrierefreiheit?
Hilfstechnologien wie Screenreader verwenden die Accessibility API von Chromium, um mit Webinhalten zu interagieren. Das zugrunde liegende Modell dieser API ist die Baumstruktur für Bedienungshilfen, die von Hilfstechnologien nach Attributen und Eigenschaften abfragen und Aktionen ausführen kann. Webentwickler gestalten und bearbeiten den Baum für Barrierefreiheit in erster Linie über DOM-Eigenschaften wie ARIA-Attribute für HTML.
In den Chrome-Entwicklertools stellen wir den Bereich „Bedienungshilfen“ zur Verfügung, über den Entwickler nachvollziehen können, wie ihre Inhalte Hilfstechnologien ausgesetzt werden. Wenn ein Knoten in der DOM-Baumansicht ausgewählt wird, werden im Fenster die Eigenschaften des entsprechenden Bedienungshilfenknotens zusammen mit einer Ansicht der Ancestors und der unmittelbaren untergeordneten Elemente des Knotens angezeigt.
Wie wird der Baum erstellt?
Bevor wir dazu kommen, wie diese neue vollständige Baumansicht in den Entwicklertools aussieht, wollen wir kurz darauf eingehen, was der Baum für Barrierefreiheit ist. Der Baum für Barrierefreiheit ist eine Ableitung des DOM-Baums. Die Struktur ist ungefähr gleich, wurde aber vereinfacht, um Knoten ohne semantischen Inhalt zu entfernen, z. B. ein <div>-Element, das nur für die Gestaltung verwendet wird. Jeder Knoten in der Baumstruktur hat eine Rolle wie Button oder Heading und häufig einen Namen, der entweder aus ARIA-Attributen stammen oder aus dem Inhalt des Knotens abgeleitet werden kann. Wenn wir uns ein HTML-Dokument ansehen:
<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 mit dem Namen Blink leitet einen internen Bedienungshilfenbaum in etwa 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'
Beachten Sie, dass diese Darstellung mehrere überflüssige Knoten mit der Rolle genericContainer enthält, was der obigen Aussage widerspricht, dass der Baum für Barrierefreiheit eine vereinfachte Ableitung des DOM-Baums ist. Dennoch befinden sich die meisten dieser Knoten nur in der internen Baumstruktur und sind nicht für Hilfstechnologien geeignet. Da die Entwicklertools die Informationen zur Barrierefreiheit direkt aus dem Renderer-Prozess erfassen, ist dies die Baumdarstellung, die in den Entwicklertools verarbeitet wird.
Vollständiger Baum für Barrierefreiheit in den Entwicklertools
Der neue, vollständige Baum für Barrierefreiheit wird mit dem DOM-Baum synchronisiert, sodass Entwickler zwischen den beiden Baumstrukturen hin- und herwechseln können. Wir hoffen, dass die neue Struktur einfacher zu ermitteln, nützlich und nutzerfreundlicher wird.
Jetzt, da Sie wissen, wie der Baum für Barrierefreiheit funktioniert, können Sie die Entwicklertools verwenden, um zu sehen, wie die neue Baumansicht aussieht. Das folgende HTML-Dokument mit einem Titel, einer Überschrift und zwei Schaltflächen wird zur Darstellung der Baumstruktur verwendet.
<!DOCTYPE html>
<title>Test</title>
<h1>Heading for example page</h1>
<div>
<button>Back</button>
<button>Next</button>
</div>
In der vorherigen Baumansicht konnten Sie nur einen einzelnen Knoten und dessen Vorgänger untersuchen.
Wenn Sie jetzt die neue Baumstruktur aktivieren, ersetzt diese die DOM-Baumansicht und Sie können die vollständige Baumstruktur für die Barrierefreiheit der Seite sehen:
Bau von Lazy Trees
Um die Leistung des Baums auch für größere Websites zu verbessern, wird der Baum bei der Erkundung des Frontends langsam konstruiert. Nachdem ein Knoten in der Baumstruktur erweitert wurde, werden die untergeordneten Knoten für die Knoten über das Chrome DevTools Protocol (CDP) abgerufen und die Baumstruktur wird neu erstellt.
Live
Die neue Baumansicht ist live und wird dynamisch aktualisiert, wenn sich die Baumstruktur im Renderer ändert. Es greift in dieselben Mechanismen ein, die assistive Technologien über Änderungen am Baum informieren, und verwendet diese, um Ereignisse mit aktualisierten Knoten an das Entwicklertools-Frontend auszugeben. In der Praxis wartet das CDP-Backend auf Aktualisierungen der Baumstruktur, verfolgt, welche Knoten zuvor angefordert wurden, und sendet Ereignisse an das Entwicklertools-Frontend, wenn sich einer dieser Knoten ändert.
Die Geschichte der vielen Bäume
In der Beschreibung der Baumstruktur für Barrierefreiheit haben Sie erfahren, wie Blink eine Baumstruktur für die Barrierefreiheit für das gerenderte DOM erstellt und die Entwicklertools über CDP abrufen. Auch wenn das stimmt, haben wir in der Beschreibung einige Komplikationen ausgelassen. Tatsächlich gibt es viele verschiedene Möglichkeiten, den Baum für Barrierefreiheit in Chromium zu nutzen. Beim Entwerfen der neuen Baumansicht für die Entwicklertools haben wir einige Entscheidungen darüber getroffen, welchen Teil der Chromium-internen Bedienungshilfen wir hervorheben möchten.
Plattformen
Jede Plattform hat eine andere Accessibility API und obwohl die Form des Baums auf allen Plattformen gleich ist, ist die API für die Interaktion mit dem Baum unterschiedlich und die Namen der Attribute können unterschiedlich sein. Die Entwicklertools zeigen die interne Struktur von Chromium, in der Rollen und Attribute tendenziell mit den in der ARIA-Spezifikation definierten Rollen und Attributen übereinstimmen.
Mehrere Frames und Website-Isolierung
Da Chromium nicht nur die Inhalte jedes Tabs in verschiedene Renderer-Prozesse speichert, sondern auch websiteübergreifende Dokumente in verschiedenen Renderer-Prozessen isoliert, müssen wir über CDP eine separate Verbindung zu jedem untergeordneten Dokument außerhalb der Verarbeitung herstellen und dessen Barrierefreiheitsstruktur abrufen. Diese Teilstrukturen werden dann im Front-End zusammengefügt, um den Anschein eines kohärenten Baumes zu erzeugen, obwohl sie in verschiedenen Renderer-Prozessen in Chromium vorhanden sind.
Ignorierte und uninteressante Knoten
Einige Knoten werden standardmäßig ausgeblendet: ignorierte Knoten und Knoten mit der Rolle „generic“ (generisch) ohne Namen. Diese Knoten haben keine semantische Bedeutung und sind im Fall von ignorierten Knoten keinen Hilfstechnologien ausgesetzt. Diese Knoten werden ausgeblendet, damit die Baumansicht nicht unübersichtlich wird. Andernfalls würde der Baum für die Barrierefreiheit für die meisten Webseiten in etwa so aussehen:
Der Vorbehalt hier ist, dass dies im Wesentlichen bedeutet, dass wir noch einen weiteren Baum als den erstellen müssen, der im Back-End verfügbar ist. Nehmen wir zum Beispiel an, wir haben die Knoten A, B, C und X, wobei A das untergeordnete X und B und X das untergeordnete Element C hat. Wenn X ein ignorierter Knoten ist, wird X aus der Baumstruktur entfernt und stattdessen eine Baumstruktur erstellt, in der C ein untergeordnetes Element von A ist.
Im Front-End wird die vollständige Baumstruktur einschließlich ignorierter Knoten erstellt und erst unmittelbar vor dem Rendern der Knoten bereinigt. Dafür gibt es zwei Gründe:
- Es vereinfacht die Verarbeitung von Knotenaktualisierungen aus dem Back-End, da wir auf beiden Endpunkten dieselbe Baumstruktur haben. Wenn beispielsweise der Knoten B in dem Beispiel entfernt wird, erhalten wir ein Update für Knoten X (da sich seine untergeordneten Elemente geändert haben). Wenn wir diesen Knoten jedoch bereinigt hätten, hätten wir Schwierigkeiten, herauszufinden, was aktualisiert werden soll.
- Damit wird sichergestellt, dass alle DOM-Knoten einen entsprechenden Knoten für Bedienungshilfen haben. Wenn die Baumstruktur umgeschaltet wird, wählen wir den Knoten aus, der dem aktuell in der DOM-Baumstruktur ausgewählten Knoten entspricht. Wenn der Nutzer im vorherigen Beispiel den Baum umschaltet, während der DOM-Knoten für X ausgewählt ist, fügen wir X zwischen die Knoten A und B ein und wählen X in der Baumstruktur aus. Dadurch kann der Nutzer den Barrierefreiheitsknoten für alle DOM-Knoten überprüfen und feststellen, warum der Knoten ignoriert wird.
Ideen für die Zukunft
Der neue Baum für Barrierefreiheit im Internet ist erst der Anfang. Wir haben ein paar Ideen für zukünftige Projekte, die wir auf der neuen Ansicht aufbauen könnten, und freuen uns auf Ihr Feedback.
Alternative Filter
Wie oben erläutert, filtern wir derzeit Knoten heraus, die als uninteressant angesehen werden. Wir könnten eine Möglichkeit anbieten, dieses Verhalten zu deaktivieren und alle Knoten anzuzeigen, oder aber alternative Filter wie Knoten für Sehenswürdigkeiten anzeigen oder Überschriften anzeigen bereitstellen.
A11y-Probleme hervorheben
Wir könnten eine Analyse der Best Practices für die Barrierefreiheit in den Baum integrieren und Probleme mit der Barrierefreiheit direkt auf den betroffenen Knoten hervorheben.
Aktionen für Bedienungshilfen in den Entwicklertools aufrufen
Die derzeit angezeigte Struktur ist rein einseitig: Sie gibt uns eine Vorstellung davon, welche Informationen beim Surfen auf einer bestimmten Webseite an Hilfstechnologien gefüttert werden. Aktionen für Bedienungshilfen stellen die Kommunikation in die andere Richtung dar: Sie ermöglichen es assistive Technologien, auf der dargestellten Benutzeroberfläche zu agieren. Wir könnten solche Aktionen in den Entwicklertools anzeigen, um Aktionen wie „Klicken“, „Scrollen“ oder das Ändern von Werten auf der Seite mithilfe der für Hilfstechnologien verfügbaren API zu ermöglichen.