7.2 Responsible ARIA: The 5 Rules of ARIA Use in HTML
Homepages with ARIA present averaged 70% more detected errors than those without ARIA. (2022 WebAIM One Million Survey)
Wenn ARIA nicht richtig verwendet wird, führt das zu mehr Verwirrung für den User und kann Barrieren noch verstärken. Die Using ARIA-Leitfaden der W3C WAI gibt Hilfestellung zur richtigen Verwendung von ARIA in HTML.
Relevante Success Criteria
- SC 2.1.1 Keyboard (Level A) – Regel 3
- All functionality of the content is operable through a keyboard interface without requiring specific timings for individual keystrokes, except where the underlying function requires input that depends on ths path of the user's movement and not just the endpoints.
- SC 2.1.3 Keyboard (No Exception)(Level AAA) – Regel 3
- All functionality of the content is operable through a keyboard interface without requiring specific timings for individual keystrokes.
The first rule of ARIA Use
If you can use a native HTML element or attribute with the semantics and behaviour you require already built in, instead of re-purposing an element and adding ARIA role, state or property to make it accessible, then do so.
Wenn die Funktion, die du nutzen möchtest, in HTML bereits existiert, verwende kein ARIA.
Ausnahmen:
- Wenn die benötigte Funktion in HTML zwar existiert, aber diese nicht implementiert ist oder Accessibility nicht unterstützt wird (z.B.
<dialog>) - Wenn die Designvorgaben nicht erlauben, ein natives HTML-Element zu verwenden, dann kann ARIA verwendet werden, aber nur, wenn es unbedingt sein muss. Wenn möglich, vermeiden. Besser wäre, das Desing Pattern zu vereinfachen bzw. zu verändern.
- Wenn die Funktion in HTML nicht verfügbar ist (z.B. Tabs)
Zusammengefasst: Ziehe semantisches HTML vor, wann immer es geht, und greife nur auf ARIA zurück, wenn es unbedingt sein muss. ARIA ist nur ein Backup, ein Polyfill.
The second Rule of ARIA Use
Do not change native semantics unless you really have to.
<!-- falsch - semantische Bedeutung von h2 geht verloren -->
<h2 role="tab">Tab panel title</h2>
<!-- richtig - semantische Bedeutung von h2 bleibt erhalten -->
<div role="tab"><h2>Tab panel title</h2></div> Accordeon: statt eine Überschrift zu einem Button zu machen, sollte ein Button innerhalb der Überschrift verwendet werden.
Ausnahmen:
- Native HTML-Elemente mit ähnlicher Semantik wie die ARIA-Rolle können als Fallback verwendet werden, z.B. HTML Listenelemente für das Skelett eines ARIA-enabled, scripted tree widgets. Das bedeutet, JavaScript kann verwendet werden, um ARIA Rollen und Verhalten zu semantisch bedeutsamen Elementen hinzuzufügen, um die Interaktivität der Elemente noch zu verbessern.
The third Rule of ARIA Use
Alle interaktiven Elemente müssen mit der Tastatur bedienbar sein.
Wenn ein klickbares/tabbares/drag- and dropbares/slide- oder scrollbares Widget erstellt wird, muss der Benutzer dieses auch mit der Tastatur erreichen und äquivalente Aktionen mit der Tastatur ausführen können.
Alle interaktiven Widgets müssen so programmiert sein, dass sie auf Standard-Tastaturbefehle oder Tastenkombinationen reagieren.
The fourth Rule of ARIA Use
Do not use role="presentation" or aria-hidden="true" on a focusable element. Using either of these on a focusable element will result in some users focusing on 'nothing'.
ARIA Rollen fügen kein interaktives Verhalten hinzu, sie nehmen es aber auch nicht weg:
<button aria-hidden="true">Do something</button> Dieser Button wird vom Screenreadern nicht mehr vorgelesen, weil er im accTree nicht mehr angezeigt wird; im DOM ist er aber noch vorhanden und er ist interaktiv, kann also getabbt/fokussiert werden. Das führt zu maximaler Verwirrung bzw. schlechter UX. Screen-Reader-User »sehen« ein interaktives Element, wissen aber nicht, wie es heißt oder was es tut. Das gilt auch, wenn ein Elternelement des Buttons versteckt wird.
<a href="..." role="presentation">Go somewhere</a> Dieser Link wird von Screenreadern nicht mehr als Link vorgelesen, weil die Link-Semantik durch die Rolle "Präsentation" unterdrückt wird. Der Unterschied zum vorhergehenden Beispiel ist, dass der Screenreader den Linkinhalt sieht, aber nicht den Link an sich.
The fifth Rule of ARIA Use
All interactive elements must have an accessible name.
Additional notes using ARIA
Redundant ARIA
ARIA fügt den meisten nativen HTML-Elementen keine sinnvolle Semantik hinzu, weil die meisten Elemente implizite ARIA Rollen haben. Der Browser behandelt sie also so, als ob sie eine ARIA Rolle hätten.
Adding explicit roles to elements that implicitly map to those roles is redundant and a waste of time.
Und nochmal:
No ARIA is better than Bad ARIA
A Role is a promise
Auf gut deutsch: du hast eine Verantwortung. Wenn ein Element eine Rolle hat, muss es sich auch der Rolle entsprechend verhalten. Dieses Versprechen ist ein verbindlicher Vertrag. Wenn es gebrochen wird, kann es sein, dass man Barrieren errichtet, nicht abbaut.
Im Vorfeld überlegen: Was verspreche ich dem User? Kann ich das Versprechen halten?
ARIA is only a polyfill for HTML semantics
Polyfills sind ein letzter Ausweg, nichts, was standardmäßig verwendet werden sollte.
Wenn ARIA verwendet wird:
- sei dir im Klaren darüber, was die Attribute machen oder nicht machen
- folge den Regeln für ARIA in HTML
- implementiere das nötige Accessibility Verhalten wo es gebraucht wird
- teste, teste, teste die Komponenten in verschiedenen Browsern und AT-Kombinationen
- vorzugsweise sollten die Komponenten von disabled AT Usern auf ihre Usability getestet werden
Use ARIA responsibly