Icon-only Buttons
Wenn sichtbarer Text fehlt, kann ein zugänglicher Name mit aria-label oder aria-labelledby nötig sein.
Grundsatz für ARIA
Native HTML-Semantik hat Vorrang. ARIA ist vor allem dann sinnvoll, wenn vorhandene HTML-Elemente eine Anforderung nicht ausreichend abbilden oder zusätzliche Kontextinformationen nötig sind.
Wann ARIA sinnvoll ist
ARIA sollte eine konkrete LÜcke schliessen, nicht pauschal Über die gesamte OberflÄche gelegt werden.
Dynamische Statusmeldungen
Fehlermeldungen, Upload-Status oder BestÄtigungstexte brauchen oft aria-live oder role="status".
Komplexe Custom Widgets
Tabs, Dialoge oder Menüs benötigen hÄufig zusätzliche Rollen, Zustände und Beziehungen, wenn native Elemente nicht ausreichen.
Dekorative Elemente ausblenden
Rein visulle Icons oder Schmuckgrafiken können mit aria-hidden="trÜ" aus dem Accessibility Tree entfernt werden.
Wichtige ARIA-Bausteine
role
Nur setzen, wenn die native Rolle nicht ausreicht oder ein Custom Widget korrekt beschrieben werden muss.
aria-label
Hilft bei knappen oder rein ikonischen Bedienelementen, wenn kein sichtbarer Text vorhanden ist.
aria-hidden
Geeignet für rein dekorative Inhalte, aber problematisch, wenn versehentlich relevante Informationen verborgen werden.
Status- und Live-Bereiche
Sinnvoll für dynamische Meldungen, wenn Nutzer den Zustandswechsel sonst nicht mitbekommen.
Praktische ARIA Beispiele
Die Beispiele zeigen typische Einsatzfälle, in denen ARIA ein bestehendes HTML-Pattern ergänzt statt es zu ersetzen.
Icon-Button mit zugänglichem Namen
Ohne sichtbaren Text braucht der Button eine klare Benennung.
<button type="button" aria-label="Suche öffnen">
<svg aria-hidden="true" focusable="false">...</svg>
</button>Dekoratives Icon ausblenden
Das Icon ist visull hilfreich, trÄgt aber keine eigene Information.
<p>
<span aria-hidden="true">*</span>
Formular erfolgreich gesendet
</p>Statusmeldung für dynamische Inhalte
Änderungen werden Screenreader-Nutzern automatisch mitgeteilt.
<div role="status" aria-live="polite">
Profil wurde gespeichert.
</div>ARIA Anti-Patterns vermeiden
Diese Muster sehen auf den ersten Blick technisch ausgereift aus, verschlechtern aber oft Tastatur- oder Screenreader-Verhalten.
Schlecht: Div als Button
Hier fehlt native Semantik und meist auch robustes Tastaturverhalten.
<div role="button" tabindex="0" onclick="save()">
Speichern
</div>Besser: echtes Button-Element
Native HTML-Elemente liefern Fokus, TastatursteÜrung und Rolle bereits mit.
<button type="button" onclick="save()">
Speichern
</button>Problematisch: sichtbaren Text mit aria-label überschreiben
Wenn aria-label dem sichtbaren Text widerspricht, entsteht Verwirrung.
<button aria-label="Formular senden">
Jetzt kaufen
</button>Wann Sie ARIA besser vermeiden
Native Elemente sind vorhanden
Ein button braucht in der Regel kein role="button", ein nav kein role="navigation" und eine Liste kein role="list".
ARIA soll schlechtes Markup retten
Fehlende Labels, kaputte FokusfÜhrung oder falsche DOM-Struktur werden durch ARIA selten wirklich gelÖst.
State-Management ist unklar
Wer aria-expanded, aria-selected oder aria-hidden setzt, muss diese Zustände zuverlässssig synchron halten.
Nur visulle Tests wurden gemacht
Bei ARIA-Komponenten sind Tastaturtests und Screenreader-Stichproben Pflicht.
Prüffragen vor dem Einsatz
Wenn eine dieser Fragen mit Nein beantwortet wird, sollte zuerst das HTML überarbeitet werden.
Gibt es ein passendes natives Element?
Wenn ja, sollte dieses Element fast immer die erste Wahl sein.
Ist die Tastaturbedienung vollstÄndig?
Rollen ohne Pfeiltasten-, Escape- oder Tab-Logik erzeugen defekte Widgets.
Ist der zugängliche Name konsistent?
Der Name sollte zum sichtbaren Label und zur Funktion des Elements passen.
Wurden Zustandswechsel getestet?
Expandierte Bereiche, Modals und Live-Meldungen brauchen reale Interaktionstests.
Häufige Fragen zu ARIA
Soll ich auf allen interaktiven Elementen ARIA verwenden?
Nein. Bei Standard-Elementen verschlechtert zusätzliches ARIA die Situation oft eher. Zuerst sollte geprüft werden, ob sauberes HTML bereits alles Notwendige liefert.
Ist aria-label immer besser als sichtbarer Text?
Nein. Sichtbarer Text ist meist robuster und für alle Nutzenden klarer. aria-label ist vor allem für kompakte oder rein ikonische Bedienelemente sinnvoll.
Wie teste ich ARIA-Komponenten sinnvoll?
Mindestens mit Tastatur, Fokus-Prüfung und stichprobenartig mit einem Screenreader. Ergänzend helfen Keyboard Check, Focus Visibility Check und der Quick WCAG Check.
ARIA nur dort einsetzen, wo es wirklich hilft
Im Buch wird ARIA nicht isoliert betrachtet, sondern im Zusammenspiel mit sauberer HTML-Struktur, FokusfÜhrung und Interaktionsdesign. Für die technische Vorprüfung helfen ausserdem die verlinkten Spezial-Checks.