Einführung in den Baum für Barrierefreiheit im Internet
Angenommen, Sie erstellen eine Benutzeroberfläche nur für Nutzer von Screenreadern. Hier müssen Sie keine visuelle Benutzeroberfläche erstellen, Informationen für den Screenreader.
In diesem Fall würden Sie eine Art API erstellen, die die Seitenstruktur beschreibt, zur DOM-API, aber mit weniger Informationen und Knoten, denn viele dieser Informationen sind nur für die visuelle Präsentation nützlich. Es könnte etwa so aussehen.
Dies ist im Grunde das, was der Browser dem Screenreader tatsächlich anzeigt. Die wandelt den DOM-Baum die DOM-Struktur so um, Hilfstechnologien. Wir bezeichnen diese geänderte Baumstruktur als Bedienungshilfen Baum.
Sie können sich den Baum für Barrierefreiheit so vorstellen, als ob er wie eine alte Webseite aussieht. aus den 90er Jahren: ein paar Bilder, viele Links, vielleicht ein Feld und eine Schaltfläche.
Wenn Sie eine Seite wie in diesem Beispiel visuell durchgehen, was Nutzende von Screenreadern erhalten würden. Die Benutzeroberfläche ist vorhanden, aber einfach gehalten. und direkt, ähnlich wie eine Barrierefreiheitsstruktur.
Der Baum für Barrierefreiheit ist das Element, mit dem die meisten assistiven Technologien interagieren. Die sieht ungefähr so aus.
- Eine Anwendung (der Browser oder eine andere Anwendung) stellt eine semantische Version ihrer Benutzeroberfläche für Hilfstechnologien über eine API
- Die Hilfstechnologien können die Informationen, die sie über die API liest, für folgende Zwecke nutzen: eine alternative Darstellung der Benutzeroberfläche für die Nutzenden zu erstellen. Beispiel: Ein Screenreader erstellt eine Schnittstelle, über die Nutzende gesprochene Darstellung der App.
- Mit der assistiven Technologie können Nutzende auch in auf eine andere Art und Weise. Die meisten Screenreader stellen beispielsweise Hooks bereit, mit denen ein einen Mausklick oder Fingertipp zu simulieren.
- Die assistive Technologie leitet die Absicht der Nutzenden (wie z. B. das Klicken) an über die Accessibility API. Die App ist dann dafür verantwortlich, die Aktion im Kontext der ursprünglichen UI richtig interpretieren.
Bei Webbrowsern ist ein zusätzlicher Schritt in jede Richtung erforderlich, da der Browser ist eigentlich eine Plattform für Web-Apps, die darin ausgeführt werden können. Der Browser muss also die Webanwendung in einen Baum für Barrierefreiheit übersetzen in JavaScript basierend auf den Nutzeraktionen entsprechend den entsprechenden Ereignissen ausgelöst werden, von assistiven Technologien.
Aber das ist die Verantwortung des Browsers. Unsere Aufgabe als Webentwickler besteht darin, sich bewusst zu sein, und Webseiten zu entwickeln, um eine barrierefreie Umgebung für unsere Nutzenden zu schaffen.
Dazu müssen wir sicherstellen, dass die Semantik unserer Seiten richtig zum Ausdruck kommt: dass die wichtigen Elemente auf der Seite die richtigen barrierefreien Rollen, Status und Eigenschaften und wir geben barrierefreie Namen und Beschreibungen. Der Browser kann dann der assistiven Technologie Zugriff um eine individuelle Nutzererfahrung zu bieten.
Semantik in nativem HTML
Ein Browser kann den DOM-Baum in einen Baum für Barrierefreiheit umwandeln, da ein Großteil der Das DOM hat eine implizite semantische Bedeutung. Das heißt, das DOM verwendet natives HTML Elemente, die von Browsern erkannt werden und auf einer Vielzahl von Plattformen. Barrierefreiheit für native HTML-Elemente wie Links oder Schaltflächen automatisch verarbeitet wird. 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, aber nicht wie native Elemente. Zum Beispiel wird diese „Schaltfläche“ überhaupt keine Taste.
Er kann auf unterschiedliche Weise in HTML aufgebaut sein. wird unten eine Richtung gezeigt.
<div class="button-ish">Give me tacos</div>
Wenn kein echtes Schaltflächenelement verwendet wird, hat der Screenreader keine Möglichkeit, zu erkennen, woran er gelandet ist. Außerdem müssten wir einen zusätzlichen Aufwand durchführen, tabindex Sie ist auch für Nutzer geeignet, die nur die Tastatur nutzen. mit der Maus.
Dieses Problem lässt sich leicht beheben, indem wir ein reguläres button
-Element anstelle eines div
-Elements verwenden.
Die Verwendung eines nativen Elements hat auch den Vorteil, dass die Tastatur gepflegt werden muss.
Interaktionen für uns. Ihre schicke Grafik muss nicht verloren gehen
nur weil Sie ein natives Element verwenden, können Sie native Elemente
Sie lassen sie so aussehen, wie Sie es möchten, und behalten dabei die implizite Semantik
verhalten.
Wir haben bereits erwähnt, dass Screenreader die Rolle, den Namen, Zustand und den Wert. Durch Verwendung des richtigen semantischen Elements, der Rolle, des Status und des Werts aber wir müssen auch sicherstellen, dass der Name eines Elements sichtbar sind.
Grundsätzlich gibt es zwei Arten von Namen:
- Sichtbare Labels, die von allen Nutzern verwendet werden, um einem Element eine Bedeutung zuzuordnen -Element und
- Textalternativen, die nur verwendet werden, wenn kein visuelles Element erforderlich ist .
Für Elemente auf Textebene müssen wir nichts tun, da sie per Definition werden einige Textinhalte enthalten. Für Eingabe- oder Steuerelemente und visuelle Elemente z. B. Bilder, müssen wir einen Namen angeben. Tatsächlich ist die Bereitstellung von textbasierten Alternativen für Nicht-Text-Inhalte die ersten Punkt auf der WebAIM-Checkliste.
Eine Möglichkeit dazu besteht darin, der Empfehlung zu folgen, zugehörigen Textlabels“. Es gibt zwei Möglichkeiten, einem Formular ein Label zuzuweisen. wie z. B. ein Kästchen. Bei beiden Methoden wird auch der Labeltext Klickziel für das Kästchen, was auch für Maus- oder Touchscreen-Nutzer. So verknüpfen Sie ein Label mit einem Element:
- Eingabeelement innerhalb eines label-Elements platzieren
<label> <input type="checkbox">Receive promotional offers? </label>
oder
- Verwenden Sie das Attribut
for
des Labels und verweisen Sie auf dasid
des Elements
<input id="promo" type="checkbox">
<label for="promo">Receive promotional offers?</label>
Wenn das Kästchen mit der richtigen Beschriftung versehen ist, kann der Screenreader Folgendes melden: Das Element hat die Rolle „Kästchen“, ist im Status „aktiviert“ und heißt „Empfangen“ Werbeangeboten?".
<ph type="x-smartling-placeholder">