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.
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>mitonclickist 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-Regel | heute |
|---|---|
| Elemente immer schliessen | bei nicht-leeren Elementen weiterhin richtig |
<br /> mit Schrägstrich | optional, ohne Wirkung |
| Attribute kleingeschrieben | Konvention, nicht erzwungen |
| Attributwerte in Anführungszeichen | dringend empfohlen |
| Attribute ohne Wert nicht erlaubt | <input required> ist wieder gültig |
| Korrekte Verschachtelung | unverändert wichtig |
| Ein Wurzelelement | unverändert |
| Strenge Fehlerbehandlung | aufgegeben, 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.
| Element | Bedeutung |
|---|---|
<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.autocompleteerlaubt dem Browser das Ausfüllen – das ist für viele Nutzer der grösste Einzelgewinn an Bedienbarkeit.aria-describedbyverknü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:
- Auf der Seite
Tabdrücken und nur mit der Tastatur weitergehen. - Ist jedes bedienbare Element erreichbar?
- Ist der Fokus jederzeit sichtbar?
- Ist die Reihenfolge nachvollziehbar?
- Kommt man aus jedem geöffneten Dialog mit
Escwieder 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.
Weiterlesen
- Coding Standard: Konventionen, die Wartung sparen
Namensgebung, Einrückung, Kommentare und Dateiaufbau - als prüfbare Regeln statt als Geschmacksfrage.
- Template-Engines in PHP: Übersicht
Was eine Engine gegenüber purem PHP bringt, welche Ansätze es gibt und wie du für ein Projekt entscheidest.
- vlibTemplate: Aufbau, Syntax und Beispiele
Platzhalter, Schleifen, Bedingungen und Includes der klassischen Engine - inklusive Hinweisen zum Betrieb auf aktuellen PHP-Versionen.
- Smarty: Grundlagen und typische Muster
Zuweisungen, Modifier, Blöcke und Caching - und wo Smarty in modernen Projekten noch seinen Platz hat.