Konzepte

Semantisches HTML

HTML-Elemente werden für ihre Bedeutung verwendet, nicht nur für ihr Standardaussehen. Ein `<button>` wird als Schaltfläche angekündigt; ein `<div onclick>` als nichts. Die überwiegende Mehrheit der Barrierefreiheitsfehler lässt sich auf aufgegebene Semantik zurückführen.

Semantisches HTML bezeichnet HTML, bei dem jedes Element nach seiner Bedeutung gewählt wird, nicht nur nach seinem Aussehen. Ein <button> dient Aktionen. Ein <nav> umschließt die Navigation. Ein <table> enthält tabellarische Daten. Ein <div> zu verwenden, das wie eine Schaltfläche aussieht, ist ein semantischer Fehler — auch wenn das visuelle Ergebnis identisch ist.

Die überwiegende Mehrheit der Barrierefreiheitsfehler lässt sich auf aufgegebene Semantik zurückführen. Fast jeder Fehler bei assistiven Technologien hat dieselbe Grundursache: ein generisches Element übernimmt die Aufgabe eines semantischen Elements, das genau dafür vorgesehen war.

Warum Screenreader das betrifft

Screenreader machen HTML über den Accessibility Tree zugänglich — eine interne Repräsentation, die aus dem DOM aufgebaut wird und jedes Element einer Rolle, einem Namen, einem Zustand und Eigenschaften zuordnet. Der Accessibility Tree ist das, was der Nutzende tatsächlich hört.

Ein nativer <button> wird im Accessibility Tree als button "Absenden" geführt. Ein <div>, das wie eine Schaltfläche aussieht, wird als generic geführt — der Screenreader kündigt also nichts Sinnvolles an, und der Nutzende hat keine Möglichkeit zu erkennen, dass das Div interaktiv ist.

Dieselbe Logik gilt für:

  • Überschriften (<h1>–<h6>) — Screenreader ermöglichen es Nutzenden, zwischen Überschriften zu springen, um eine Seite zu überfliegen. <div class="heading"> erscheint nicht in der Überschriftenliste.
  • Listen (<ul>, <ol>, <li>) — Screenreader kündigen „Liste, 5 Einträge“ an, bevor vorgelesen wird. <div>-Elemente, die Listeneinträge imitieren, tun das nicht.
  • Formulare — <input> mit verbundenem <label> wird vorgelesen als „E-Mail, Textfeld“. Ein benutzerdefiniertes Eingabefeld aus Divs und contenteditable wird gar nicht angekündigt.
  • Tabellen — <table> mit <th>-Zeilen-/Spaltenüberschriften ermöglicht Nutzenden, Datentabellen zellenweise mit angekündigtem Kopfzeilenkontext zu navigieren. CSS-Grids aus Divs hingegen nicht.

Das Ersetzungsmuster

Die Korrektur hat fast immer dieselbe Form:

  • <div onclick="..."> → <button> (oder <a href> für Navigation).
  • <span class="link"> → <a href>.
  • <div role="heading"> → <h1> bis <h6>.
  • Benutzerdefinierte Dropdowns → <select> wo das Design es erlaubt, oder ein erprobtes ARIA-Combobox-Muster, wo es das nicht tut.
  • Tabs aus gestalteten <div>-Elementen → Tab-Muster aus dem ARIA Authoring Practices Guide.

Wann ARIA eingesetzt werden sollte

Die erste Regel von ARIA lautet: ARIA nicht verwenden, wenn ein natives Element die Aufgabe erfüllt. ARIA-Rollen, -Zustände und -Eigenschaften sind ein Patch für Fälle, in denen natives HTML das aufzubauende Widget nicht beschreiben kann (Baumansichten, Multi-Select-Comboboxen, bestimmte Modal-Muster). Sie sind kein Ersatz für die Verwendung von <button>.

Ein pragmatisches Audit

Der schnellste Weg, semantischen Verfall in einer Codebasis aufzudecken: nach onclick auf div- und span-Elementen suchen. Jeder Treffer ist ein potenzieller Fehler. Der nächstschnellere Weg: nach role=-Attributen suchen. ARIA ist in begrenzten Kontexten sinnvoll, aber ein hoher ARIA-Anteil deutet häufig darauf hin, dass native Elemente aus Styling-Gründen übergangen wurden, die den Verzicht gar nicht erfordert hätten.