Einführung in ARIA und nicht native HTML-Semantik
Bisher haben wir die Verwendung nativer HTML-Elemente empfohlen, weil sie Ihnen Fokus, Tastaturunterstützung und integrierte Semantik bieten. Es gibt jedoch Situationen, in denen ein einfaches Layout und natives HTML nicht ausreicht. Für ein sehr gängiges UI-Konstrukt, nämlich das Pop-up-Menü, gibt es aktuell kein standardisiertes HTML-Element. Es gibt auch kein HTML-Element mit semantischem Merkmal wie z. B. „Der Nutzer muss so schnell wie möglich darüber Bescheid wissen“.
In dieser Lektion erfahren Sie, wie Sie eine Semantik ausdrücken, die HTML nicht allein ausdrücken kann.
Die „Accessible Rich Internet Applications“-Spezifikation der Web Accessibility Initiative (WAI-ARIA oder einfach ARIA) eignet sich, um Bereiche mit Bedienungshilfen zu schließen, die nicht mit nativem HTML verwaltet werden können. Dabei können Sie Attribute angeben, die beeinflussen, wie ein Element in den Baum für Barrierefreiheit übersetzt wird. Sehen wir uns ein Beispiel an.
Im folgenden Snippet verwenden wir ein Listenelement als eine Art benutzerdefiniertes Kästchen. Die CSS-Klasse „Kästchen“ verleiht dem Element die erforderlichen visuellen Eigenschaften.
<li tabindex="0" class="checkbox" checked>
Receive promotional offers
</li>
Dies funktioniert zwar für sehende Nutzer problemlos, ein Screenreader gibt jedoch keinen Hinweis darauf, dass das Element als Kästchen dient, sodass Nutzer mit eingeschränktem Sehvermögen es möglicherweise ganz übersehen können.
Mithilfe von ARIA-Attributen können wir dem Element jedoch die fehlenden Informationen geben, damit der Screenreader sie richtig interpretieren kann. Hier haben wir die Attribute role und aria-checked hinzugefügt, um das Element explizit als Kästchen zu kennzeichnen und anzugeben, dass es standardmäßig aktiviert ist. Der Listeneintrag wird nun dem Baum für Barrierefreiheit
hinzugefügt und ein Screenreader meldet korrekt als Kästchen.
<li tabindex="0" class="checkbox" role="checkbox" checked aria-checked="true">
Receive promotional offers
</li>
Bei ARIA wird die standardmäßige DOM-Zugriffsstruktur geändert und erweitert.
Mit ARIA können wir den Baum für die Barrierefreiheit für jedes Element auf der Seite subtil (oder sogar radikal) ändern, aber das ist das Einzige, was sich ändert. ARIA verbessert nicht das inhärente Verhalten des Elements. Das Element wird dadurch nicht fokussierbar und ihm werden auch keine Tastaturereignis-Listener zugewiesen. Das ist immer noch Teil unserer Entwicklungsaufgabe.
Es ist wichtig zu verstehen, dass die Standardsemantik nicht neu definiert werden muss. Unabhängig von seiner Verwendung benötigt ein Standard-HTML-<input type="checkbox">-Element kein zusätzliches role="checkbox"-ARIA-Attribut, um richtig angesagt zu werden.
Für bestimmte HTML-Elemente gelten Einschränkungen im Hinblick darauf, welche ARIA-Rollen und -Attribute dafür verwendet werden können. Beispielsweise darf auf ein Standard-<input
type="text">-Element keine zusätzliche Rolle bzw. kein zusätzliches Attribut angewendet werden.
Weitere Informationen finden Sie unter ARIA in HTML-Spezifikation.
Sehen wir uns an, welche weiteren Funktionen ARIA zu bieten hat.
Was kann ARIA tun?
Wie Sie am Beispiel des Kästchens gesehen haben, kann ARIA die vorhandene Elementsemantik ändern oder Elemente ohne native Semantik eine Semantik hinzufügen. Sie kann auch semantische Muster ausdrücken, die in HTML überhaupt nicht vorhanden sind, z. B. ein Menü oder ein Tabbereich. Häufig lässt sich mit ARIA Widget-Elemente erstellen, die mit einfachem HTML nicht möglich wären.
- ARIA kann beispielsweise zusätzliche Labels und Beschreibungen hinzufügen, die nur für APIs von Hilfstechnologien verwendet werden.
<button aria-label="screen reader only label"></button>
- ARIA kann semantische Beziehungen zwischen Elementen ausdrücken, die die standardmäßige über-/untergeordnete Verbindung erweitern, z. B. eine benutzerdefinierte Bildlaufleiste, die eine bestimmte Region steuert.
<div role="scrollbar" aria-controls="main"></div>
<div id="main">
. . .
</div>
- Und ARIA kann Teile der Seite „live“ machen, sodass sie sofort die unterstützende Technologie informieren, wenn sie sich ändern.
<div aria-live="polite">
<span>GOOG: $400</span>
</div>
Einer der Kernaspekte des ARIA-Systems ist die Sammlung von Rollen. Eine Rolle im Hinblick auf die Barrierefreiheit entspricht einer Kurzschreibweise für ein bestimmtes UI-Muster. ARIA stellt ein Vokabular von Mustern zur Verfügung, das wir über das Attribut role für jedes HTML-Element verwenden können.
Als wir im vorherigen Beispiel role="checkbox" angewendet haben, wurde der unterstützenden Technologie mitgeteilt, dass das Element dem Muster „Kästchen“ folgen soll. Wir garantieren, dass der Status wie bei einem standardmäßigen HTML-Kästchenelement mit der Maus oder der Leertaste umgeschaltet werden kann.
Da Tastaturinteraktionen bei der Verwendung von Screenreadern sehr häufig verwendet werden, ist es sehr wichtig, beim Erstellen eines benutzerdefinierten Widgets unbedingt darauf zu achten, dass das Attribut role immer an derselben Stelle wie das Attribut tabindex angewendet wird. Dadurch werden Tastaturereignisse an die richtige Stelle verschoben und wenn der Fokus auf einem Element liegt, wird seine Rolle korrekt vermittelt.
In der ARIA-Spezifikation wird eine Taxonomie möglicher Werte für das Attribut role und die zugehörigen ARIA-Attribute beschrieben, die in Verbindung mit diesen Rollen verwendet werden können. Dies ist die beste Quelle für definitive Informationen darüber, wie die ARIA-Rollen und -Attribute zusammenarbeiten und wie sie so verwendet werden können, dass sie von Browsern und Hilfstechnologien unterstützt werden.
Die Spezifikation ist jedoch sehr kompakt. Ein einfacherer Ausgangspunkt ist das ARIA-Dokument zu Authoring-Verfahren, in dem Best Practices für die Verwendung der verfügbaren ARIA-Rollen und -Eigenschaften beschrieben werden.
ARIA bietet auch Orientierungshilfen, die die in HTML5 verfügbaren Optionen erweitern. Weitere Informationen finden Sie in der Spezifikation zu Designmustern für Sehenswürdigkeiten.