Semantik & ARIA

Semantisches HTML und WAI-ARIA

Begriffe vorab

• Semantik: Bedeutung von Elementen, nicht nur ihr Aussehen.
• Rolle: Art des Elements (Button, Link, Tab).
• Zustand: veränderliche Eigenschaft wie „aufgeklappt“.
• Zugänglicher Name: der Name, den assistive Technik für ein Element ausgibt.

Die wirkungsvollste Barrierefreiheits-Maßnahme ist oft die unspektakulärste: korrektes, semantisches HTML.

Die erste ARIA-Regel

Der WAI-ARIA Authoring Practices Guide formuliert es als „No ARIA is better than Bad ARIA“ und als erste Regel: Wenn ein natives HTML-Element oder -Attribut mit der benötigten Semantik existiert, sollte es verwendet werden, statt ein generisches Element mit ARIA nachzubauen.

<!-- Gut -->
<button>Absenden</button>

<!-- Unnötig aufwendig und fehleranfällig -->
<div role="button" tabindex="0" onclick="..." onkeydown="...">Absenden</div>

Ein natives <button> ist automatisch per Tastatur fokussierbar und auslösbar und wird von Screenreadern korrekt als Schaltfläche angesagt. Der div muss all das händisch nachbilden und vergisst dabei leicht Details wie Leertaste als Auslöser.

Landmark-Rollen und Strukturelemente

HTML5-Elemente wie <header>, <nav>, <main>, <aside> und <footer> erzeugen automatisch ARIA-Landmarks, über die Screenreader-Nutzende direkt zwischen Seitenbereichen springen können. Überschriften (<h1> bis <h6>) müssen eine sinnvolle, nicht rein optisch motivierte Hierarchie bilden – sie sind die wichtigste Navigationshilfe für Screenreader-Nutzende.

Wann ARIA sinnvoll ergänzt

Für Komponenten, die HTML nicht nativ abdeckt (Tabs, Akkordeons, komplexe Comboboxen), definiert WAI-ARIA Rollen, Zustände und Eigenschaften:

• role – z. B. role="tablist", role="dialog".
• aria-expanded – zeigt an, ob ein Element auf- oder zugeklappt ist.
• aria-label / aria-labelledby – liefert einen zugänglichen Namen, wenn kein sichtbarer Text ausreicht.
• aria-live – meldet dynamische Inhaltsänderungen (z. B. eine Statusmeldung), ohne dass der Fokus wechseln muss.

Der WAI-ARIA Authoring Practices Guide (APG) liefert für Standardmuster wie Tabs, Akkordeons und Dialoge fertige Referenzimplementierungen inklusive Tastaturverhalten.

ARIA-Attribute ändern nur, was assistive Technologien ansagen – sie ändern nichts am tatsächlichen Verhalten. aria-hidden="true" auf einem fokussierbaren Element versteckt es zwar vor Screenreadern, per Tastatur bleibt es aber trotzdem erreichbar. Beides muss zusammenpassen.

Ein Beispiel: Akkordeon

Ein Akkordeon besteht aus einer Schaltfläche, die einen Bereich auf- und zuklappt. Mit einem echten <button>, dem Attribut aria-expanded (wahr/falsch) und aria-controls, das auf den Bereich verweist, erfährt ein Screenreader-Nutzer: „Versand, Schaltfläche, eingeklappt“. Das Zustandsattribut muss beim Klick mit dem tatsächlichen Zustand aktualisiert werden, sonst sagt die Seite etwas Falsches an.

Der Namensbaustein

Ein zugänglicher Name entsteht in dieser Reihenfolge aus sichtbarem Text, aria-labelledby, aria-label oder dem Label. Sichtbarer Text ist der beste Name, weil er mit dem übereinstimmt, was alle sehen; Sprachsteuerungsnutzer sprechen, was sie sehen.

Heading- und Landmark-Gerüst

• Genau eine h1 je Seite, darunter logisch gestaffelte Überschriften.
• Jeder Hauptbereich in ein passendes Landmark (main, nav, footer).
• Mehrere Navigationen durch Namen unterscheiden.

Prüfstatus: Belegt (Stand 1. Oktober 2026): Jahreszahlen, Zahlen, Namen und Quellenangaben dieser Lektion, soweit die Quellenliste sie nennt, wurden gegen Primärquellen geprüft. Nicht einzeln belegt: erklärende Darstellung nach Lehrbuchstand und Quellen, die in der Liste als „allgemeine Referenz“ markiert sind.

Quellen

• W3C – WAI-ARIA 1.2 Spezifikation und „WAI-ARIA Authoring Practices Guide (APG)“ (allgemeine Referenz, nicht Zeile für Zeile geprüft)
• WCAG 2.2 – Erfolgskriterium 4.1.2 „Name, Rolle, Wert“
• MDN Web Docs – „ARIA“ und „HTML-Elemente nach Kategorie“ (Referenz zu semantischem HTML) (allgemeine Referenz, nicht Zeile für Zeile geprüft)