Einführung in den Baum für Bedienungshilfen
Stellen Sie sich vor, Sie erstellen eine Benutzeroberfläche nur für Nutzer von Screenreadern. Hier müssen Sie gar keine visuelle UI erstellen, sondern lediglich genügend Informationen für den Screenreader bereitstellen.
Sie erstellen also eine Art API, die die Seitenstruktur ähnlich wie die DOM API beschreibt. Allerdings benötigen Sie weniger Informationen und weniger Knoten, da viele dieser Informationen nur für die visuelle Darstellung nützlich sind. Das könnte etwa so aussehen:
![DOM API-Modell für Screenreader](https://web.dev/static/articles/the-accessibility-tree/image/screen-reader-dom-api-moc-86f15b848dd25.jpg?authuser=6&hl=de)
Das ist im Grunde das, was der Browser dem Screenreader tatsächlich anzeigt. Der Browser wandelt den DOM-Baum in eine für Hilfstechnologien geeignete Form um. Diese geänderte Baumstruktur wird als Accessibility Baum bezeichnet.
Sie können sich den Baum für Barrierefreiheit wie eine alte Webseite aus den 90ern vorstellen: ein paar Bilder, viele Links, vielleicht ein Feld und eine Schaltfläche.
![Eine Webseite im Stil der 1990er](https://web.dev/static/articles/the-accessibility-tree/image/a-1990s-style-web-page-71a74592e602e.png?authuser=6&hl=de)
Das visuelle Scannen einer Seite wie in diesem Fall bietet ähnliche Funktionen wie ein Screenreader-Nutzer. Die Oberfläche ist zwar vorhanden, aber sie ist einfach und direkt, ähnlich wie eine Bedienungshilfe-Baumoberfläche.
Die meisten assistiven Technologien interagieren mit dem Baum für Barrierefreiheit. Der Ablauf läuft in etwa so ab.
- Eine Anwendung (der Browser oder eine andere Anwendung) stellt eine semantische Version ihrer UI über eine API für Hilfstechnologien zur Verfügung.
- Die Hilfstechnologie kann die Informationen, die sie über die API liest, verwenden, um eine alternative Darstellung der Benutzeroberfläche für den Nutzer zu erstellen. Ein Screenreader erstellt beispielsweise eine Oberfläche, auf der der Nutzer eine gesprochene Darstellung der App hört.
- Die assistive Technologie kann Nutzenden auch ermöglichen, auf andere Weise mit der App zu interagieren. Die meisten Screenreader bieten beispielsweise Hooks, mit denen Nutzer auf einfache Weise einen Mausklick oder Fingertipp simulieren können.
- Die Hilfstechnologie leitet die Absicht des Nutzers (z. B. „Klicken“) über die Accessibility API an die App weiter. Die App trägt dann die Verantwortung, die Aktion im Kontext der ursprünglichen UI entsprechend zu interpretieren.
Bei Webbrowsern gibt es einen zusätzlichen Schritt in jede Richtung, da der Browser eigentlich eine Plattform für darin ausgeführte Webanwendungen ist. Der Browser muss also die Webanwendung in einen Baum für Bedienungshilfen übersetzen und dafür sorgen, dass die entsprechenden Ereignisse basierend auf den Nutzeraktionen, die über die Hilfstechnologie eingehen, in JavaScript ausgelöst werden.
Aber das liegt in der Verantwortung des Browsers. Unsere Aufgabe als Webentwickler ist es, uns dieser Entwicklung bewusst zu sein und Webseiten zu entwickeln, die diesen Prozess nutzen, um eine barrierefreie Umgebung für unsere Nutzer zu schaffen.
Dazu achten wir darauf, dass wir die Semantik unserer Seiten richtig ausdrücken: Die wichtigen Elemente auf der Seite müssen die korrekten zugänglichen Rollen, Status und Eigenschaften haben und wir müssen barrierefreie Namen und Beschreibungen angeben. Der Browser kann dann die Hilfstechnologien Zugriff auf diese Informationen geben, um ein benutzerdefiniertes Erlebnis zu schaffen.
Semantik in nativem HTML
Ein Browser kann den DOM-Baum in einen Baum für Barrierefreiheit umwandeln, da ein Großteil des DOMs eine implizite semantische Bedeutung hat. Das bedeutet, dass das DOM native HTML-Elemente verwendet, die von Browsern erkannt werden und auf einer Vielzahl von Plattformen vorhersehbar funktionieren. Die Zugänglichkeit für native HTML-Elemente wie Links oder Schaltflächen wird automatisch gehandhabt. Wir können diese integrierte Barrierefreiheit nutzen, indem wir HTML-Code schreiben, der 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 überhaupt keine Schaltfläche.
Es gibt verschiedene Möglichkeiten, in HTML zu konstruieren. Eine Möglichkeit wird unten gezeigt.
<div class="button-ish">Give me tacos</div>
Wenn wir kein tatsächliches Schaltflächenelement verwenden, hat der Screenreader keine Möglichkeit zu wissen, worauf es ankommt. Außerdem müssten wir zusätzlich tabindex hinzufügen, damit dieser nur für Nutzer mit der Tastatur genutzt werden kann, da er jetzt codiert ist und nur mit einer Maus verwendet werden kann.
Dieses Problem lässt sich leicht beheben, indem wir anstelle eines div
-Elements ein reguläres button
-Element verwenden.
Die Verwendung eines nativen Elements hat auch den Vorteil, dass wir uns um Tastaturinteraktionen kümmern. Und denken Sie daran, dass Ihre optisch ansprechenden Effekte nicht allein wegen der Verwendung eines nativen Elements verloren gehen müssen. Sie können native Elemente so gestalten, dass sie wie gewünscht aussehen, und behalten dabei die implizite Semantik und das Verhalten bei.
Wir haben bereits erwähnt, dass Screenreader die Rolle, den Namen, den Status und den Wert eines Elements vorlesen. Durch die Verwendung des richtigen semantischen Elements werden die Rollen, der Status und der Wert abgedeckt. Wir müssen aber auch dafür sorgen, dass der Name eines Elements gut sichtbar ist.
Im Großen und Ganzen 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 keine visuellen Labels erforderlich sind.
Für Elemente auf Textebene müssen wir nichts tun, da sie per Definition Textinhalt enthalten. Für Eingabe- oder Steuerelemente und visuelle Inhalte wie Bilder muss jedoch ein Name angegeben werden. Tatsächlich ist die Bereitstellung von Textalternativen für alle Nicht-Text-Inhalte der erste Punkt auf der WebAIM-Checkliste.
Eine Möglichkeit, dies zu tun, besteht darin, der Empfehlung zu folgen, dass Formulareingaben verknüpfte Textlabels haben. 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 Maus- oder Touchscreen-Nutzer hilfreich ist. Sie haben zwei Möglichkeiten, ein Label mit einem Element zu verknüpfen:
- Eingabeelement innerhalb eines Label-Elements platzieren
<label> <input type="checkbox">Receive promotional offers? </label>
oder
- Verwende das
for
-Attribut des Labels und verweise auf dasid
-Element des Elements
<input id="promo" type="checkbox">
<label for="promo">Receive promotional offers?</label>
Wenn das Kästchen richtig beschriftet ist, kann der Screenreader melden, dass das Element die Rolle „Kästchen“ hat, sich im aktivierten Status befindet und den Namen „Werbeangebote erhalten?“ hat.
![Bildschirmtextausgabe von VoiceOver mit dem gesprochenen Label für ein Kästchen](https://web.dev/static/articles/the-accessibility-tree/image/on-screen-text-output-vo-2bf0c33d65f23.png?authuser=6&hl=de)