TL;DRTL;DR too long; didn't read. Wörtlich übersetzt "zu lang; nicht gelesen". Überschrift für eine kurze Zusammenfassung eines längeren Artikels oder Beitrags.
- Nutze native HTML-Elemente, wann immer möglich
- ARIA-Roles nur dort einsetzen, wo HTML nicht reicht
- Jedes interaktive Element braucht einen Accessible Name
- Landmarks helfen bei Orientierung – aber nur sauber eingesetzt
- Falsches ARIA ist schlimmer als gar keins
ARIA ist eines der meistmissverstandenen Werkzeuge im Frontend. Viele Entwickler wissen, dass es ARIA-Roles, Labels und Landmarks gibt – aber nicht immer wann und warum man sie einsetzen sollte. Das Ergebnis sind Interfaces, die technisch „barrierefrei aussehen“, praktisch aber schlechter bedienbar sind als vorher.
Die wichtigste Grundregel: Native HTML schlägt ARIA
Ein <button> ist immer besser als ein <div role="button">
- Browser kennen das Element
- ScreenreaderScreenreader Software, die Texte am Bildschirm laut vorliest oder als Braille ausgibt. wissen, wie es sich verhält
- Tastaturbedienung ist automatisch dabei
ARIA kann SemantikSemantik Bedeutungsvolle HTML-Struktur, z. B. korrekt verwendete Überschriften, Listen und Abschnitte. Hilft Screenreadern, die Seite zu verstehen und kommt auch Suchmaschinen zugute. hinzufügen, aber keine Funktionalität ersetzen.
1. ARIA Roles: Sag dem Browser, was es ist
Eine ARIA-Role (oder kurz role) beschreibt die Funktion eines Elements auf der Seite. Es teilt dem Browser mit, welche Art von UI-Element es ist und wie es sich verhalten soll: Button, Dialog, Navigation, Alert usw.
Wann Roles sinnvoll sind
- Bei Custom Components, die es in HTML nicht gibt
(z. B. komplexe Comboboxen, Tabs, modale Dialoge) - Wenn ein natives Element semantisch nicht passt
Wann nicht
- Wenn es bereits ein passendes HTML-Element gibt
- Wenn du nur „auf Nummer sicher gehen“ willst
Schlechtes Beispiel:
<nav role="navigation">Besser:
<nav>nav hat die Rolle bereits eingebaut. Die explizite Role ist redundant – und Redundanz ist bei Accessibility fast immer schlecht.
role="button": Macht aus einem div einen Button für den Screenreader. Denk dran, du musst dann auch die Tastaturinteraktion selbst implementieren (z.B. mit der Enter-Taste)!
role="checkbox": Definiert eine Checkbox. Hier kommt aria-checked ins Spiel, um den Status (aktiviert/deaktiviert) zu übermitteln.
2. ARIA Labels: Gib deinem Element einen Namen
Ein Screenreader kann ein Bild nicht „sehen“. Er braucht einen beschreibenden Text. Gleiches gilt für viele interaktive Elemente. Hier kommen ARIA-Labels ins Spiel.
ARIA-Labels liefern zugängliche Namen für Elemente, die keinen sichtbaren oder ausreichenden Textinhalt haben. Es gibt verschiedene Arten:
aria-label: Bietet eine direkte Textbeschreibung für ein Element, wenn kein sichtbarer Text vorhanden ist oder dieser nicht ausreicht.
<button aria-label="Suche starten">
<img src="search-icon.svg" alt="">
</button>Der Screenreader liest hier „Suche starten“ vor, auch wenn nur ein Icon sichtbar ist.
aria-labelledby: Verweist auf ein anderes Element auf der Seite, dessen Text als Label dienen soll. Das ist praktisch, wenn ein Label für mehrere Elemente verwendet wird oder wenn das Label schon woanders im DOM existiert.
<h2 id="section-title">Meine Sektion</h2>
<div role="region" aria-labelledby="section-title"></div>Der Screenreader würde die Region mit dem Label „Meine Sektion“ ankündigen.
aria-describedby: Bietet eine erweiterte Beschreibung oder zusätzliche Informationen für ein Element. Im Gegensatz zu aria-label ist aria-describedby für ergänzende Details gedacht, die nach dem Label vorgelesen werden.
<input type="text" aria-describedby="password-help">
<p id="password-help">Dein Passwort muss mindestens 8 Zeichen lang sein.</p>Auch hier gilt natürlich: Native HTML-Elemente sind immer besser. Aber auch dabei gibt es Unterschiede:
<input type="text" placeholder="E-Mail">Der Placeholder ist kein Label. Er verschwindet beim Tippen und wird oft nicht zuverlässig vorgelesen.
Besser:
<label for="email">E-Mail</label>
<input id="email" type="email">3. ARIA Landmarks: Navigationspunkte für Screenreader
Stell dir eine Webseite wie ein großes Buch vor. Ohne Landmarks wäre es, als würde man dieses Buch ohne Inhaltsverzeichnis oder Kapitelüberschriften lesen.
ARIA-Landmarks definieren große, wichtige Bereiche deiner Webseite (Header, Navigation, Hauptinhalt, Footer etc.). Sie ermöglichen es Screenreader-Nutzern, schnell zwischen diesen Bereichen zu navigieren.
Auch hier gilt: Semantisches HTML ist der König! Elemente wie <header>, <nav>, <main>, <aside>, <article> und <footer> sind von Natur aus bereits Landmarks. Wenn du diese korrekt verwendest, brauchst du oft keine zusätzlichen role-Attribute.
Beispiel:
<header role="banner">...</header>
<nav role="navigation">...</nav>
<main role="main">...</main>
<aside role="complementary">...</aside>
<footer role="contentinfo">...</footer>
In diesem Fall sind die role-Attribute redundant, da die HTML5-Elemente die Semantik bereits liefern. Nur wenn du älteres HTML verwendest (z.B. divs statt <main>), sind die Rollen explizit nötig.
Eine gute Übersicht über Landmark Roles und ihre Verwendung findest du auch hier: W3C WAI-ARIA Authoring Practices Guide – Using WAI-ARIA Landmarks.
Wichtige Regeln
- Nur ein
<main>pro Seite - Landmarks sollten inhaltlich eindeutig sein
- Mehrere
<nav>→ mitaria-labelunterscheiden
<nav aria-label="Hauptnavigation">
<nav aria-label="Footer-Navigation">
Ohne Label hören Screenreader-Nutzer nur:
„Navigation, Navigation, Navigation.“
Häufige Fehler:
role="button"ohne Tastatur-Handlingaria-hidden="true"auf fokussierbaren Elementenaria-labelund sichtbarer Text mit anderem Inhalt- ARIA-Roles, die der HTML-Semantik widersprechen
ARIA kann Barrieren abbauen – oder neue schaffen, wenn man es falsch einsetzt.