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 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 in erster Linie ü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 Informationen zur Barrierefreiheit in den DevTools direkt aus dem Rendering-Prozess erfasst werden, ist dies die Baumdarstellung, die in den DevTools verwendet wird.
Vollständige Baumansicht für Barrierefreiheit in den Entwicklertools
Der neue, vollständige Baumansicht 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 explorativer, nützlicher und nutzerfreundlicher ist.
Nachdem Sie nun mit der Funktionsweise der Baumstruktur für Barrierefreiheit vertraut sind, 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 Baumansicht konnten Sie nur einen einzelnen Knoten und dessen Vorgänger 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:
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. 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 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 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 Barrierefreiheit von Chromium wir präsentieren wollten.
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 die Inhalte jedes Tabs in verschiedenen Renderer-Prozessen platziert, 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 „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 unnötig 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. 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 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 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. 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
Der neue Baum für Barrierefreiheit im Internet 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 mithilfe der API zu ermöglichen, die für Hilfstechnologien verfügbar ist.