Inhalte ausblenden und aktualisieren

Verbergen von Inhalten vor assistiven Technologien

Alice Boxhall

Dave Gash

Meggin Kearney

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 von aria-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 war false).
• 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 jedoch additions text. Wenn Sie aria-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.