Überschriften-Struktur richtig einsetzen (h1-h6)

1. Warum Überschriften-Struktur über die Navigierbarkeit entscheidet

Sehende Nutzer überfliegen eine Seite visuell: großer fetter Text signalisiert einen neuen Abschnitt, kleinere Zwischentitel gliedern Unterpunkte. Screenreader-Nutzer haben diese visuelle Abkürzung nicht. Stattdessen verlassen sie sich auf die programmatische Überschriften-Struktur im HTML. Assistive Technologien wie JAWS, NVDA und VoiceOver bieten eine eigene Tastenkombination, meist die Taste H, mit der Nutzer von einer Überschrift zur nächsten springen, ohne den gesamten Text durchzuhören. Umfragen von WebAIM zeigen seit Jahren konstant, dass die Mehrheit der Screenreader-Nutzer genau diese Sprungnavigation als bevorzugte Methode angibt, um sich einen ersten Überblick über eine unbekannte Seite zu verschaffen.

Damit ist die Überschriften-Struktur faktisch das Inhaltsverzeichnis der Seite, nicht nur eine typografische Formatierung. Fehlt eine echte Hierarchie oder ist sie inkonsistent, verliert der Screenreader-Nutzer genau diese Orientierung, während die Seite für sehende Besucher optisch völlig unauffällig aussieht. Der Fehler bleibt im Alltag oft unbemerkt, weil kein visueller Bruch entsteht, wohl aber ein struktureller. Genau diese Unsichtbarkeit macht Heading-Fehler zu einer der häufigsten und zugleich am leichtesten vermeidbaren Barrieren im Web.

2. Semantische Bedeutung versus visuelles Styling

Der zentrale Denkfehler bei Überschriften: Entwickler wählen die Tag-Ebene h1 bis h6 anhand der gewünschten Schriftgröße, nicht anhand der inhaltlichen Position im Dokument. Eine h4 wird eingesetzt, weil sie im Standard-Stylesheet kleiner aussieht als eine h2, obwohl der Abschnitt inhaltlich klar eine zweite Gliederungsebene ist. Für sehende Nutzer fällt das nicht auf, für die Accessibility-API, die Screenreadern die Struktur mitteilt, ist es jedoch ein direkter Bruch: Die Ebene im Dokumentbaum stimmt nicht mehr mit der tatsächlichen inhaltlichen Hierarchie überein.

Die saubere Lösung trennt beide Zuständigkeiten strikt: Die HTML-Ebene h1 bis h6 beschreibt ausschließlich die Position im Inhaltsbaum, während CSS-Klassen die visuelle Größe, Gewichtung und den Abstand steuern. Eine h2 darf optisch genauso klein aussehen wie eine h5, solange die semantische Ebene der tatsächlichen Gliederung entspricht. Tailwind-Utility-Klassen eignen sich dafür besonders gut, weil sie Größe und Tag vollständig entkoppeln, ohne dass eigene CSS-Selektoren pro Heading-Level nötig sind.

<!-- Semantische Ebene und visuelle Größe sind zwei unterschiedliche Dinge -->

<!-- FALSCH: h5 nur gewählt, weil die Schrift kleiner aussehen soll -->
<h5 class="font-bold text-2xl mt-8">Neue Kollektion Sommer 2026</h5>
<p>Leichte Stoffe, klare Schnitte, limitierte Stückzahlen.</p>

<!-- RICHTIG: h3 behält die korrekte Ebene im Dokumentbaum, -->
<!-- die Größe kommt ausschließlich aus der Utility-Klasse -->
<h3 class="font-bold text-2xl mt-8">Neue Kollektion Sommer 2026</h3>
<p>Leichte Stoffe, klare Schnitte, limitierte Stückzahlen.</p>

3. Genau ein h1 pro Seite: die praktische Konvention

Die HTML5-Spezifikation erlaubt technisch mehrere h1-Elemente pro Seite, sofern sie in getrennten sectioning-Elementen wie article oder section stehen und ein sogenannter Outline-Algorithmus die Ebenen daraus ableitet. In der Praxis unterstützt kein gängiger Browser und kein Screenreader diesen theoretischen Outline-Algorithmus vollständig. Für Nutzer von JAWS, NVDA und VoiceOver zählt schlicht die tatsächliche Tag-Ebene im DOM, unabhängig vom umgebenden sectioning-Element.

Deshalb hat sich in der Praxis eine einfache, robuste Konvention durchgesetzt: genau ein h1 pro Seite, das den Seitentitel oder das zentrale Thema der Seite benennt, etwa den Produktnamen auf einer Produktdetailseite oder den Kategorienamen auf einer Kategorieseite. Alle weiteren Abschnitte folgen ab h2 abwärts. Diese Konvention ist keine offizielle WCAG-Pflicht, aber die verlässlichste Methode, um Screenreader-Nutzern eine eindeutige Antwort auf die Frage zu geben, wo sie sich gerade befinden, sobald sie mit der Taste 1 direkt zur nächsten h1 springen.

4. Hierarchie einhalten: keine Ebenen überspringen

Neben der h1-Konvention ist die zweite zentrale Regel: Überschriftenebenen dürfen beim Abstieg nicht übersprungen werden. Auf eine h2 darf als nächste tiefere Ebene nur eine h3 folgen, niemals direkt eine h4. Der Grund liegt wieder in der Sprungnavigation: Ein Screenreader-Nutzer, der sich systematisch von Ebene zu Ebene durch die Seite arbeitet, erwartet eine lückenlose Kette. Fehlt eine Zwischenebene, entsteht der Eindruck, ein ganzer Abschnitt sei verschwunden, obwohl der Inhalt eigentlich vorhanden ist, nur unter der falschen Ebene einsortiert.

Beim Aufstieg zurück zu einer höheren Ebene ist ein Sprung dagegen unproblematisch: Nach mehreren h3-Abschnitten direkt wieder mit einer neuen h2 weiterzumachen, ist die normale und korrekte Beendigung eines Unterabschnitts. Die Regel betrifft ausschließlich das Hinabsteigen in der Hierarchie. Wer ein Redesign plant und dabei eine kleinere Schriftgröße für einen bestimmten Bereich möchte, sollte deshalb immer zuerst die inhaltliche Frage stellen: Auf welcher tatsächlichen Gliederungsebene befindet sich dieser Abschnitt, unabhängig davon, wie er später aussehen soll.

5. Umsetzung in Magento- und Hyvä-Templates

In Magento-Shops entstehen Heading-Fehler häufig an drei Stellen: im Theme-Layout selbst, in CMS-Blöcken, die über den WYSIWYG-Editor gepflegt werden, und in Widget-Ausgaben von Drittanbieter-Modulen. Der WYSIWYG-Editor im Magento-Backend erlaubt Redakteuren freie Wahl der Überschriftenebene, ohne auf die umgebende Seitenstruktur Rücksicht zu nehmen. Ergebnis: Ein CMS-Block mit einer h2 mitten auf einer Produktdetailseite, die bereits eine eigene h2 für „Beschreibung" besitzt, oder ein Marketing-Widget, das aus Gewohnheit mit h1 beginnt.

Im Hyvä-Theme lässt sich die Struktur direkt im phtml-Template kontrollieren, da dort kein Block-generiertes Markup wie bei klassischen UI-Components verwendet wird. Die Produktdetailseite setzt den Produktnamen als einzige h1, während Abschnitte wie Beschreibung, technische Daten oder Bewertungen konsequent mit h2 beginnen. Für Redakteure empfiehlt sich zusätzlich eine CMS-Richtlinie, die WYSIWYG-Überschriften grundsätzlich bei h3 starten lässt, damit CMS-Inhalte niemals mit der Seitenstruktur kollidieren können.

<!-- Hyvä phtml: Kategorieseite mit korrekter Überschriften-Hierarchie -->
<div class="category-view">
    <h1 class="text-3xl font-bold"><?= $block->escapeHtml($category->getName()) ?></h1>

    <?php if ($block->getCategoryDescription()): ?>
        <div class="category-description mt-4">
            <?= /* @noEscape */ $block->getCategoryDescription() ?>
        </div>
    <?php endif; ?>

    <h3 class="text-xl font-semibold mt-8">Produkte in dieser Kategorie</h3>
    <div class="product-grid">
        <?= $block->getChildHtml('category.product.list') ?>
    </div>

    <?php if ($block->getRelatedCategories()): ?>
        <h3 class="text-xl font-semibold mt-8">Verwandte Kategorien</h3>
        <?= $block->getChildHtml('category.related') ?>
    <?php endif; ?>
</div>

6. Zusammenspiel mit ARIA-Landmarks und Rollen

ARIA-Landmarks wie main, nav und aside ergänzen die Überschriften-Struktur, ersetzen sie aber nicht. Landmarks beantworten die Frage „welcher Bereich der Seite ist das", Überschriften beantworten „welche inhaltliche Gliederung hat dieser Bereich". Ein Screenreader-Nutzer springt oft zwischen beiden Navigationsarten hin und her: zunächst per Landmark zum main-Bereich, danach per Heading-Taste durch die dortigen Abschnitte. Fehlt eine der beiden Ebenen, bleibt die andere als Notlösung, ist aber deutlich weniger präzise.

Für interaktive Komponenten, die aus Design-Gründen kein natives h1 bis h6 verwenden können, etwa ein div, das per JavaScript als Akkordeon-Titel fungiert, lässt sich mit role="heading" und aria-level="3" eine gleichwertige semantische Ebene erzwingen. Diese Lösung sollte jedoch die Ausnahme bleiben: Ein natives h3-Element ist immer robuster, weil es ohne zusätzliche ARIA-Attribute funktioniert und von jedem Tool automatisch korrekt erkannt wird. Automatisierte Prüfwerkzeuge wie axe-core melden übersprungene Ebenen unabhängig davon, ob sie nativ oder per ARIA-Rolle erzeugt wurden.

{
  "id": "heading-order",
  "impact": "moderate",
  "description": "Ensures the order of headings is semantically correct",
  "help": "Heading levels should only increase by one",
  "helpUrl": "https://dequeuniversity.com/rules/axe/4.9/heading-order",
  "nodes": [
    {
      "html": "<h4 class=\"font-bold text-2xl\">Neue Kollektion Sommer 2026</h4>",
      "target": [".category-view > h4"],
      "failureSummary": "Fix any of the following: Heading order invalid, expected h2 or h3 but got h4"
    }
  ]
}

7. Auditing: Browser-Tools und Screenreader-Test

Der schnellste Weg, eine Überschriften-Struktur zu prüfen, führt über kostenlose Browser-Erweiterungen wie HeadingsMap oder das Accessibility-Panel der Chrome- und Firefox-Entwicklertools. HeadingsMap zeigt die gesamte Gliederung einer Seite auf einen Blick als eingerückte Baumstruktur und markiert übersprungene Ebenen sofort visuell. Wer keine Erweiterung installieren will oder darf, erreicht dasselbe Ergebnis mit wenigen Zeilen JavaScript direkt in der Browser-Konsole, was sich auch gut in ein Pre-Deployment-Skript einbauen lässt.

Automatisierte Tools wie axe-core oder Lighthouse decken strukturelle Fehler wie übersprungene Ebenen oder mehrere h1-Elemente zuverlässig auf, erkennen aber nicht, ob eine Überschrift inhaltlich sinnvoll ist. Deshalb ergänzt ein kurzer manueller Test mit NVDA oder VoiceOver die automatisierte Prüfung: Mit der Taste H durch die Seite springen und dabei laut mitlesen, ob die vorgelesene Gliederung für jemanden, der die Seite nicht sieht, tatsächlich verständlich ist. Dieser Test dauert selten länger als fünf Minuten pro Seitentyp.

// In der Browser-Konsole ausführen: gibt die Überschriften-Gliederung der Seite aus
(function printHeadingOutline() {
  const headings = document.querySelectorAll('h1, h2, h3, h4, h5, h6');
  let lastLevel = 0;

  headings.forEach((heading) => {
    const level = parseInt(heading.tagName.substring(1), 10);
    const indent = '  '.repeat(level - 1);
    const skipped = level - lastLevel > 1 && lastLevel !== 0;
    const marker = skipped ? '  <-- Ebene übersprungen' : '';

    console.log(`${indent}h${level}: ${heading.textContent.trim()}${marker}`);
    lastLevel = level;
  });

  const h1Count = document.querySelectorAll('h1').length;
  console.log(`\nGefundene h1-Elemente: ${h1Count}${h1Count !== 1 ? '  <-- sollte genau 1 sein' : ''}`);
})();

8. Häufige Fehler in der Praxis

Der häufigste Fehler ist die rein optische Wahl der Heading-Ebene, gefolgt von div- oder span-Elementen, die per fettem, großem CSS wie eine Überschrift aussehen, aber semantisch überhaupt nicht als Heading erkennbar sind. Für Screenreader-Nutzer existiert ein solches Element schlicht nicht in der Gliederung, egal wie prominent es optisch wirkt. Ein weiterer klassischer Fehler entsteht durch mehrere unabhängig entwickelte Komponenten auf derselben Seite, etwa ein Marketing-Banner-Modul, das standardmäßig mit h1 beginnt, kombiniert mit dem eigentlichen Seiten-h1 aus dem Theme.

Dritter häufiger Fehler: Überschriften werden für rein dekorative Marketing-Claims missbraucht, etwa <h2>Jetzt Angebot sichern!</h2> ohne echten inhaltlichen Abschnitt darunter. Das bläht die Gliederung für Screenreader-Nutzer künstlich auf und verwässert die eigentliche Struktur. Die Faustregel: Eine Überschrift beschreibt immer den folgenden Inhaltsblock, niemals nur einen isolierten Werbetext ohne zugehörigen Abschnitt.

/* Größenklassen unabhängig von der semantischen Ebene definieren */
.heading-display { font-size: 2.25rem; font-weight: 800; line-height: 1.2; }
.heading-section  { font-size: 1.5rem;  font-weight: 700; line-height: 1.3; }
.heading-label    { font-size: 1rem;    font-weight: 600; letter-spacing: 0.02em; }

/* Eine h3 darf optisch wie eine h1 aussehen, ohne die Ebene zu ändern */
h3.heading-display {
  font-size: 2.25rem;
}

/* Ein div sieht wie eine Überschrift aus, ist aber semantisch keine */
/* Screenreader-Nutzer finden dieses Element in der Gliederung nicht */
.fake-heading {
  font-size: 1.5rem;
  font-weight: 700;
}

9. Überschriften-Patterns im direkten Vergleich

Die folgende Übersicht fasst die wichtigsten Entscheidungen zwischen unsicherer und korrekter Umsetzung zusammen. Jede Zeile beschreibt ein Szenario, das in Magento- und Hyvä-Shops regelmäßig auftaucht.

Alle fünf Szenarien haben denselben Kern: Die Entscheidung für eine Heading-Ebene sollte immer aus der tatsächlichen inhaltlichen Position im Dokument folgen, niemals aus dem gewünschten Erscheinungsbild. Wer diese Trennung konsequent einhält, muss Überschriften nie wieder nachträglich umbauen, wenn sich das Design ändert.

10. Zusammenfassung

Eine korrekte Überschriften-Struktur ist keine Frage der Optik, sondern das Inhaltsverzeichnis der Seite für Screenreader-Nutzer, die per Tastenkürzel direkt von einer Überschrift zur nächsten springen. h1 bis h6 beschreiben ausschließlich die Position im Dokumentbaum, während CSS-Klassen die Größe und den Stil steuern. Genau ein h1 pro Seite hat sich als robuste Konvention durchgesetzt, weil kein gängiger Screenreader den theoretischen HTML5-Outline-Algorithmus zuverlässig umsetzt. Beim Abstieg in tiefere Ebenen dürfen niemals Stufen übersprungen werden, während der Aufstieg zu einer höheren Ebene jederzeit möglich ist.

In Magento- und Hyvä-Shops entstehen Fehler meist an drei Stellen: im Theme selbst, in CMS-Blöcken über den WYSIWYG-Editor und in Drittanbieter-Widgets. Browser-Erweiterungen wie HeadingsMap, automatisierte Tools wie axe-core und ein kurzer manueller Test mit NVDA oder VoiceOver decken die häufigsten Probleme in wenigen Minuten pro Seitentyp auf. Wer die Trennung zwischen semantischer Ebene und visueller Größe konsequent einhält, muss die Struktur bei jedem Redesign nie wieder anfassen.

11. FAQ: Überschriften-Struktur richtig einsetzen