Wenn Entwickler mich nach Barrierefreiheit fragen, fragen sie meistens nach ARIA-Attributen. Sie fragen selten nach dem richtigen HTML-Element. Das ist die falsche Reihenfolge – und einer der häufigsten Gründe, warum Custom-Komponenten in Audits durchfallen. Semantisches HTML ist nicht irgendein altmodisches Detail vor dem Framework-Zeitalter, sondern die tragende Schicht jeder zugänglichen Website. Wer das richtige Element wählt, bekommt Tastaturbedienung, Fokus-Verhalten, Screenreader-Unterstützung und Formular-Integration kostenlos dazu. Wer es ignoriert und mit div-Bausteinen plus ARIA arbeitet, baut dieselbe Funktionalität mühsam nach – meistens unvollständig. In diesem Ratgeber zeige ich Ihnen mit konkreten Code-Vergleichen, warum semantisches HTML rund 90 Prozent aller ARIA-Attribute überflüssig macht.
Was semantisches HTML ausmacht
Semantisches HTML bedeutet, Elemente nicht nach ihrer Optik, sondern nach ihrer Bedeutung zu wählen. Ein Button ist ein <button>, eine Liste ein <ul> oder <ol>, eine Hauptüberschrift ein <h1> und nicht ein gestyltes <div>. Diese Bedeutung ist für sehende Nutzer unsichtbar, für assistive Technologien aber zentral: Ein Screenreader unterscheidet zwischen einem Button und einem Absatz, navigiert über Überschriften und Landmarks, kündigt Listen als solche an. Generische Container wie <div> oder <span> sagen nichts über die Funktion ihres Inhalts aus – sie sind reine Behälter ohne semantischen Wert.
Warum semantisches HTML 90 Prozent der ARIA-Attribute überflüssig macht
Die Beobachtung ist nicht meine, sondern steht so ähnlich in den ARIA Authoring Practices des W3C: Wenn ein natives HTML-Element die nötige Semantik und das nötige Verhalten mitbringt, verwenden Sie dieses Element statt ARIA. Sieben konkrete Gegenüberstellungen zeigen, was das in der Praxis bedeutet.
Button
<!-- Mit ARIA -->
<div role="button" tabindex="0"
onclick="speichern()"
onkeydown="if(event.key==='Enter')speichern()">
Speichern
</div>
<!-- Semantisch -->
<button onclick="speichern()">Speichern</button>Das native <button> bringt von sich aus mit: Fokussierbarkeit, Tastaturbedienung mit Enter und Leertaste, Default-Fokus-Stil, korrekte Rolle für Screenreader, Formular-Integration. Beim div-Konstrukt müssen Sie das alles selbst nachbauen – und übersehen in der Regel mindestens einen Punkt.
Navigation
<!-- Mit ARIA -->
<div role="navigation" aria-label="Hauptnavigation">
<div><a href="/">Start</a></div>
<div><a href="/produkte">Produkte</a></div>
</div>
<!-- Semantisch -->
<nav aria-label="Hauptnavigation">
<ul>
<li><a href="/">Start</a></li>
<li><a href="/produkte">Produkte</a></li>
</ul>
</nav>Das <nav>-Element ist eine Landmark, die Screenreader-Nutzer mit einem einzigen Tastenkürzel ansteuern können. Die <ul> kündigt die Anzahl der Einträge an. Beides bekommt der div-Bau nicht ohne weiteres ARIA hin – und selbst dann fehlen die Listen-Ansagen.
Akkordeon
<!-- Mit ARIA (vereinfacht) -->
<div role="button" aria-expanded="false"
aria-controls="panel-1" tabindex="0">
Details
</div>
<div id="panel-1" role="region" hidden>
Inhalt
</div>
<!-- Semantisch -->
<details>
<summary>Details</summary>
Inhalt
</details>Das Element-Paar <details> und <summary> ist ein vollständig funktionales natives Akkordeon – mit Tastaturbedienung, Toggle-Verhalten und Zustandsmeldung. Wer das nicht weiß, baut die Komponente in JavaScript nach, oft inklusive vergessenem aria-expanded-Update.
Listen
<!-- Falsch -->
<div class="item">Erstes Element</div>
<div class="item">Zweites Element</div>
<div class="item">Drittes Element</div>
<!-- Semantisch -->
<ul>
<li>Erstes Element</li>
<li>Zweites Element</li>
<li>Drittes Element</li>
</ul>Ein Screenreader kündigt die <ul> mit „Liste mit drei Elementen“ an und erlaubt das Springen zwischen den Listenpunkten. Die div-Variante hört sich an wie drei zusammenhanglose Sätze.
Überschriften-Struktur
<!-- Falsch (rein optisch) -->
<div class="title-large">Unsere Produkte</div>
<div class="title-medium">Kategorie A</div>
<!-- Semantisch -->
<h1>Unsere Produkte</h1>
<h2>Kategorie A</h2>Die Überschriftenhierarchie ist für Screenreader-Nutzer das, was für Sehende das Überfliegen ist – die einzige Möglichkeit, sich schnell zu orientieren. Per Tastenkürzel können sie zwischen Überschriften springen. Ohne echte H-Elemente entfällt diese Navigation komplett.
Formular-Label
<!-- Falsch -->
<span>E-Mail-Adresse</span>
<input type="email">
<!-- Semantisch -->
<label for="email">E-Mail-Adresse</label>
<input type="email" id="email">Das verknüpfte <label> sorgt dafür, dass ein Klick auf den Beschriftungstext das Feld fokussiert – wichtig für Nutzer mit motorischen Einschränkungen. Ein Screenreader liest die Beschriftung beim Fokussieren automatisch vor. Beim span-Konstrukt fehlen beide Eigenschaften.
Bilder
<!-- Falsch -->
<div style="background-image: url(produkt.jpg)"
aria-label="Produktfoto"></div>
<!-- Semantisch -->
<img src="produkt.jpg" alt="Produktfoto">Ein <img>-Element mit echtem alt-Attribut wird von Screenreadern korrekt als Bild angekündigt, lädt vorhersehbar, lässt sich mit Browser-Werkzeugen anzeigen oder herunterladen. Ein als Hintergrundbild geladenes Foto ist für viele dieser Zwecke schlicht unsichtbar.
Die wichtigsten semantischen Elemente im Überblick
Eine kompakte Übersicht, gruppiert nach Funktion:
| Kategorie | Elemente | Funktion |
|---|---|---|
| Struktur (Landmarks) | header, nav, main, aside, footer | Hauptbereiche der Seite, navigierbar per Screenreader-Kürzel |
| Inhaltsbereiche | article, section | Inhaltliche Untergliederung |
| Überschriften | h1 bis h6 | Hierarchische Gliederung |
| Listen | ul, ol, li, dl, dt, dd | Zusammengehörige Aufzählungen |
| Interaktive Elemente | button, a, input, select, textarea, label, details, summary, dialog | Native Interaktion mit eingebauter Barrierefreiheit |
| Tabellen | table, thead, tbody, tr, th, td, caption | Tabellarische Daten mit Zell-Zuordnung |
| Medien | img, figure, figcaption, video, audio | Eingebettete Inhalte mit Alternativen |
Landmarks: Wie Screenreader-Nutzer navigieren
Die Landmark-Elemente <header>, <nav>, <main>, <aside> und <footer> sind mehr als nur semantisch korrekte Container. Sie sind Wegmarken, mit denen ein Screenreader-Nutzer per Tastenkürzel direkt durch die Seitenbereiche springt – ohne durch die komplette Tab-Reihenfolge wandern zu müssen. Eine Seite mit klaren Landmarks lässt sich in Sekunden überblicken; eine Seite ohne, in der alles in <div>-Containern liegt, zwingt zum sequenziellen Durchhören. Wichtig: <main> darf pro Seite nur einmal vorkommen und kennzeichnet den eigentlichen Hauptinhalt – der Inhalt, zu dem ein Skip-Link am Seitenanfang führen sollte. Wie Tastaturbedienung und Fokus-Management insgesamt funktionieren, habe ich in Tastaturbedienung und Fokus-Management nach WCAG umsetzen beschrieben.
Wann Sie ARIA wirklich noch brauchen
Die übrigen zehn Prozent. Wenn Ihr HTML semantisch sauber ist, bleibt ARIA für eine kleine, aber wichtige Auswahl von Fällen:
- Icon-Buttons ohne sichtbaren Text – ein Lupen-Symbol braucht einen
aria-label, weil das Element selbst keinen Textinhalt hat. - Custom-Widgets, für die HTML keine Entsprechung kennt – Tabs, Karussells, Trees, komplexe Modals. Auch hier gilt: vorher prüfen, ob nicht
<details>,<dialog>oder andere native Elemente passen. - Live-Regionen – Toast-Notifications, dynamische Suchergebnisse, Statusmeldungen, die ankommen müssen, ohne dass der Fokus wandert.
- Zustandsangaben bei nicht-nativen Komponenten –
aria-expanded,aria-pressed,aria-current.
Welche ARIA-Patterns dabei richtig sind und welche das Gegenteil bewirken, finden Sie in ARIA-Label richtig einsetzen: Der Praxis-Guide für Entwickler.
Die häufigsten HTML-Anti-Patterns aus der Praxis
Vier Muster fallen mir in Code-Reviews am häufigsten auf: Erstens, die <div>-Suppe – eine ganze Seite, in der nur generische Container verschachtelt sind, ohne ein einziges semantisches Element. Zweitens, Links, die wie Buttons aussehen sollen, aber als <a> ohne href oder mit href="#" auftreten – ein <a> ohne Ziel ist semantischer Müll. Drittens, Tabellen für Layout-Zwecke – ein Anti-Pattern, das aus den 2000er Jahren überlebt hat und in Newsletter-Templates immer noch grassiert. Viertens, mehrere <h1>-Elemente auf einer Seite, weil der Page Builder das so anlegt oder weil verschiedene Komponenten ihre Überschriften je als „Haupt“ auszeichnen. Pro Seite ein <h1>, das ist die ungeschriebene Regel, die in fast keinem Audit gehalten wird.
Was im Code-Review auffallen sollte
HTML-Mängel sind die einzige Klasse von Accessibility-Verstößen, die sich gut automatisiert erkennen lässt – fehlende alt-Attribute, falsche Überschriften-Hierarchie, generische Container ohne Semantik, Buttons ohne Beschriftung. Genau hier setzt unser Access Guard an: Das Monitoring prüft Ihre Seiten nach jedem Code-Deployment automatisch auf die typischen HTML-Anti-Patterns aus diesem Ratgeber und meldet sie direkt in Ihre Entwicklungs-Werkzeuge wie Jira, Slack oder Teams. Mit konkreten Hinweisen, welches semantische Element an welcher Stelle das richtige wäre.
Das ersetzt keinen Code-Review – aber es macht den Code-Review schneller, weil die offensichtlichen Mängel schon gemeldet sind, bevor jemand draufschaut. Wer den Stand seiner aktuellen Website zuerst grob einschätzen will, beginnt mit dem kostenlosen Access Score.
