Bevor wir uns mit den Regeln von ARIA befassen, wollen wir noch einmal zusammenfassen, was ARIA leistet. ARIA steht für „Accessible Rich Internet Applications“ und trägt dazu bei, Webinhalte oder Webanwendungen für Menschen mit Behinderungen besser zugänglich zu machen. Es ist insbesondere bei dynamischen Inhalten und komplexen Bedienelementen der Benutzeroberfläche hilfreich, die mit Ajax, HTML, JavaScript und verwandten Technologien entwickelt wurden. Mit WAI-ARIA können Entwickler komplexe Webanwendungen für Menschen mit Behinderungen zugänglich und nutzbar machen.
Obwohl ARIA bereits vor Jahren entwickelt wurde, wenden einige Entwickler ARIA aufgrund mangelnder fundierter Kenntnisse zu diesem Thema immer noch falsch an. Eine falsche Anwendung von ARIA führt zu einer deutlich schlechteren Barrierefreiheit als wenn Entwickler ARIA gar nicht verwenden. Das ist der Grund für die weit verbreitete Redensart: „Kein ARIA ist besser als schlechtes ARIA.“ Dennoch sollten Entwickler versuchen, die Regeln von ARIA zu verstehen und zu befolgen, um Menschen mit Behinderungen eine barrierefreiere Nutzung zu ermöglichen. Sehen wir uns die Regeln von ARIA im Folgenden genauer an.
Regel Nr. 1: Verwende kein ARIA, sondern stattdessen natives HTML
Bevor Sie ARIA verwenden, sollten Sie zunächst native HTML-Elemente oder -Attribute nutzen. Falls die von Ihnen gewünschte Semantik in HTML nicht verfügbar ist, sollten Sie ARIA verwenden.
Let me explain this with the example. To construct the checkbox on a web page, use HTML checkbox (<input type=”checkbox”>) rather than ARIA checkbox (<div role=”checkbox”>…</div>). The reason for this is that HTML checkbox conveys the semantics to people using assistive technology (such as screen readers) without any additional effort because it is already mapped to the accessibility APIs.
Nun stellt sich die Frage, wann ARIA eingesetzt werden sollte. Es gibt einige Szenarien, in denen wir möglicherweise auf ARIA zurückgreifen müssen, zum Beispiel:
- Wenn die Website nicht von Grund auf neu entwickelt wurde und nachträglich barrierefrei gestaltet wird. In diesem Fall ist es besser, ARIA zu verwenden, um Zeit, Aufwand und Geld zu sparen.
- Wenn es nicht möglich ist, das native Element zu stylen (Ausnahmefälle), ist es in Ordnung, das benutzerdefinierte Element zu erstellen, es zu stylen und ihm mithilfe von ARIA Semantik zuzuweisen.
- Falls die erforderliche Semantik in der Host-Sprache (HTML 5.x) nicht vorhanden ist, sollte ARIA verwendet werden, um die Semantik zu vermitteln. Beispielsweise muss ARIA eingesetzt werden, um die Baumstruktur zu vermitteln, da es kein entsprechendes HTML-Element oder -Attribut gibt.
- Wenn die Unterstützung bestimmter HTML 5.x-Funktionen durch den User-Agent nicht verfügbar ist, verwenden Sie ARIA.
Regel Nr. 2: Ändere die native Semantik nicht, es sei denn, du musst es wirklich, wirklich tun
Wie bereits erwähnt, vermitteln die meisten HTML-Elemente oder -Attribute die eine oder andere Semantik. Wir sollten die native Semantik nicht ändern, es sei denn, dies ist wirklich unerlässlich. Ein Beispiel hierfür wäre, wenn ein Entwickler eine Überschrift erstellen möchte, die gleichzeitig eine Registerkarte ist:
Tu das nicht:
<h2 role=tab>heading tab</h2>
Befolgen Sie stattdessen diese bewährte Vorgehensweise:
<div role=tab><h2>heading tab</h2></div>
Regel Nr. 3: Alle interaktiven ARIA-Steuerelemente müssen über die Tastatur bedienbar sein
Die Angabe der ARIA-Rollen würde dem benutzerdefinierten Steuerelement zwar Semantik verleihen, aber es würde niemals dazu führen, dass das Steuerelement mit der Tastatur wie erwartet funktioniert. Wir müssen bedenken, dass ARIA nichts mit der Tastaturfunktionalität zu tun hat, sondern vielmehr die Semantik für die Barrierefreiheits-APIs bereitstellt.
That being said it is the developer’s responsibility to make the custom control accessible with the keyboard by using some scripting. For example, if we construct the custom button(<div role=”button”>) then we need to make sure that it receives the focus and the user is able to activate the associated functionality by using both enter and space keys. To put it in simpler terms, the custom button should work with the keyboard as to how a native button works.
Regel Nr. 4: Verwenden Sie bei einem fokussierbaren Element nicht „role=“presentation““ oder „aria-hidden=“true““.
„role=“presentation““ oder „role=“none““ dient dazu, die Semantik aus dem Barrierefreiheitsbaum auszuschließen, und ein Element mit „role=“none““ soll in keiner Weise interaktiv sein. In ähnlicher Weise dient das Attribut „ARIA-hidden“ dazu, den Inhalt oder das Element vor den Barrierefreiheits-APIs zu verbergen, und ein Element, bei dem „ARIA-hidden“ auf „true“ gesetzt ist, soll in keiner Weise interaktiv sein. Wird eines dieser Attribute für sichtbare, fokussierbare Elemente definiert, führt dies dazu, dass manche Nutzer auf nichts den Fokus setzen können.
Tu das nicht:
<button role=presentation>press me</button>
Das solltest du auch nicht tun:
<button aria-hidden="true">press me</button>
Befolgen Sie stattdessen diese bewährte Vorgehensweise:
<button role="presentation" tabindex="-1">Don't Click Me</button> <button style="display: none;">Don't Click Me</button>
Regel Nr. 5: Alle interaktiven Elemente müssen einen barrierefreien Namen haben
Alle interaktiven Elemente (wie Links, Schaltflächen, Textfelder, Auswahllisten, Optionsfelder, Kontrollkästchen usw.) auf einer Webseite müssen über einen barrierefreien Namen verfügen. Ohne einen barrierefreien Namen können assistive Technologien nicht erkennen, wozu das Steuerelement dient. Zur Angabe des barrierefreien Namens stehen verschiedene Techniken zur Verfügung, die je nach Steuerelement variieren. Sehen wir uns einige davon an.
-
- HTML-Links und Schaltflächen: Unabhängig davon, welchen Linktext bzw. Schaltflächenwert wir angeben, wird dieser zum barrierefreien Namen.
- Eingabefelder: Um den barrierefreien Namen bereitzustellen, müssen Formularsteuerelemente entweder implizit oder explizit mit ihrer sichtbaren Beschriftung verknüpft werden.
- Benutzerdefinierte Widgets: Um den barrierefreien Namen für benutzerdefinierte Widgets bereitzustellen, können Autoren entweder die ARIA-label- oder die ARIA-labelledby-Technik verwenden.
Beispiel:
Das untenstehende Eingabefeld verfügt über eine sichtbare Beschriftung, es gibt jedoch keinen barrierefreien Namen:
First name<input type=”text”>
Das untenstehende Eingabefeld verfügt sowohl über eine sichtbare Beschriftung als auch über einen barrierefreien Namen. Der/die barrierefreie(n) Name(n) stellen die ID-Zuordnung her:
<label for=”fname”>First name</label> <input type=”text” id=”fname”>
Zusammenfassung
Wenn Autoren ARIA einsetzen, um die Barrierefreiheit von Steuerelementen bzw. Widgets zu verbessern, müssen die ARIA-Regeln eingehalten werden. Die Nichtbeachtung der ARIA-Regeln bei der Verwendung von ARIA kann zu schwerwiegenden Problemen hinsichtlich der Barrierefreiheit führen. Daher empfehlen wir Autoren nachdrücklich, die ARIA-Regeln bei der Verwendung von ARIA für alle Steuerelemente einzuhalten, um das Web für alle Nutzer, einschließlich Menschen mit Behinderungen, zugänglicher zu machen.
Quellenangaben: Verwendung von ARIA – W3C
