In den Chrome-Entwicklertools wird eine vollständige Struktur zur Barrierefreiheit veröffentlicht, die es Entwicklern einfacher macht, sich einen Überblick zu verschaffen. In diesem Beitrag erfahren Sie, wie dieser Baum erstellt wird und wie Sie ihn bei Ihrer Arbeit verwenden 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 der Baum der Bedienungshilfen: eine Baumstruktur aus Bedienungshilfen, die mithilfe von Hilfstechnologien nach Attributen und Eigenschaften abfragen und Aktionen ausführen kann. Webentwickler gestalten und bearbeiten die Struktur für Barrierefreiheit hauptsächlich über DOM-Eigenschaften wie ARIA-Attribute für HTML.
In den Chrome-Entwicklertools finden Entwickler einen Bereich mit Bedienungshilfen, damit sie nachvollziehen können, wie ihre Inhalte durch Hilfstechnologien ausgesetzt werden. Konkret werden bei Auswahl eines Knotens in der DOM-Baumansicht die Eigenschaften des entsprechenden Knotens für Bedienungshilfen im Bereich zusammen mit einer Ansicht der Ancestors und der unmittelbaren untergeordneten Elemente des Knotens angezeigt.
Wie wird der Baum erstellt?
Bevor wir uns damit befassen, wie diese neue vollständige Baumansicht in den Entwicklertools aussieht, möchten wir kurz darauf eingehen, was die Baumstruktur für Barrierefreiheit bedeutet. Der Baum für Barrierefreiheit ist eine Ableitung des DOM-Baums. Die Struktur ist ungefähr gleich, wurde aber vereinfacht. Knoten ohne semantischen Inhalt, z. B. ein <div>-Element, das nur für Stile verwendet wird, werden entfernt. 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 namens Blink leitet eine interne Struktur für Bedienungshilfen grob 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 scheinbar der obigen Aussage widerspricht, dass der Baum für Barrierefreiheit eine vereinfachte Ableitung des DOM-Baums ist. Dennoch kommen die meisten dieser Knoten nur in der internen Struktur vor und sind nicht mit Hilfstechnologien ausgesetzt. Da die Entwicklertools die Informationen zur Barrierefreiheit direkt aus dem Renderer-Prozess erfassen, ist dies die Baumdarstellung, die von 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 der neue Baum sich als besser erforschen, nützlicher und benutzerfreundlicher erweisen wird.
Nachdem Sie nun wissen, wie die Baumansicht für Bedienungshilfen funktioniert, können Sie sich mit den Entwicklertools ansehen, wie die neue Baumansicht aussieht. Das folgende HTML-Dokument mit einem Titel, einer Überschrift und zwei Schaltflächen wird zum Anzeigen der Struktur verwendet.
<!DOCTYPE html>
<title>Test</title>
<h1>Heading for example page</h1>
<div>
<button>Back</button>
<button>Next</button>
</div>
In der vorherigen Baumansicht könnten Sie nur einen einzelnen Knoten und seine Ancestors untersuchen.
Wenn Sie jetzt den neuen Baum ein-/ausblenden, ersetzt er die DOM-Baumansicht und Sie können den vollständigen Baum für Barrierefreiheit auf der Seite sehen:
Verzögerte Baumkonstruktion
Damit der Baum auch für größere Standorte leistungsfähiger wird, wird er am Front-End verzögert konstruiert, während er erkundet wird. Sobald ein Knoten in der Baumstruktur erweitert wurde, werden die untergeordneten Knoten über das Chrome DevTools Protocol (CDP) abgerufen und die Struktur neu erstellt.
Livestreams
Die neue Baumansicht ist live und wird dynamisch aktualisiert, wenn sich die Struktur für Barrierefreiheit im Renderer ändert. Sie verbindet sich mit denselben Mechanismen, die assistive Technologien über Änderungen an der Struktur informieren würden, und verwendet diese, um Ereignisse an das DevTools-Front-End mit aktualisierten Knoten auszugeben. In der Praxis wartet das CDP-Back-End auf Aktualisierungen der Struktur, verfolgt, welche Knoten zuvor angefordert wurden, und sendet Ereignisse an das DevTools-Front-End, wenn sich einer dieser Knoten ändert.
Die Geschichte vieler Bäume
In der Beschreibung des Baums für Barrierefreiheit haben Sie erfahren, wie Blink einen Baum für Barrierefreiheit für das gerenderte DOM erstellt. DevTools ruft diese Baumstruktur über CDP ab. Dies stimmt zwar, aber wir haben einige Zusatzfunktionen in dieser Beschreibung 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 internen Elemente von Chromium zur Barrierefreiheit angezeigt werden sollte.
Plattformen
Jede Plattform hat eine andere Accessibility API. 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 sich unterscheiden. Die Entwicklertools zeigen die interne Struktur von Chromium, in der Rollen und Attribute mit denen in der ARIA-Spezifikation übereinstimmen.
Mehrere Frames und Website-Isolierung
Da Chromium nicht nur den Inhalt jedes Tabs in verschiedene Renderer-Prozesse platziert, sondern auch websiteübergreifende Dokumente in verschiedenen Renderer-Prozessen isoliert, müssen wir mit jedem untergeordneten Out-of-Process-Dokument über CDP separat eine Verbindung zu jedem untergeordneten Dokument herstellen und dessen Barrierefreiheitsstruktur abrufen. Diese Teilbäume werden dann im Front-End zusammengefügt, um den Anschein zu erwecken, dass es sich um einen kohärenten Baum handelt, obwohl sie in Chromium in verschiedenen Renderer-Prozessen enthalten sind.
Ignorierte und uninteressante Knoten
Einige Knoten werden standardmäßig ausgeblendet: ignorierte Knoten und Knoten mit der Rolle „generic“ ohne Namen. Diese Knoten haben keine semantische Bedeutung und sind im Fall ignorierter Knoten nicht mit Hilfstechnologien ausgesetzt. Diese Knoten werden ausgeblendet, um die Baumansicht nicht zu überladen. Andernfalls würde der Baum für Barrierefreiheit für die meisten Webseiten in etwa so aussehen:
Dies bedeutet jedoch im Wesentlichen, dass ein weiterer Baum erstellt werden muss, als im Back-End verfügbar ist. Angenommen, 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, entfernen wir X aus dem Baum und erstellen stattdessen einen Baum, in dem C ein untergeordnetes Element von A ist.
Im Front-End erstellen wir den vollständigen Baum einschließlich ignorierter Knoten und bereinigen sie nur unmittelbar vor dem Rendern der Knoten. Dies geschieht aus zwei Gründen:
- Es vereinfacht die Verarbeitung von Knotenaktualisierungen vom Back-End aus, da auf beiden Endpunkten dieselbe Baumstruktur verwendet wird. Wenn beispielsweise Knoten B in diesem Beispiel entfernt wird, erhalten wir ein Update für Knoten X, da sich seine untergeordneten Elemente geändert haben. Wenn wir diesen Knoten jedoch gekürzt hätten, würden wir Schwierigkeiten haben, herauszufinden, was aktualisiert werden soll.
- Sie sorgt dafür, dass alle DOM-Knoten einen entsprechenden Bedienungshilfen-Knoten haben. Wenn der Baum ein- und ausgeschaltet wird, wählen wir den Knoten aus, der dem derzeit im DOM-Baum ausgewählten Knoten entspricht. Für das vorherige Beispiel gilt: Wenn der Nutzer den Baum ein- und ausschaltet, während der DOM-Knoten ausgewählt ist, der X entspricht, wird X zwischen den Knoten A und B eingefügt und wir wählen X im Baum aus. Auf diese Weise kann der Nutzer den Zugänglichkeitsknoten für alle DOM-Knoten überprü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 einige Ideen für zukünftige Projekte, die wir auf der neuen Ansicht aufbauen könnten, und würden uns freuen, Ihr 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 Landmark-Knoten anzeigen oder Überschriften anzeigen bereitzustellen.
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 anzeigen
Der Baum, den wir derzeit zeigen, ist nur einseitig: Er ermöglicht uns, eine Vorstellung davon zu bekommen, welche Informationen von assistiven Technologien gefüttert werden, wenn sie auf einer bestimmten Webseite surfen. Bedienungshilfen-Aktionen stellen die Kommunikation in die andere Richtung dar: Sie ermöglichen Hilfstechnologien, auf der dargestellten Benutzeroberfläche zu agieren. Wir könnten solche Aktionen in den Entwicklertools anzeigen lassen, um Aktionen wie „Klicken“, Scrollen oder Ändern von Werten auf der Seite mithilfe der API zu ermöglichen, die für Hilfstechnologien zur Verfügung steht.