Was ist ARIA und warum gibt es das?

ARIA steht für "Accessible Rich Internet Applications". Es ist eine technische Spezifikation des W3C und im Grunde ein Werkzeugkasten von zusätzlichen HTML-Attributen. Diese Attribute helfen dabei, Webseiten und insbesondere komplexe Web-Anwendungen für Menschen mit Behinderungen, die assistive Technologien (AT) wie Screenreader verwenden, zugänglicher und verständlicher zu machen.

ARIA schließt die Lücke, wo reines HTML an seine Grenzen stößt. Während Standard-HTML-Elemente wie <button> oder <input type="checkbox"> eine eingebaute Bedeutung (Semantik) und Bedienbarkeit haben, gilt das für generische <div>- oder <span>-Elemente, aus denen moderne UIs oft gebaut werden, nicht.

Die erste und wichtigste Regel von ARIA

Die allererste Regel, die man verinnerlichen muss, lautet: Verwende ARIA nicht, wenn du ein natives HTML-Element verwenden kannst, das die Funktionalität bereits bietet.

Ein <button>-Element ist von Natur aus per Tastatur fokussierbar und bedienbar. Ein <div>, das mit JavaScript wie ein Button aussehen und funktionieren soll (<div onclick="...">Klick mich</div>), ist es nicht. Um es zugänglich zu machen, bräuchte man <div role="button" tabindex="0">...</div> und müsste die Tastenbedienung (Enter, Leertaste) selbst implementieren. Es ist fast immer besser, einfach <button> zu verwenden.

Wann braucht man ARIA wirklich? (Praxisbeispiele)

ARIA wird dann wichtig, wenn man interaktive Komponenten baut, für die es kein einfaches HTML-Pendant gibt, oder wenn man den Zustand von Elementen dynamisch kommunizieren muss. Sie sind ein wichtiger Teil unserer BFSG-Checkliste.

• Dynamische Inhalte & Benachrichtigungen: Wenn Inhalte auf der Seite erscheinen, ohne dass die Seite neu lädt (z.B. eine Fehlermeldung, eine Erfolgsnachricht, neue Chat-Nachrichten). Mit aria-live="polite" (für nicht dringende Änderungen) oder aria-live="assertive" (für dringende Meldungen) kann man Screenreader anweisen, diese Änderungen vorzulesen.
• Komplexe Widgets und UI-Komponenten: Für Komponenten wie Karussells, Schieberegler (Slider), Tabs oder aufklappbare Menüs. Hier definieren ARIA-Rollen (z.B. role="tablist", role="tab", role="tabpanel") die Funktion und Zustands-Attribute (z.B. aria-selected="true", aria-expanded="false") den aktuellen Zustand.
• Zusätzliche Beschreibungen und Namen: Wenn die sichtbare Beschriftung nicht ausreicht oder fehlt. Ein Button, der nur ein "X"-Icon anzeigt, ist für Sehende verständlich, für Screenreader aber nicht. Mit aria-label="Schließen" gibt man ihm einen klaren, zugänglichen Namen.

Ein einfaches Beispiel: Ein Akkordeon (Aufklapp-Element)

<h3>
  <button aria-expanded="false" aria-controls="content1" id="trigger1">
    Abschnitt 1
  </button>
</h3>
<div id="content1" role="region" aria-labelledby="trigger1" hidden>
  <p>Hier ist der versteckte Inhalt von Abschnitt 1.</p>
</div>

Hier teilt ARIA dem Screenreader mit: Der Button steuert einen Bereich (aria-controls), der aktuell eingeklappt ist (aria-expanded="false"). Wenn der Nutzer den Button aktiviert, ändert sich das Attribut zu aria-expanded="true" und das hidden-Attribut wird vom Inhalt entfernt. So wird die Interaktion verständlich.

Ein falscher oder übermäßiger Einsatz von ARIA kann mehr schaden als nutzen. Unser kostenloses Analysetool prüft auf einige grundlegende ARIA-Anwendungen und hilft, potenzielle Probleme zu identifizieren, kann aber eine manuelle Prüfung komplexer Komponenten nicht ersetzen.