Semantisches HTML: Die Basis jeder barrierefreien Webseite

Die meisten Accessibility-Probleme entstehen, weil Entwickler <div> und <span> für alles nutzen – mit Custom-Klassen, ohne semantische Bedeutung. Das Ergebnis: Screenreader wissen nicht, was Navigation ist, was Hauptinhalt, was Button. Semantisches HTML löst 80 % aller Accessibility-Probleme, ohne eine einzige Zeile ARIA.

Die wichtigsten semantischen Tags

Landmarks: <header>, <nav>, <main>, <aside>, <footer>, <section>, <article>
Text-Struktur: <h1>–<h6> (Hierarchie!), <p>, <ul>/<ol>/<li>, <blockquote>
Interaktion: <button> (nicht <div onclick>!), <a href> (nicht <span onclick>)
Formulare: <label>, <fieldset>, <legend>, <input> mit korrektem type
Medien: <figure> + <figcaption> für Bilder mit Bildunterschrift

Die Landmark-Struktur

Eine barrierefreie Seite hat klare Landmarks:
<header> – Kopfbereich mit Logo + Hauptnavigation
<nav> – Navigation (kann auch im Header stehen)
<main> – Hauptinhalt (nur einmal pro Seite!)
<aside> – Seitenleiste (optional)
<footer> – Fußbereich
Screenreader-Nutzer springen per Shortcut direkt zwischen diesen Landmarks – erspart ihnen das Durchtabben der Navigation.

Warum <button> statt <div onclick>?

<button> ist automatisch tastaturbedienbar, fokussierbar, wird als Schaltfläche vorgelesen, lässt sich per Enter UND Leertaste auslösen. <div onclick> bietet nichts davon – nur CSS und JS. Für Barrierefreiheit müsstest du manuell nachrüsten: tabindex, role="button", onkeydown für Enter/Space, Focus-Styling. 10 Zeilen Code statt 1 nativem Tag.

Link vs. Button – nicht verwechseln

<a href>: navigiert zu einer anderen URL, ändert den Browser-Verlauf, kann Enter-auslösen.
<button>: löst eine Aktion aus (Formular senden, Modal öffnen, Filter setzen), ändert keinen URL.
Falsche Wahl (Link als Button gestylt, Button für Navigation) verwirrt Screenreader-Nutzer. Regel: Wenn "href" kein Sinn ergibt → Button.

Nicht übertreiben

Nicht jedes