Zum Inhalt springen

Von XHTML zu semantischem HTML

Was von den strengen XHTML-Regeln übrig geblieben ist, welche Elemente heute Struktur tragen und warum Semantik und Barrierefreiheit dieselbe Sache sind.

Zuletzt geprüft: Gedacht für: Altprojekte modernisieren

Das Wichtigste

  • XHTML als eigener Standard ist Geschichte. Geblieben ist die Disziplin: geschlossene Elemente, kleingeschriebene Attribute, Werte in Anführungszeichen.
  • Semantische Elemente sind keine Kosmetik. Screenreader bauen daraus die Navigation, mit der Nutzer eine Seite überspringen und anspringen.
  • Ein <div> mit onclick ist kein Button: keine Tastaturbedienung, keine Rolle, kein Fokus. <button> bringt alles davon mit.
  • Genau eine <h1> pro Seite, danach lückenlose Hierarchie. Übersprungene Ebenen brechen die Sprungnavigation.

XHTML sollte HTML in die Strenge von XML überführen: jedes Element geschlossen, jedes Attribut kleingeschrieben und in Anführungszeichen, ein einziger Syntaxfehler und die Seite wird gar nicht angezeigt. Der Standard hat sich nicht durchgesetzt – die Disziplin dahinter hat sich als nützlich erwiesen.

Was geblieben ist

XHTML-Regelheute
Elemente immer schliessenbei nicht-leeren Elementen weiterhin richtig
<br /> mit Schrägstrichoptional, ohne Wirkung
Attribute kleingeschriebenKonvention, nicht erzwungen
Attributwerte in Anführungszeichendringend empfohlen
Attribute ohne Wert nicht erlaubt<input required> ist wieder gültig
Korrekte Verschachtelungunverändert wichtig
Ein Wurzelelementunverändert
Strenge Fehlerbehandlungaufgegeben, Browser reparieren

Die aufgegebene Fehlerbehandlung war der eigentliche Grund für das Scheitern: Eine Seite, die wegen eines nicht geschlossenen Listenpunkts komplett weiss bleibt, ist in der Praxis unbrauchbar. HTML5 definiert stattdessen genau, wie ein Parser mit fehlerhaftem Markup umgeht – und damit reparieren alle Browser gleich.

Übrig bleibt eine praktische Empfehlung: Schreibe so, als würde die Strenge noch gelten. Sauber verschachteltes, konsequent geschlossenes Markup ist leichter zu ändern, und Template-Engines wie Werkzeuge müssen weniger raten.

Struktur statt Container

Der typische Altbestand:

<div id="header">
  <div id="nav">…</div>
</div>
<div id="content">
  <div class="article">
    <div class="title">Überschrift</div>
    <div class="text">…</div>
  </div>
</div>
<div id="footer">…</div>

Für den Browser sind das zehn bedeutungslose Kästen. Dasselbe mit Bedeutung:

<header>
  <nav aria-label="Hauptnavigation">…</nav>
</header>
<main>
  <article>
    <h1>Überschrift</h1>
    <p>…</p>
  </article>
</main>
<footer>…</footer>

Der Unterschied ist nicht ästhetisch. Ein Screenreader baut aus diesen Elementen eine Landmarkenliste, über die Nutzer direkt zur Navigation oder zum Hauptinhalt springen. Ohne sie bleibt nur, sich linear durch die Seite zu arbeiten.

ElementBedeutung
<header>einleitender Bereich einer Seite oder eines Abschnitts
<nav>ein Block von Navigationslinks
<main>der Hauptinhalt, genau einmal pro Seite
<article>in sich abgeschlossener Inhalt
<section>thematischer Abschnitt – mit eigener Überschrift
<aside>ergänzender Inhalt
<footer>Abschluss einer Seite oder eines Abschnitts
<figure> / <figcaption>Abbildung mit zugehöriger Beschriftung
<time datetime="">maschinenlesbares Datum

<section> ohne Überschrift ist die häufigste Fehlanwendung. Wenn kein Titel dazugehört, ist ein <div> das ehrlichere Element.

Überschriften bilden die Gliederung

Genau eine <h1> pro Seite, danach lückenlos absteigend. Von <h2> direkt zu <h4> zu springen bricht die Sprungnavigation, mit der Screenreader-Nutzer eine Seite überfliegen.

Überschriften sind kein Mittel zur Schriftgrösse. Wer eine kleinere Schrift will, nimmt eine Klasse, keine tiefere Ebene.

Interaktive Elemente

<!-- funktioniert nur mit Maus -->
<div class="btn" onclick="senden()">Absenden</div>

<!-- funktioniert für alle -->
<button type="button" onclick="senden()">Absenden</button>

Das native <button> bringt mit:

  • Fokussierbarkeit über die Tabulatortaste
  • Auslösen mit Leertaste und Eingabetaste
  • die Rolle “Schaltfläche” für Hilfsmittel
  • den Deaktiviert-Zustand über disabled

Ein <div> bringt nichts davon. Alles nachzurüsten braucht role, tabindex, Tastatur-Handler für zwei Tasten und aria-disabled – und ist trotzdem nur eine Näherung.

Dasselbe gilt für Links: <a href="…"> navigiert, <button> löst eine Aktion aus. Ein <a href="#"> mit JavaScript ist beides nicht richtig.

Formulare

<label for="mail">E-Mail-Adresse</label>
<input type="email" id="mail" name="mail" required
       autocomplete="email" aria-describedby="mail-hilfe">
<p id="mail-hilfe">Wir verwenden die Adresse nur für die Antwort.</p>

Vier Punkte, die zusammen den Unterschied machen:

  • <label for="…"> verknüpft Beschriftung und Feld. Ein Klick auf die Beschriftung setzt den Fokus, und Screenreader lesen sie vor.
  • type="email" blendet auf Mobilgeräten die passende Tastatur ein.
  • autocomplete erlaubt dem Browser das Ausfüllen – das ist für viele Nutzer der grösste Einzelgewinn an Bedienbarkeit.
  • aria-describedby verknüpft den Hilfetext, sodass er beim Fokussieren mitgelesen wird.

Ein Platzhalter ist keine Beschriftung. Er verschwindet beim Tippen, hat oft zu wenig Kontrast und wird nicht überall vorgelesen.

Prüfen

Automatische Prüfer finden fehlende Alternativtexte und Kontrastprobleme. Was sie nicht finden, findet ein Tastaturtest in zwei Minuten:

  1. Auf der Seite Tab drücken und nur mit der Tastatur weitergehen.
  2. Ist jedes bedienbare Element erreichbar?
  3. Ist der Fokus jederzeit sichtbar?
  4. Ist die Reihenfolge nachvollziehbar?
  5. Kommt man aus jedem geöffneten Dialog mit Esc wieder heraus?

Wer diese fünf Punkte einhält, hat mehr für die Bedienbarkeit getan als mit jeder ARIA-Erweiterung.

Häufige Fragen

Muss ich Elemente noch selbst schliessen?

In HTML5 ist der Schrägstrich bei leeren Elementen optional und ohne Wirkung. Konsequent zu schliessen bleibt trotzdem sinnvoll, weil es Vorlagen eindeutig macht und Werkzeuge weniger raten müssen. Wichtiger ist, nicht-leere Elemente wie Listenpunkte und Absätze zu schliessen.

Was bringt semantisches HTML konkret?

Screenreader bauen daraus eine Übersicht, mit der Nutzer direkt zur Navigation oder zum Hauptinhalt springen. Suchmaschinen und Textextraktion erkennen die Struktur besser. Und der eigene Code wird lesbar, weil ein main mehr aussagt als ein div mit einer Klasse.

Sind ARIA-Attribute besser als semantische Elemente?

Nein, sie sind der Ersatz, wenn kein passendes Element existiert. Die erste Regel von ARIA lautet, ARIA nicht zu verwenden, wenn es ein natives Element gibt. Ein button ist immer besser als ein div mit role button.

Wie prüfe ich die Struktur meiner Seite?

Mit einem Werkzeug für die Überschriftengliederung und einem Tastaturtest: Nur mit Tabulator durch die Seite gehen und schauen, ob jedes bedienbare Element erreichbar ist und der Fokus sichtbar bleibt. Das findet mehr als jeder automatische Prüfer.