Verbergen von Inhalten vor assistiven Technologien
Aria-verborgen
Eine weitere wichtige Methode zur Optimierung der Nutzung für Nutzer von Hilfstechnologien besteht darin, dafür zu sorgen, dass nur relevante Teile der Seite für Hilfstechnologien sichtbar sind. Es gibt mehrere Möglichkeiten, dafür zu sorgen, dass ein Bereich des DOM nicht für APIs zur Barrierefreiheit freigegeben wird.
Erstens: Alles, was im DOM explizit ausgeblendet ist, wird auch nicht in den Baum für Barrierefreiheit aufgenommen. Alle Inhalte mit dem CSS-Stil visibility:
hidden
oder display: none
oder mit dem HTML5-Attribut hidden
werden also auch für Nutzer von Hilfstechnologien ausgeblendet.
Ein Element, das nicht visuell gerendert, aber nicht explizit ausgeblendet wird, ist jedoch weiterhin im Bedienungshilfen-Baum enthalten. Eine gängige Methode besteht darin, „nur für Screenreader sichtbaren Text“ in einem Element zu platzieren, das absolut außerhalb des Bildschirms positioniert ist.
.sr-only {
position: absolute;
left: -10000px;
width: 1px;
height: 1px;
overflow: hidden;
}
Wie wir bereits gesehen haben, ist es auch möglich, Text, der nur für Screenreader bestimmt ist, über ein aria-label
-, aria-labelledby
- oder aria-describedby
-Attribut anzugeben, das auf ein Element verweist, das ansonsten ausgeblendet ist.
Weitere Informationen zum Erstellen von Text, der nur für Screenreader sichtbar ist, finden Sie in diesem WebAIM-Artikel zu Methoden zum Ausblenden von Text.
Schließlich bietet ARIA mit dem Attribut aria-hidden
einen Mechanismus, mit dem Inhalte von Hilfstechnologien ausgeschlossen werden können, die nicht visuell ausgeblendet sind.
Wenn Sie dieses Attribut auf ein Element anwenden, werden es und alle seine Nachkommen aus dem Baum für Barrierefreiheit entfernt. Die einzigen Ausnahmen sind Elemente, auf die über ein aria-labelledby
- oder aria-describedby
-Attribut verwiesen wird.
<div class="deck">
<div class="slide" aria-hidden="true">
Sales Targets
</div>
<div class="slide">
Quarterly Sales
</div>
<div class="slide" aria-hidden="true">
Action Items
</div>
</div>
Sie können aria-hidden
beispielsweise verwenden, wenn Sie eine modale Benutzeroberfläche erstellen, die den Zugriff auf die Hauptseite blockiert. In diesem Fall sieht ein sehender Nutzer möglicherweise eine Art von halbtransparentem Overlay, das darauf hinweist, dass ein Großteil der Seite derzeit nicht verwendet werden kann. Ein Screenreader-Nutzer kann jedoch möglicherweise trotzdem die anderen Bereiche der Seite erkunden. In diesem Fall müssen Sie nicht nur die oben beschriebene Tastaturfalle erstellen, sondern auch dafür sorgen, dass die Teile der Seite, die derzeit nicht im Fokus sind, ebenfalls aria-hidden
sind.
Sie kennen jetzt die Grundlagen von ARIA, wie es mit der nativen HTML-Semantik zusammenspielt und wie es verwendet werden kann, um ziemlich umfangreiche Änderungen am Baum der Barrierefreiheit vorzunehmen und die Semantik eines einzelnen Elements zu ändern. Sehen wir uns nun an, wie wir damit zeitkritische Informationen vermitteln können.
Aria Live
Mit aria-live
können Entwickler einen Teil der Seite als „live“ kennzeichnen, d. h., dass Updates unabhängig von der Position auf der Seite sofort an die Nutzer gesendet werden sollten, anstatt nur dann, wenn sie diesen Teil der Seite zufällig aufrufen. Wenn ein Element ein aria-live
-Attribut hat, wird der Teil der Seite, der es und seine Nachkommen enthält, als Live-Region bezeichnet.
Eine Live-Region kann beispielsweise eine Statusmeldung sein, die als Ergebnis einer Nutzeraktion angezeigt wird. Wenn die Mitteilung wichtig genug ist, um die Aufmerksamkeit sehender Nutzer zu erregen, ist sie auch wichtig genug, um die Aufmerksamkeit von Nutzern mit Hilfstechnologien darauf zu lenken. Legen Sie dazu das aria-live
-Attribut fest. Vergleichen Sie diese einfache div
<div class="status">Your message has been sent.</div>
mit dem „Live“-Äquivalent.
<div class="status" aria-live="polite">Your message has been sent.</div>
Für aria-live
sind drei Werte zulässig: polite
, assertive
und off
.
aria-live="polite"
weist die Hilfstechnologie an, den Nutzer über diese Änderung zu informieren, sobald die aktuelle Aktion abgeschlossen ist. Sie eignet sich gut, wenn etwas wichtig, aber nicht dringend ist. Sie wird am häufigsten verwendet.aria-live="assertive"
weist die Hilfstechnologie an, die aktuelle Aktion zu unterbrechen und den Nutzer sofort über diese Änderung zu informieren. Dies gilt nur für wichtige und dringende Aktualisierungen, z. B. Statusmeldungen wie „Es ist ein Serverfehler aufgetreten und Ihre Änderungen wurden nicht gespeichert. Bitte aktualisieren Sie die Seite.“ oder Aktualisierungen an einem Eingabefeld als direkte Folge einer Nutzeraktion, z. B. Schaltflächen in einem Stepper-Widget.aria-live="off"
weist die Hilfstechnologie an, Unterbrechungen vonaria-live
vorübergehend zu pausieren.
Es gibt einige Tricks, mit denen Sie sicherstellen können, dass Ihre Live-Regionen ordnungsgemäß funktionieren.
Zuerst sollte die aria-live
-Region beim ersten Laden der Seite festgelegt werden.
Das ist keine feste Regel, aber wenn Sie Probleme mit einer aria-live
-Region haben, könnte das der Grund sein.
Zweitens reagieren verschiedene Screenreader unterschiedlich auf verschiedene Arten von Änderungen. Beispielsweise ist es möglich, bei einigen Screenreadern eine Benachrichtigung auszulösen, indem der Stil hidden
eines untergeordneten Elements von „true“ zu „false“ geändert wird.
Mit anderen Attributen, die mit aria-live
funktionieren, können Sie anpassen, was Nutzern angezeigt wird, wenn sich die Live-Region ändert.
aria-atomic
gibt an, ob die gesamte Region bei der Kommunikation von Updates als Ganzes betrachtet werden soll. Wenn beispielsweise ein Datums-Widget, das aus einem Tag, Monat und Jahr besteht, aria-live=true
und aria-atomic=true
hat und der Nutzer ein Schrittsteuerelement verwendet, um nur den Wert des Monats zu ändern, wird der vollständige Inhalt des Datums-Widgets noch einmal vorgelesen. Der Wert von aria-atomic
kann true
oder false
(Standardeinstellung) sein.
aria-relevant
gibt an, welche Arten von Änderungen dem Nutzer angezeigt werden sollen.
Es gibt einige Optionen, die separat oder als Tokenliste verwendet werden können.
- additions – es spielt also eine Rolle, ob jedes Element, das der Live-Region hinzugefügt wird, von Bedeutung ist. Wenn Sie beispielsweise einem vorhandenen Protokoll mit Statusmeldungen einen Span anhängen, wird der Span dem Nutzer angesagt (vorausgesetzt,
aria-atomic
warfalse
). - text, d. h. Textinhalte, die einem untergeordneten Knoten hinzugefügt werden, sind relevant. Wenn Sie beispielsweise das Attribut
textContent
eines benutzerdefinierten Textfeldes ändern, wird der geänderte Text für den Nutzer vorgelesen. - Entfernungen, d. h. das Entfernen von Text oder untergeordneten Knoten muss dem Nutzer mitgeteilt werden.
- alle, was bedeutet, dass alle Änderungen relevant sind. Der Standardwert für
aria-relevant
ist jedochadditions text
. Wenn Siearia-relevant
also nicht angeben, wird der Nutzer bei jeder Ergänzung des Elements benachrichtigt. Das ist in den meisten Fällen auch das, was Sie möchten.
Mit aria-busy
können Sie Hilfstechnologien außerdem mitteilen, dass sie Änderungen an einem Element vorübergehend ignorieren sollen, z. B. beim Laden von Inhalten. Sobald alles eingerichtet ist, sollte aria-busy
auf „false“ gesetzt werden, um den Betrieb des Lesegeräts zu normalisieren.