Barrierefreiheit (Accessibility) im Web bedeutet, dass alle Menschen eine Webseite nutzen können – unabhängig von körperlichen oder technischen Einschränkungen. Dazu gehören z. B. blinde Nutzer:innen mit Screenreadern, Menschen mit motorischen Einschränkungen oder Nutzer:innen, die ausschließlich per Tastatur navigieren.

HTML bringt bereits viele Accessibility-Funktionen mit. ARIA (Accessible Rich Internet Applications) ergänzt HTML dort, wo native Elemente nicht ausreichen – aber nur dann.

Merksatz:
👉 Nutze zuerst sauberes HTML. Verwende ARIA nur, wenn es wirklich nötig ist.

1. Was ist ARIA überhaupt?

ARIA ist eine Sammlung von Attributen, die zusätzliche Informationen für assistive Technologien (z. B. Screenreader) bereitstellen.

ARIA hilft Screenreadern zu verstehen:

  • Was ein Element ist (Rolle)
  • Wie es sich verhält (Zustand)
  • Was es bedeutet (Beschreibung)

ARIA besteht im Wesentlichen aus drei Bausteinen:

Kategorie Beschreibung
Roles Was ist dieses Element?
States In welchem Zustand ist es gerade?
Properties Welche zusätzlichen Infos gibt es?

2. Die goldenen ARIA-Regeln (sehr wichtig!)

Bevor wir zu den Attributen kommen, hier die wichtigsten Grundregeln:

✅ Regel 1: Verwende natives HTML, wann immer möglich

<button>Speichern</button>

❌ Schlechter:

<div role="button">Speichern</div>

HTML-Buttons sind automatisch:

  • fokussierbar
  • per Tastatur bedienbar
  • korrekt für Screenreader

ARIA kann das nicht vollständig ersetzen.

✅ Regel 2: Keine ARIA-Attribute ohne Funktion

ARIA verändert nicht das Verhalten eines Elements – nur dessen Bedeutung.

<div role="button">Klick mich</div>

➡️ Das ist kein echter Button, wenn kein JavaScript dahinter hängt.

✅ Regel 3: Falsches ARIA ist schlimmer als kein ARIA

Ein falsch gesetztes Attribut kann Screenreader komplett verwirren.

3. ARIA Roles – was ist dieses Element?

ARIA-Roles beschreiben die semantische Bedeutung eines Elements.

Häufige Rollen

role="button"

Nur verwenden, wenn kein <button> möglich ist.

<div role="button" tabindex="0">Mehr anzeigen</div>

⚠️ Wichtig:

  • tabindex="0" macht das Element fokussierbar
  • Tastatur-Events (Enter, Space) müssen per JS umgesetzt werden

role="navigation"

Kennzeichnet einen Navigationsbereich.

<nav role="navigation">
  <ul>
    <li><a href="/">Start</a></li>
  </ul>
</nav>

➡️ Hinweis: <nav> hat diese Rolle bereits automatisch – role ist hier optional.

role="dialog"

Für modale Fenster / Popups.

<div role="dialog" aria-modal="true">
  <h2 id="dialog-title">Einstellungen</h2>
</div>

4. ARIA States – aktueller Zustand eines Elements

States ändern sich dynamisch und werden von Screenreadern live angesagt.

aria-expanded

Unverzichtbar für Dropdowns & Akkordeons.

<button aria-expanded="false">
  Menü öffnen
</button>

Nach dem Öffnen:

<button aria-expanded="true">
  Menü schließen
</button>

➡️ Screenreader:
„Menü öffnen, eingeklappt“ / „… ausgeklappt“

aria-checked

Für Custom-Checkboxen oder Switches.

<div role="checkbox" aria-checked="false" tabindex="0">
  Newsletter abonnieren
</div>

aria-disabled

Wenn etwas sichtbar, aber nicht nutzbar ist.

<button aria-disabled="true">
  Absenden
</button>

⚠️ Nicht dasselbe wie disabled – Verhalten muss selbst umgesetzt werden.

5. ARIA Properties – Beschreibungen & Beziehungen

aria-label

Gibt einem Element einen sprechenden Namen, wenn kein Text vorhanden ist.

<button aria-label="Suche starten">
  🔍
</button>

➡️ Screenreader liest: „Suche starten“

aria-labelledby

Verknüpft ein Element mit einer sichtbaren Beschriftung.

<h2 id="profile-heading">Profil</h2>

<section aria-labelledby="profile-heading">
  ...
</section>

➡️ Besser als aria-label, weil sichtbarer Text genutzt wird.

aria-describedby

Für zusätzliche Hinweise oder Fehlermeldungen.

<input id="email" type="email" aria-describedby="email-help">

<p id="email-help">
  Bitte geben Sie eine gültige E-Mail-Adresse ein.
</p>

➡️ Screenreader liest Label + Erklärung

aria-hidden

Blendet Inhalte nur für Screenreader aus.

<span aria-hidden="true">★</span>

⚠️ Vorsicht:

  • Nicht verwenden, um wichtige Inhalte zu verstecken
  • Nicht auf fokussierbare Elemente anwenden

6. Attribute, die man unbedingt kennen (und nutzen) sollte

🔴 Pflicht bei interaktiven Custom-Elementen

  • role
  • tabindex
  • passende aria-* States

🟢 Sehr häufig & wichtig

  • aria-label
  • aria-labelledby
  • aria-describedby
  • aria-expanded

🟡 Nur bei Bedarf

  • aria-hidden
  • aria-live
  • aria-disabled

7. Typische Fehler (bitte vermeiden 🙏)

❌ ARIA auf alles werfen „zur Sicherheit“
❌ Native HTML-Semantik überschreiben
❌ aria-label und sichtbaren Text doppeln
❌ Fokus-Management vergessen (Tab-Reihenfolge!)

8. Fazit

ARIA ist ein mächtiges Werkzeug, aber kein Ersatz für sauberes HTML.

Die beste Barrierefreiheit erreichst du mit:

  1. Semantischem HTML
  2. Tastatur-Bedienbarkeit
  3. Sinnvollem, gezieltem Einsatz von ARIA
  4. Regelmäßigen Tests (z. B. mit Screenreader oder Lighthouse)

💡 Faustregel:
Kein ARIA ist besser als falsches ARIA – aber richtig eingesetzt ist es Gold wert.