ARIA (Accessible Rich Internet Applications) ist eine technische Spezifikation des W3C, die Webentwicklern Attribute zur Verfügung stellt, mit denen die Barrierefreiheit dynamischer Webinhalte verbessert werden kann. ARIA ergänzt HTML um Rollen, Zustände und Eigenschaften, die Screenreadern und anderen Assistenztechnologien Informationen liefern, die im Standard HTML nicht ausgedrückt werden können.

ARIA wurde 2014 als W3C Empfehlung verabschiedet und wird kontinuierlich weiterentwickelt. Aktuelle Version 2026 ist WAI-ARIA 1.2, die Arbeit an WAI-ARIA 1.3 läuft. ARIA ist ein zentraler Baustein der digitalen Barrierefreiheit und im Kontext der WCAG 2.2 sowie des BFSG oft unverzichtbar.

Wichtig: ARIA ist kein Ersatz für semantisches HTML, sondern eine Ergänzung. Das W3C selbst formuliert die fünf goldenen Regeln, deren erste lautet: Wenn ein natives HTML Element existiert, das die gewünschte Funktion bereits liefert, sollte ARIA nicht eingesetzt werden. Diese Hierarchie zeigen wir später in der Levels Tabelle.

ARIA gehört zu den Themen, die in Beratungsprojekten am häufigsten Probleme bereiten. Falsche Rollen, kaputte aria-labelledby Verknüpfungen oder unbedienbare Custom Widgets sind die Klassiker. Wir kennen die häufigen Fehlermuster aus zahlreichen Accessibility Audits und wissen, wie ARIA Patterns aus dem WAI-ARIA Authoring Practices Guide korrekt implementiert werden.

Konkret unterstützen wir Frontend Teams beim barrierefreien Webdesign nach BFSG und WCAG 2.2. Dazu gehören ARIA Audits, Accessibility Testing mit Tools wie ANDI und axe DevTools, die Refaktorierung von Custom Components und Frontend Schulungen zu ARIA Patterns.

ARIA schließt die Lücke, die zwischen modernen Webanwendungen und den Möglichkeiten von Standard HTML besteht. Single Page Applications, Modal Dialoge, Tab Panel, Combobox Widgets oder Live Regionen lassen sich mit reinem HTML nicht vollständig barrierefrei umsetzen — hier kommt ARIA ins Spiel.

Konkret leistet ARIA folgendes:

• Rollen erweitern: Komponenten ohne native HTML Entsprechung bekommen eine semantische Rolle (z.B. role="alert", role="tabpanel").
• Zustände kommunizieren: Dynamische Zustandsänderungen werden Screenreadern mitgeteilt (aria-expanded, aria-checked, aria-busy).
• Beziehungen herstellen: Elemente werden semantisch verknüpft (aria-labelledby, aria-describedby, aria-controls).
• Live Updates ankündigen: Asynchrone Inhalte werden ohne Fokuswechsel vorgelesen (aria-live, role="status").
• Sichtbarkeit steuern: Versteckte Inhalte werden für Screenreader korrekt behandelt (aria-hidden).

Ohne ARIA sind komplexe Web Komponenten für Screenreader Nutzer oft unbedienbar. Mit ARIA — korrekt eingesetzt — werden sie zugänglich. Falsch eingesetzt verschlechtert ARIA die Barrierefreiheit jedoch oft mehr als es nützt, weshalb wir es in Accessibility Audits immer kritisch prüfen.

ARIA findet überall dort Anwendung, wo HTML allein nicht ausreicht, um den Zweck oder Zustand eines UI Elements an Assistenztechnologien zu kommunizieren. Typische Einsatzgebiete:

• Dialoge und Modals: role="dialog" oder role="alertdialog" mit aria-labelledby und aria-modal="true"
• Tab Panels: role="tablist", role="tab", role="tabpanel" mit aria-selected und aria-controls
• Combobox und Autocomplete: role="combobox" mit aria-expanded, aria-controls und aria-activedescendant
• Live Regionen: aria-live="polite" oder aria-live="assertive" für Status Updates und Fehlermeldungen
• Toggle Buttons: aria-pressed oder aria-checked für Zustandsanzeige
• Akkordeons: aria-expanded für Aufklapp Zustand, aria-controls für Verknüpfung
• Custom Controls: Slider, Spinbutton, Tree, Grid mit den entsprechenden ARIA Patterns
• Landmarks: role="banner", role="navigation", role="main", role="contentinfo" zur Strukturnavigation

Für jedes dieser Patterns existiert im offiziellen WAI-ARIA Authoring Practices Guide (APG) eine Referenzimplementierung. Wer Custom Components baut, sollte diese als Vorlage nutzen — selbst kleine Abweichungen führen zu Bugs, die mit Tools wie ANDI oder axe DevTools erst sichtbar werden.

Wann ARIA wirklich nötig ist und wann es schadet, lässt sich mit einer einfachen Klassifikation in vier Levels ausdrücken. Sie folgt der ersten goldenen Regel des W3C: Wenn ein natives HTML Element existiert, das die Funktion bereits liefert, sollte ARIA nicht eingesetzt werden. Die folgende Tabelle und die Infografik darunter zeigen die Levels mit konkreten Code Beispielen.

ARIA besteht aus drei Kategorien von Attributen: Rollen definieren was ein Element ist, Eigenschaften definieren statische Charakteristika und Zustände beschreiben dynamische Veränderungen.

Die wichtigsten ARIA Rollen:

Die wichtigsten ARIA Eigenschaften und Zustände:

Eine vollständige Referenz findet sich in der offiziellen WAI-ARIA 1.2 Specification und im praktisch orientierten WAI-ARIA Authoring Practices Guide des W3C.

Das W3C formuliert in den ARIA Authoring Practices fünf Grundregeln, die jedes Frontend Team verinnerlichen sollte. Diese Regeln verhindern die häufigsten ARIA Fehler.

1. Wenn ein natives HTML Element existiert, nutze es: button vor div role="button", nav vor div role="navigation", dialog vor div role="dialog". Native Elemente bringen Tastatur Support, Fokus Verhalten und Browser Defaults automatisch mit.
2. Native Semantik nicht ändern, außer es ist nötig: Ein h1 mit role="button" bricht die Heading Struktur. Wer einen Button braucht, nutzt ein button Element.
3. Alle interaktiven ARIA Komponenten müssen per Tastatur bedienbar sein: Wer mit ARIA einen Button baut, muss Enter und Space Handler ergänzen — das passiert nicht automatisch.
4. Nutze role="presentation" oder aria-hidden="true" nicht auf fokussierbaren Elementen: Versteckte fokussierbare Elemente verwirren Tastatur Nutzer.
5. Alle interaktiven Elemente brauchen einen Accessible Name: Buttons, Links, Form Felder müssen einen Namen haben, den Screenreader vorlesen können — über sichtbares Text Label, aria-label oder aria-labelledby.

Diese Regeln werden bei jedem Accessibility Audit systematisch geprüft. Tools wie ANDI zeigen Verstöße schnell auf.

In Accessibility Audits begegnen uns die immer gleichen ARIA Fehler. Diese Liste hilft, die häufigsten Fallen zu erkennen und zu vermeiden.

• div role="button" statt button: Der Klassiker. Bringt manuell implementiertes Tastatur Handling, Fokus Verhalten und Screenreader Ansprache mit sich, das bei nativen button kostenlos käme.
• aria-label auf nicht interaktiven Elementen: aria-label auf einem div ohne Rolle hat keine Wirkung. Screenreader lesen es nicht vor, weil das Element nicht ansprechbar ist.
• Doppelte Beschriftung: button mit sichtbarem Text und zusätzlich aria-label überschreibt den sichtbaren Text. Sehende und Screenreader Nutzer hören dann unterschiedliche Bezeichnungen.
• aria-hidden auf fokussierbaren Elementen: aria-hidden="true" auf einem button macht es für Screenreader unsichtbar — aber Tastatur Nutzer können trotzdem hinfokussieren und sind dann verloren.
• Kaputte aria-labelledby Verknüpfung: aria-labelledby verweist auf eine ID, die nicht existiert oder leer ist. Resultat: kein Accessible Name. Tools wie ANDI zeigen das sofort.
• role="button" ohne Tastatur Handler: Custom Buttons müssen Enter und Space manuell verarbeiten. Ohne diesen Code sind sie für Tastatur Nutzer unbedienbar.
• aria-live auf statischen Containern: aria-live wirkt nur auf Inhalte, die nach dem Laden geändert werden. Ein aria-live Container mit statischem Text bewirkt nichts.
• Übermaß an ARIA: Jeder div bekommt eine Rolle, jedes Element ein aria-label. Resultat: Screenreader liest sich tot und Nutzer schalten ab.

Die Prävention dieser Fehler ist Hauptgrund für strukturiertes Accessibility Testing mit Kombination aus automatisierten Tools, manuellen Reviews und Screenreader Tests.

In Beratungsprojekten setzen wir uns regelmäßig mit ARIA Implementierungen auseinander — von einfachen Modal Dialogen bis zu komplexen Custom Comboboxen mit Autocomplete. Drei Erkenntnisse haben sich dabei verfestigt:

Erstens: Die meisten ARIA Probleme entstehen aus der Annahme, ARIA mache eine Komponente automatisch barrierefrei. Tatsächlich ist ARIA nur die Beschriftung, nicht die Funktion. Tastatur Bedienung, Fokus Management und korrekte Zustandsänderung bleiben Aufgabe des JavaScript Codes. Wer das nicht weiß, baut div role="button" Komponenten, die niemand bedienen kann.

Zweitens: Der WAI-ARIA Authoring Practices Guide ist die wichtigste Referenz für Frontend Teams. Wir empfehlen, vor jedem Custom Widget zuerst dort nachzuschauen. Die offiziellen Patterns sind erprobt, dokumentiert und von der ARIA Working Group verifiziert. Eigene ARIA Konstruktionen führen fast immer zu Problemen.

Drittens: ARIA Tests gehören in jeden CI Lauf. Mit axe-core in der Pipeline werden offensichtliche Fehler — fehlende Names, kaputte Verknüpfungen, falsche Rollen — vor dem Merge gefunden. Manuelle Reviews mit Tools wie ANDI und Screenreader Tests bleiben ergänzend nötig, ersetzen aber nicht die Automatisierung.

Wer ARIA in einer komplexen Frontend Codebase aufräumen will, findet bei NCA sowohl Audits als auch konkrete Hilfe bei der BFSG Umsetzung.

Die folgenden Antworten beruhen auf der offiziellen WAI-ARIA 1.2 Spezifikation, dem WAI-ARIA Authoring Practices Guide und unserer Praxis aus Beratungsprojekten. Für vertiefende Erklärungen verlinken wir auf die passenden Artikel im NCA Glossar für Barrierefreiheit.