Ungültige ARIA-Attribute: Wenn der Versuch zu helfen alles schlimmer macht

ARIA (Accessible Rich Internet Applications)-Attribute existieren, um Lücken zu füllen, die natives HTML allein nicht abdecken kann – sie beschreiben die Rolle, den Zustand oder die Beziehungen eines benutzerdefinierten Widgets gegenüber assistiver Technologie. Sie sind gerade deshalb mächtig, weil Browser und Screenreader ihnen vollständig vertrauen: aria-expanded="true" wird für bare Münze genommen, ob es nun tatsächlich zutrifft oder nicht. Genau dieses Vertrauen macht ungültiges ARIA so schädlich – ein Tippfehler bewirkt nicht einfach nichts, er kann aktiv falsch informieren.

Dies fällt unter WCAG-Erfolgskriterium 4.1.2 (Name, Rolle, Wert), Stufe A.

Die drei Arten, wie ARIA versagt

Ungültige Attributnamen – ein Tippfehler wie aria-lable statt aria-label ist überhaupt kein erkanntes ARIA-Attribut. Browser und Screenreader ignorieren nicht erkannte Attribute stillschweigend, sodass sich das Element genauso verhält, als wäre gar keine Beschriftung angegeben worden.

<!-- Wird stillschweigend ignoriert – kein echtes ARIA-Attribut -->
<button aria-lable="Schließen">×</button>

<!-- Korrekt -->
<button aria-label="Schließen">×</button>

Ungültige Attributwerte – aria-expanded akzeptiert nur "true" oder "false"; ein Wert wie aria-expanded="yes" scheitert an der Validierung und wird behandelt, als wäre das Attribut nicht gesetzt.

<!-- Ungültiger Wert -->
<button aria-expanded="yes">Menü</button>

<!-- Korrekt -->
<button aria-expanded="false">Menü</button>

Ungültige oder missbrauchte Rollen – die Zuweisung eines role-Werts, der in der WAI-ARIA-Spezifikation nicht existiert, oder einer Rolle, die Attribute erfordert, die Sie nicht bereitgestellt haben. role="tab" etwa wird erwartet, innerhalb eines role="tablist"-Containers zu liegen und benötigt typischerweise aria-selected – es eigenständig ohne diesen Kontext zu verwenden, lässt assistive Technologie außerstande, sich ein kohärentes Bild des Widgets zu machen.

<!-- Unvollständig: ein Tab benötigt erforderliche Attribute und den richtigen Kontext -->
<div role="tab">Einstellungen</div>

<!-- Vollständig -->
<div role="tablist">
  <div role="tab" aria-selected="true" id="tab-1">Einstellungen</div>
</div>

Wie man dies zuverlässig erkennt

Anders als viele Barrierefreiheitsprobleme ist ungültiges ARIA nahezu 100 % automatisierbar – die WAI-ARIA-Spezifikation definiert eine exakte, endliche Liste gültiger Attribute, gültiger Werte pro Attribut und gültiger Rollen, sodass ein Scanner die Syntax mit Sicherheit prüfen kann. Wenn Sie ARIA von Hand schreiben, gleichen Sie mit der tatsächlichen Spezifikation ab (oder den Widget-Mustern im WAI-ARIA Authoring Practices Guide), statt Attributnamen aus dem Gedächtnis zu raten – dies ist einer der wenigen Bereiche der Barrierefreiheit, in dem es eine strikt richtige Antwort gibt, keine Ermessensfrage.

Das größere Bild: "Kein ARIA ist besser als schlechtes ARIA"

Dies ist die zweite Hälfte der bekannten ersten Regel von ARIA (die erste Hälfte lautet "Verwenden Sie kein ARIA, wenn natives HTML den Job bereits erledigt"). Ein <div> mit kaputtem role="button" und ohne Tastaturbehandlung ist für einen Screenreader-Nutzer oft schlechter als ein einfaches, ungestyltes <div> – das kaputte ARIA kündigt aktiv "das ist eine Schaltfläche" für etwas an, das sich nicht wie eine verhält, und erzeugt eine verwirrende Diskrepanz zwischen dem, was angekündigt wird, und dem, was tatsächlich passiert.

Offizielle Referenzen

• Deque University: aria-hidden-focus
• Deque University: aria-required-attr
• Deque University: aria-roles
• Deque University: aria-valid-attr
• Deque University: aria-valid-attr-value