Inhalte ausblenden und aktualisieren

Inhalte vor Hilfstechnologien verbergen

Alice Boxhall

Dave Gash

Meggin Kearney

aria-ausgeblendet

Eine weitere wichtige Technik zur Optimierung der User Experience für Nutzende von assistiven Technologien besteht darin, sicherzustellen, dass nur relevante Teile der Seite von assistiven Technologien ausgesetzt werden. Es gibt verschiedene Möglichkeiten, dafür zu sorgen, dass ein Abschnitt des DOM nicht mit Bedienungshilfen-APIs in Berührung kommt.

Erstens: Alles, was explizit im DOM verborgen ist, wird nicht in die Barrierefreiheitsstruktur aufgenommen. Alle Inhalte, die den CSS-Stil visibility: hidden oder display: none verwenden oder das HTML5-Attribut hidden verwenden, sind also auch für Nutzer von Hilfstechnologien ausgeblendet.

Elemente, die nicht visuell gerendert, aber nicht explizit ausgeblendet sind, werden weiterhin in die Barrierefreiheitsstruktur aufgenommen. Eine gängige Technik besteht darin, „Nur Screenreader-Text“ in ein Element einzufügen, das sich außerhalb des sichtbaren Bildschirmbereichs befindet.

.sr-only {
    position: absolute;
    left: -10000px;
    width: 1px;
    height: 1px;
    overflow: hidden;
}

Außerdem ist es möglich, über ein aria-label-, aria-labelledby- oder aria-describedby-Attribut nur Text für Screenreader bereitzustellen, der auf ein ansonsten verborgenes Element verweist.

Weitere Informationen zum Erstellen von "Nur Screenreader"-Text finden Sie in diesem WebAIM-Artikel zu Verfahren zum Ausblenden von Text.

Zu guter Letzt bietet ARIA über das Attribut aria-hidden einen Mechanismus, mit dem Inhalte, die nicht visuell ausgeblendet sind, von Hilfstechnologien ausgeschlossen werden können. Wenn Sie dieses Attribut auf ein Element anwenden, werden es und alle seine Nachfolger effektiv aus der Barrierefreiheitsstruktur entfernt. Die einzigen Ausnahmen sind Elemente, die durch ein aria-labelledby- oder aria-describedby-Attribut bezeichnet werden.

<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 beispielsweise aria-hidden verwenden, wenn Sie eine modale UI erstellen, die den Zugriff auf die Hauptseite blockiert. In diesem Fall sieht ein sehender Nutzer möglicherweise ein halbtransparentes Overlay, das darauf hinweist, dass der Großteil der Seite derzeit nicht verwendet werden kann. Ein Screenreader-Nutzer kann jedoch möglicherweise dennoch zu den anderen Teilen der Seite navigieren. In diesem Fall und zum Erstellen der oben erläuterten Tastatur-Trap müssen Sie dafür sorgen, dass auch die Teile der Seite, die derzeit ausgeschlossen sind, aria-hidden sind.

Sie kennen nun die Grundlagen von ARIA, wissen, wie native HTML-Semantik eingesetzt wird, wie damit eine größere Operation am Barrierefreiheitsbaum durchgeführt und die Semantik eines einzelnen Elements geändert werden kann. 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“ markieren, sodass Aktualisierungen den Nutzern unabhängig von der Seitenposition sofort mitgeteilt werden sollen und nicht nur, wenn sie diesen Teil der Seite besuchen. Wenn ein Element ein aria-live-Attribut hat, wird der Teil der Seite, der es und die Nachfolgerelemente enthält, als Live-Region bezeichnet.

Eine Live-Region kann beispielsweise eine Statusmeldung sein, die infolge einer Nutzeraktion angezeigt wird. Wenn die Nachricht wichtig genug ist, um die Aufmerksamkeit eines sehenden Nutzers zu erregen, ist es wichtig, durch Festlegen des Attributs aria-live die Aufmerksamkeit eines Nutzers von Hilfstechnologien darauf zu lenken. Diese einfache div vergleichen

<div class="status">Your message has been sent.</div>

mit seinem „live“-Gegenstück.

<div class="status" aria-live="polite">Your message has been sent.</div>

aria-live hat drei zulässige Werte: polite, assertive und off.

• aria-live="polite" weist Hilfstechnologien an, den Nutzer über diese Änderung zu informieren, wenn sie die aktuelle Aktivität abgeschlossen hat. Diese Option empfiehlt sich, wenn etwas wichtig, aber nicht dringend ist und den Großteil der aria-live-Verwendung ausmacht.
• aria-live="assertive" weist Hilfstechnologien an, alles, was sie tun, zu unterbrechen und den Nutzer sofort auf diese Änderung hinzuweisen. Dies gilt nur für wichtige und dringende Aktualisierungen, z. B. für eine Statusmeldung wie „Es ist ein Serverfehler aufgetreten und Ihre Änderungen werden nicht gespeichert. Bitte aktualisieren Sie die Seite.“ oder für Aktualisierungen eines Eingabefelds als direkte Folge einer Nutzeraktion, z. B. Schaltflächen in einem Schritt-Widget.
• aria-live="off" weist Hilfstechnologien an, aria-live Unterbrechungen vorübergehend auszusetzen.

Es gibt einige Tricks, um sicherzustellen, dass Ihre Live-Regionen richtig funktionieren.

Zuerst sollte die Region aria-live wahrscheinlich beim ersten Seitenaufbau festgelegt werden. Dies ist keine harte Regel. Wenn Sie jedoch Probleme mit einer aria-live-Region haben, könnte dies das Problem sein.

Zweitens reagieren verschiedene Screenreader unterschiedlich auf verschiedene Arten von Änderungen. Beispielsweise ist es möglich, auf einigen Screenreadern eine Benachrichtigung auszulösen, indem Sie den hidden-Stil eines untergeordneten Elements von „true“ zu „false“ ändern.

Mit anderen Attributen, die mit aria-live funktionieren, können Sie genau abstimmen, was an den Nutzer gesendet wird, wenn sich die Live-Region ändert.

aria-atomic gibt an, ob die gesamte Region bei der Kommunikation von Aktualisierungen als Ganzes betrachtet werden soll. Wenn beispielsweise ein Datums-Widget, das aus einem Tag, einem Monat und einem Jahr besteht, aria-live=true und aria-atomic=true enthält 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 (Standardwert) 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 (Ergänzungen) bedeutet, dass jedes Element, das der Live-Region hinzugefügt wird, wichtig ist. Wenn Sie beispielsweise einen Span an ein bestehendes Log mit Statusnachrichten anhängen, wird der Span dem Nutzer mitgeteilt (vorausgesetzt, aria-atomic ist false).
• text, was bedeutet, dass der Textinhalt, der einem nachfolgenden Knoten hinzugefügt wird, relevant ist. Wenn Sie beispielsweise die Eigenschaft textContent eines benutzerdefinierten Textfelds ändern, wird dem Nutzer der geänderte Text angezeigt.
• Removals bedeutet, dass das Entfernen von Text oder untergeordneten Knoten dem Nutzer mitgeteilt werden sollte.
• all, was bedeutet, dass alle Änderungen relevant sind. Der Standardwert für aria-relevant ist jedoch additions text. Wenn Sie aria-relevant nicht angeben, wird der Nutzer für jede Ergänzung des Elements aktualisiert, was höchstwahrscheinlich der Fall ist.

Schließlich können Sie mit aria-busy Hilfstechnologien darüber informieren, dass Änderungen an einem Element, z. B. beim Laden von Elementen, vorübergehend ignoriert werden sollen. Sobald alles eingerichtet ist, sollte aria-busy auf „false“ gesetzt werden, um die Funktionsweise des Lesegeräts zu normalisieren.