Einführung in die Baumstruktur für Barrierefreiheit im Internet
Stellen Sie sich vor, Sie erstellen eine Benutzeroberfläche nur für Screenreader-Nutzer. Hier müssen Sie überhaupt keine visuelle Benutzeroberfläche erstellen, sondern nur genügend Informationen für den Screenreader bereitstellen.
Sie würden eine Art API erstellen, die die Seitenstruktur beschreibt, ähnlich der DOM API. Sie können jedoch mit weniger Informationen und weniger Knoten auskommen, da viele dieser Informationen nur für die visuelle Darstellung nützlich sind. Das könnte in etwa so aussehen.
Das ist im Grunde das, was der Browser dem Screenreader präsentiert. Der Browser nimmt den DOM-Baum und wandelt ihn in eine Form um, die für Hilfstechnologien nützlich ist. Diese modifizierte Baumstruktur wird als Bedienungshilfen-Baumstruktur bezeichnet.
Sie können sich die Struktur der Bedienungshilfen wie eine alte Webseite aus den 90er-Jahren vorstellen: ein paar Bilder, viele Links, vielleicht ein Feld und eine Schaltfläche.
Wenn Sie eine Seite wie diese visuell überfliegen, erhalten Sie einen ähnlichen Eindruck wie ein Nutzer mit Screenreader. Die Benutzeroberfläche ist vorhanden, aber sie ist einfach und direkt, ähnlich wie die Benutzeroberfläche eines Accessibility Trees.
Die meisten Hilfstechnologien interagieren mit der Baumansicht für Barrierefreiheit. Der Ablauf sieht in etwa so aus:
- Eine Anwendung (der Browser oder eine andere App) stellt Hilfstechnologien über eine API eine semantische Version ihrer Benutzeroberfläche zur Verfügung.
- Die Hilfstechnologie kann die über die API gelesenen Informationen verwenden, um eine alternative Darstellung der Benutzeroberfläche für den Nutzer zu erstellen. Ein Screenreader erstellt beispielsweise eine Benutzeroberfläche, auf der der Nutzer eine gesprochene Darstellung der App hört.
- Die Hilfstechnologie kann dem Nutzer auch ermöglichen, auf andere Weise mit der App zu interagieren. Die meisten Screenreader bieten beispielsweise Hooks, mit denen Nutzer ganz einfach einen Mausklick oder ein Tippen mit dem Finger simulieren können.
- Die Hilfstechnologie leitet die Nutzerabsicht (z. B. „Klicken“) über die Accessibility API an die App weiter. Die App ist dann dafür verantwortlich, die Aktion im Kontext der ursprünglichen Benutzeroberfläche entsprechend zu interpretieren.
Bei Webbrowsern gibt es in jeder Richtung einen zusätzlichen Schritt, da der Browser tatsächlich eine Plattform für Web-Apps ist, die darin ausgeführt werden. Der Browser muss die Web-App also in eine Baumstruktur für Barrierefreiheit übersetzen und dafür sorgen, dass die entsprechenden Ereignisse in JavaScript ausgelöst werden, basierend auf den Nutzeraktionen, die von der Hilfstechnologie eingehen.
Aber das liegt alles in der Verantwortung des Browsers. Als Webentwickler müssen wir uns dessen bewusst sein und Webseiten entwickeln, die diesen Prozess nutzen, um unseren Nutzern ein barrierefreies Erlebnis zu bieten.
Dazu müssen wir die Semantik unserer Seiten korrekt ausdrücken: Wir müssen dafür sorgen, dass die wichtigen Elemente auf der Seite die richtigen barrierefreien Rollen, Zustände und Eigenschaften haben und dass wir barrierefreie Namen und Beschreibungen angeben. Der Browser kann dann der Hilfstechnologie Zugriff auf diese Informationen gewähren, um eine personalisierte Nutzung zu ermöglichen.
Semantik in nativem HTML
Ein Browser kann den DOM-Baum in eine Bedienungshilfen-Baumstruktur umwandeln, da ein Großteil des DOM eine implizite semantische Bedeutung hat. Das bedeutet, dass das DOM native HTML-Elemente verwendet, die von Browsern erkannt werden und auf verschiedenen Plattformen vorhersehbar funktionieren. Die Barrierefreiheit für native HTML-Elemente wie Links oder Schaltflächen wird daher automatisch berücksichtigt. Wir können diese integrierte Barrierefreiheit nutzen, indem wir HTML schreiben, das die Semantik unserer Seitenelemente ausdrückt.
Manchmal verwenden wir jedoch Elemente, die wie native Elemente aussehen, es aber nicht sind. Diese „Schaltfläche“ ist beispielsweise gar keine Schaltfläche.
Es kann auf verschiedene Arten in HTML erstellt werden. Eine Möglichkeit wird unten gezeigt.
<div class="button-ish">Give me tacos</div>
Wenn wir kein tatsächliches Schaltflächenelement verwenden, kann der Screenreader nicht wissen, worauf er gelandet ist. Außerdem müssten wir den zusätzlichen Aufwand betreiben, tabindex hinzuzufügen, damit es für Nutzer, die nur die Tastatur verwenden, nutzbar ist, da es so, wie es jetzt codiert ist, nur mit einer Maus verwendet werden kann.
Das lässt sich ganz einfach beheben, indem wir ein reguläres button-Element anstelle eines div-Elements verwenden.
Die Verwendung eines nativen Elements hat außerdem den Vorteil, dass Tastaturinteraktionen für uns übernommen werden. Und denken Sie daran, dass Sie nicht auf Ihre schicken visuellen Effekte verzichten müssen, nur weil Sie ein natives Element verwenden. Sie können native Elemente so gestalten, dass sie so aussehen, wie Sie es möchten, und trotzdem die implizite Semantik und das Verhalten beibehalten.
Wir haben bereits erwähnt, dass Screenreader die Rolle, den Namen, den Status und den Wert eines Elements ansagen. Durch die Verwendung des richtigen semantischen Elements werden Rolle, Status und Wert abgedeckt. Wir müssen aber auch dafür sorgen, dass der Name eines Elements auffindbar ist.
Grob gesagt gibt es zwei Arten von Namen:
- Sichtbare Labels, die von allen Nutzern verwendet werden, um einem Element eine Bedeutung zuzuordnen, und
- Textalternativen, die nur verwendet werden, wenn kein visuelles Label erforderlich ist.
Bei Elementen auf Textebene müssen wir nichts tun, da sie per Definition Textinhalte enthalten. Für Eingabe- oder Steuerelemente und visuelle Inhalte wie Bilder müssen wir jedoch einen Namen angeben. Tatsächlich ist die Bereitstellung von Textalternativen für alle Inhalte, die nicht auf Text basieren, der allererste Punkt auf der WebAIM-Checkliste.
Eine Möglichkeit besteht darin, der Empfehlung zu folgen, dass „Formulareingaben mit Textlabels verknüpft sind“. Es gibt zwei Möglichkeiten, ein Label mit einem Formularelement wie einem Kästchen zu verknüpfen. Bei beiden Methoden wird der Labeltext auch zu einem Klickziel für das Kästchen, was auch für Nutzer mit Maus oder Touchscreen hilfreich ist. So verknüpfen Sie ein Label mit einem Element:
- Das input-Element in ein label-Element einfügen
<label>
<input type="checkbox">Receive promotional offers?
</label>oder
- Verwenden Sie das Attribut
fordes Labels und verweisen Sie auf das Attributiddes Elements
<input id="promo" type="checkbox">
<label for="promo">Receive promotional offers?</label>
Wenn das Kästchen korrekt beschriftet ist, kann der Screenreader melden, dass das Element die Rolle „Kästchen“ hat, aktiviert ist und den Namen „Werbeangebote erhalten?“ hat.
