NCA Social Media
Erstellt:
Aktualisiert:
Autor:
Roland Golla
Grüne Webseite mit Überschriften Hierarchie H1 H2 H3 und Wordmark Headlines

Was sind barrierefreie Headlines?

Barrierefreie Headlines sind Überschriften, die im HTML als echte Überschriften (h1 bis h6) ausgezeichnet sind und eine lückenlose, logische Hierarchie bilden. Screenreader lesen diese Struktur vor und springen von Überschrift zu Überschrift, so wie sehende Menschen eine Seite überfliegen.
Eine Überschrift ist damit nicht nur groß und fett. Sie ist ein Navigationspunkt. Wer eine Headline nur per CSS gestaltet, nimmt blinden Nutzern die Orientierung. Wer Ebenen überspringt, zerstört die Gliederung. Beides sind klassische Fehler, die in fast jedem Accessibility Audit auftauchen.
Die WCAG 2.2 fordern in Erfolgskriterium 1.3.1 (Info und Beziehungen), dass Struktur programmatisch erkennbar ist. Kriterium 2.4.6 (Überschriften und Beschriftungen) verlangt, dass Überschriften das Thema oder den Zweck beschreiben. Beides gilt in Deutschland über das BFSG seit Juni 2025 verbindlich für viele Onlineshops und Dienste.
Inhalt

Barrierefreie Headlines mit NCA: Schnelle Hilfe vom Experten

Wir bauen Frontends mit Astro, React und Vue und liefern Inhalte über Sulu CMS aus. Überschriftenstrukturen sind bei uns kein Nachtrag, sondern Teil der Komponente. Jede Heading Ebene wird in Cypress mit cypress-axe geprüft, bevor sie in Production geht. Das machen wir seit Jahren für eigene Projekte und für Teams, die ihre Seiten fit für BFSG und WCAG 2.2 machen wollen.
Dazu passen unsere Leistungen rund um Accessibility Webdesign und Frontend, die Umsetzung von barrierefreien Überschriftenstrukturen im Webdesign, automatisiertes Accessibility Testing mit axe DevTools und Cypress, Lighthouse Accessibility Audits und unsere Frontend Development Beratung für saubere, semantische Komponenten.
Lass uns sprechen
Finde das passende Angebot für dein Projekt
Anfrage-Konfiguration
Starten Sie Ihre Anfrage
Projektart
Infos
Nachricht

Eliminierung technischer Schulden mit PHPStan, Rector PHP und PHPUnit. Über 20 Jahre Praxiserfahrung in skalierbaren Backends.

CORE EXPERTISE

Gesetzliche Konformität & Inklusion. Optimierung von Performance und Conversion durch radikal nutzerzentriertes, universelles Design.

BFSG COMPLIANT

Skalierbare KI-Systeme mit echtem Code Ownership. CI/CD, Backup-Strategien und Infrastruktur, die mit deinem Team wächst.

ENTERPRISE READY

Warum Überschriften für Screenreader so wichtig sind

Sehende Menschen scannen eine Seite in Sekunden. Das Auge springt zu großen Buchstaben, zu Abständen, zu Fettdruck. Screenreader Nutzer haben dieses Bild nicht. Sie hören die Seite. Damit sie nicht alles von oben nach unten anhören müssen, bieten Screenreader wie NVDA, JAWS oder VoiceOver eine Überschriftenliste an. Ein Tastendruck, die Taste H, springt zur nächsten Überschrift. Die Zahlen 1 bis 6 springen direkt zu einer bestimmten Ebene.
Genau deshalb sind Headlines das wichtigste Navigationsinstrument nach den Links. Fehlt die h1, fehlt der Einstieg. Ist die Reihenfolge durcheinander, wirkt die Seite wie ein Buch mit vertauschten Kapiteln. Mehr zur Lesereihenfolge und zur logischen Reihenfolge haben wir in eigenen Glossar Einträgen zusammengefasst.
Der Effekt reicht weiter als bis zur Barrierefreiheit. Suchmaschinen nutzen dieselbe Struktur, um Inhalte zu gewichten. KI Suche und LLMs zerlegen Seiten entlang der Überschriften in Abschnitte. Eine saubere Hierarchie ist damit gleichzeitig Semantic HTML, SEO Grundlage und Voraussetzung dafür, dass ein Text in KI Antworten zitiert wird.

Die fünf Regeln für barrierefreie Headlines

  • Genau eine h1 pro Seite. Sie benennt das Thema der Seite und stimmt inhaltlich mit dem Seitentitel überein. HTML erlaubt technisch mehrere h1, in der Praxis führt das aber zu Verwirrung bei Screenreadern und Suchmaschinen.
  • Keine Ebene überspringen. Nach einer h2 folgt eine h3, nie direkt eine h4. Nach oben darf beliebig gesprungen werden, nach unten nur eine Stufe.
  • Struktur vor Optik. Die Ebene folgt der Gliederung, nicht der gewünschten Schriftgröße. Wenn eine h3 zu klein aussieht, ändert das CSS, nicht das Tag.
  • Jede Überschrift trägt Inhalt. Leere Headlines, Icons ohne Text oder Bilder als Überschrift ohne Alternativtext sind für Screenreader unsichtbar oder verwirrend.
  • Keine Fake Headlines. Ein fett gesetzter Absatz oder ein div mit großer Schrift ist keine Überschrift. Screenreader ignorieren ihn beim Springen komplett.
Ein sauberes Grundgerüst sieht so aus:
Code: 
          
<h1>Barrierefreie Headlines</h1>
  <h2>Warum Überschriften wichtig sind</h2>
  <h2>Die fünf Regeln</h2>
    <h3>Eine h1 pro Seite</h3>
    <h3>Keine Ebene überspringen</h3>
  <h2>Häufige Fragen</h2>
Die Einrückung dient nur der Lesbarkeit im Beispiel. Im echten Code stehen die Tags flach im DOM, die Hierarchie ergibt sich allein aus der Zahl hinter dem h.

Headlines in Komponenten: Die Falle bei React, Vue und Astro

In komponentenbasierten Frontends entsteht der häufigste Fehler nicht im Text, sondern in der Wiederverwendung. Eine Card Komponente bekommt eine h2 fest verdrahtet. Auf der Startseite passt das. Auf einer Detailseite liegt dieselbe Card unter einer h3 und plötzlich springt die Hierarchie von h3 zurück auf h2. Kein Entwickler hat einen Fehler gemacht, die Struktur ist trotzdem kaputt.
Die Lösung ist eine konfigurierbare Ebene. Die Komponente bekommt die Heading Stufe als Property und rendert das passende Tag:
Code: 
          
type Level = 1 | 2 | 3 | 4 | 5 | 6;

export function Heading({ level, children }: { level: Level; children: React.ReactNode }) {
  const Tag = `h${level}` as const;
  return <Tag>{children}</Tag>;
}

// Einsatz: <Heading level={3}>Titel der Card</Heading>
In Astro geht das mit einer Property und dynamischem Tag genauso, in Vue über eine component :is Anweisung. Wichtig ist nur: Die Seite entscheidet über die Ebene, nicht die Komponente. So bleibt die Hierarchie auch dann korrekt, wenn Redakteure im Sulu CMS Blöcke frei anordnen.
Ein zweiter Klassiker: Visuell versteckte Überschriften. Manchmal braucht ein Abschnitt für Screenreader eine Überschrift, die im Design nicht vorkommt, etwa über einer Navigationsliste. Dann hilft eine visually hidden Klasse, die den Text aus dem sichtbaren Bereich schiebt, aber im Accessibility Tree behält. display: none darf es nicht sein, das versteckt die Headline auch vor dem Screenreader. Wie Name, Rolle und Zustand hier zusammenspielen, erklärt unser Eintrag zu Name, Rolle, Zustand in ARIA.

Headlines automatisiert testen mit axe-core und Cypress

Überschriften lassen sich gut automatisiert prüfen. axe-core bringt dafür eigene Regeln mit: heading-order meldet übersprungene Ebenen, empty-heading findet leere Überschriften, page-has-heading-one prüft, ob eine h1 existiert. Die ersten beiden laufen als Best Practice Regeln, sie müssen im Setup aktiviert sein. In unserem Überblick zu Accessibility Testing Tools 2026 steht, wie axe, Pa11y und Lighthouse zusammenspielen.
In Cypress sieht ein Test mit cypress-axe so aus:
Code: 
          
describe('Barrierefreie Headlines', () => {
  it('hat eine saubere Heading Hierarchie', () => {
    cy.visit('/glossare/nca-glossar-barrierefreiheit/barrierefreie-headlines');
    cy.injectAxe();
    cy.checkA11y(null, {
      runOnly: ['heading-order', 'empty-heading', 'page-has-heading-one'],
    });
  });

  it('hat genau eine h1', () => {
    cy.get('h1').should('have.length', 1);
  });
});
Der zweite Test ist bewusst simpel. Er braucht kein axe und schlägt trotzdem sofort an, wenn ein Template zwei h1 rendert. Solche Guardrails laufen bei uns in jeder Pipeline mit GitHub Actions oder GitLab CI, die Ergebnisse landen in Cypress Cloud.
Was Automatisierung nicht prüft: ob eine Überschrift inhaltlich sinnvoll ist. Ein h2 mit dem Text „Mehr“ ist technisch korrekt und für Screenreader Nutzer wertlos. Dafür bleibt der manuelle Test mit Tastatur und Screenreader Pflicht, wie ihn Accessibility Testing beschreibt. Ergänzend zeigt der Accessibility Inspector in den Firefox Accessibility Testing Tools die Überschriftenliste so, wie ein Screenreader sie sieht.

Überschriftenebenen im Vergleich: Aufgabe und typischer Fehler

Ebene Aufgabe Typischer Fehler
h1 Thema der gesamten Seite, genau einmal, deckt sich mit dem Seitentitel Logo oder Site Name als h1 auf jeder Seite, zweite h1 im Hero Block
h2 Hauptabschnitte, bilden das Inhaltsverzeichnis der Seite Nur eine h2, danach direkt h4; h2 für Teaser Cards fest in der Komponente
h3 Unterabschnitte innerhalb eines h2 Blocks h3 ohne übergeordnete h2, weil der Abschnitt aus dem Design heraus zu klein wirkte
h4 bis h6 Feingliederung bei langen Fachtexten, selten nötig Einsatz als Stilmittel für Kleingedrucktes, Footer Spalten oder Labels

Gute Headlines schreiben: Klar, kurz, aussagekräftig

Die Technik ist die eine Hälfte. Die andere ist der Text. WCAG 2.4.6 verlangt, dass Überschriften Thema oder Zweck beschreiben. Für die Praxis heißt das: Wer nur die Überschriftenliste hört, muss verstehen, worum es in jedem Abschnitt geht.
  • Konkret statt kreativ. „Preise“ ist besser als „Was es kostet, mit uns zu arbeiten“. Screenreader Nutzer hören dutzende Überschriften nacheinander, jede sollte in zwei Sekunden verständlich sein.
  • Vorne das Wichtigste. Das Schlüsselwort steht am Anfang. So greift auch die Überschriftenliste, wenn lange Titel abgeschnitten werden.
  • Keine Wiederholungen. Fünf Blöcke mit dem Titel „Mehr erfahren“ sind für die Navigation nutzlos. Jede Überschrift ist einmalig auf der Seite.
  • Verständliche Sprache. Kurze Wörter, keine Abkürzungen ohne Erklärung. Das kommt allen zugute, nicht nur Menschen, die auf Leichte Sprache oder Einfache Sprache angewiesen sind.
Ein guter Selbsttest: Kopiert alle Überschriften einer Seite untereinander in ein Textdokument. Ergibt die Liste ohne Fließtext eine sinnvolle Gliederung, ist die Seite gut strukturiert. Bleibt sie unverständlich, hört ein Screenreader Nutzer genau dieses Durcheinander.

Headings, for example are a very common way to navigate around a webpage for me.

Léonie Watson, Director TetraLogical, W3C Board of Directors – via The Informed Life Podcast, Episode 106

Barrierefreie Headlines in NCA Projekten

In unseren Sulu Projekten legt das Template die h1 fest, jeder Content Block bringt seine h2 mit, und Unterpunkte innerhalb eines Blocks bleiben h3. Redakteure können Blöcke frei sortieren, ohne die Hierarchie zu brechen. Diese Regel ist einfach, hält seit Jahren und spart in jedem Accessibility Audit Zeit.
Beim Einstieg in bestehende Projekte prüfen wir Überschriften als Erstes. Sie sind schnell zu messen, schnell zu reparieren und ihr Effekt ist sofort spürbar, für Screenreader Nutzer genauso wie im Ranking. Erst danach folgen Keyboard Navigation, ARIA und Farbkontrast.
Wir helfen Teams, Heading Regeln in Komponenten zu gießen, cypress-axe in die Pipeline zu bringen und Redaktionen so zu schulen, dass saubere Struktur zur Gewohnheit wird. Das Ziel ist immer dasselbe: Die Seite erfüllt die Anforderungen aus BFSG und European Accessibility Act, ohne dass jemand daran denken muss. Alle Begriffe rund um das Thema findet ihr im NCA Glossar für Barrierefreiheit.
CYPRESS.IO Ambassador und IT Consultant für QA Engenieering und Qualität in PHP Projekten.
Erreichen Sie unsere Spezialisten zu barrierefreien Webdesign

Wir sind hier, um Ihnen zu helfen. Gemeinsam meistern wir Ihre digitalen Herausforderungen und fördern die Inklusion im Internet. Lassen Sie uns Ihre Projekte mit barrierefreiem Webdesign erfolgreich machen.

Kostenlose Demo Jetzt anrufen

Häufige Fragen zu barrierefreien Headlines

Die wichtigsten Fragen zu Überschriften, Screenreadern und WCAG 2.2 kurz beantwortet.
Was sind barrierefreie Headlines 2026?

Barrierefreie Headlines sind Überschriften, die als echte h1 bis h6 Tags im HTML stehen und eine lückenlose Hierarchie bilden. Screenreader nutzen sie zum Springen durch die Seite. 2026 gilt das in Deutschland über das BFSG für viele Onlineshops und Dienste verbindlich, geprüft wird nach WCAG 2.2, Kriterien 1.3.1 und 2.4.6.

Wie viele h1 darf eine Seite 2026 haben?

Genau eine. HTML verbietet mehrere h1 nicht, aber Screenreader Nutzer erwarten eine einzige Überschrift, die das Thema der Seite benennt. Suchmaschinen bewerten mehrere h1 ebenfalls als unklare Struktur. Typische Fehlerquelle sind Logos oder Hero Blöcke, die zusätzlich als h1 gerendert werden.

Welche WCAG 2.2 Kriterien betreffen Überschriften 2026?

Drei Kriterien sind relevant: 1.3.1 Info und Beziehungen (Level A) verlangt programmatisch erkennbare Struktur. 2.4.6 Überschriften und Beschriftungen (Level AA) fordert beschreibende Texte. 2.4.10 Abschnittsüberschriften (Level AAA) empfiehlt, jeden Inhaltsabschnitt mit einer Überschrift zu versehen. BFSG verlangt Level AA.

Wie teste ich Überschriften 2026 automatisiert?

Mit axe-core Regeln wie heading-order, empty-heading und page-has-heading-one, zum Beispiel über cypress-axe in Cypress oder über Pa11y in der CI Pipeline. Die Regeln heading-order und empty-heading gelten als Best Practice und müssen im Setup aktiviert sein. Ergänzend prüft ein simpler Cypress Test, dass genau eine h1 existiert.

Warum sind barrierefreie Headlines 2026 auch für SEO und KI Suche wichtig?

Suchmaschinen gewichten Inhalte entlang der Überschriftenstruktur. KI Suche und LLMs zerlegen Seiten in Abschnitte, die von Überschriften begrenzt werden. Eine saubere Hierarchie erhöht die Chance, dass ein Abschnitt als Antwort zitiert wird. Barrierefreiheit, SEO und LLMO profitieren hier von derselben Maßnahme.

Darf ich eine Überschriftenebene überspringen?

Nach unten nicht. Auf eine h2 folgt eine h3, nie direkt eine h4. Nach oben ist Springen erlaubt, etwa von h4 zurück auf h2, wenn ein neuer Hauptabschnitt beginnt. Übersprungene Ebenen wirken für Screenreader Nutzer wie fehlende Kapitel und werden von axe-core als heading-order Verstoß gemeldet.

Kann ich h Tags für die Optik nutzen?

Nein. Die Ebene folgt der Gliederung, die Optik regelt CSS. Wenn eine h3 zu klein aussieht, bekommt sie eine Klasse mit größerer Schrift. Wer stattdessen eine h2 setzt, zerstört die Struktur für Screenreader. Umgekehrt ist ein fetter Absatz keine Überschrift, auch wenn er wie eine aussieht.

Wie löse ich das Heading Problem in wiederverwendbaren Komponenten?

Die Komponente bekommt die Ebene als Property und rendert das passende Tag dynamisch. In React über ein berechnetes Tag wie h plus Level, in Vue über component :is, in Astro über eine Property. So entscheidet die Seite über die Ebene, nicht die Komponente. Fest verdrahtete h2 in Cards sind der häufigste Strukturfehler in modernen Frontends.

Was ist eine visuell versteckte Überschrift?

Eine Überschrift, die per CSS aus dem sichtbaren Bereich geschoben wird, aber im Accessibility Tree bleibt. Sie hilft Screenreader Nutzern, etwa über einer Navigationsliste ohne sichtbaren Titel. Wichtig: display none oder visibility hidden entfernen die Überschrift auch für Screenreader. Es braucht eine echte visually hidden Klasse.

Wie sollte eine gute Überschrift formuliert sein?

Kurz, konkret und einmalig auf der Seite. Das Schlüsselwort steht am Anfang, damit es in der Überschriftenliste sofort verständlich ist. Kreative Umschreibungen oder wiederholte Texte wie Mehr erfahren sind für die Navigation nutzlos. Ein guter Test: Alle Überschriften untereinander gelesen ergeben eine sinnvolle Gliederung.

Wie navigieren Screenreader Nutzer mit Überschriften?

Screenreader wie NVDA, JAWS oder VoiceOver bieten eine Überschriftenliste und Schnelltasten. Die Taste H springt zur nächsten Überschrift, die Zahlen 1 bis 6 direkt zu einer Ebene. So überfliegen blinde Nutzer eine Seite ähnlich schnell wie Sehende. Ohne echte Heading Tags funktioniert keine dieser Techniken.

Reicht ein automatisierter Test für barrierefreie Headlines aus?

Nein. Automatisierung findet fehlende h1, übersprungene Ebenen und leere Überschriften zuverlässig. Ob eine Überschrift inhaltlich sinnvoll ist, erkennt kein Tool. Dafür braucht es den manuellen Test mit Screenreader oder mindestens den Blick in die Überschriftenliste des Accessibility Inspectors. Beides zusammen ergibt ein belastbares Ergebnis.