Die Überschriftenhierarchie.

Die Überschriftenhierarchie ist die Ordnung der h1–h6-Elemente einer Seite, sodass sie die Dokumentstruktur richtig spiegeln — sie ist das Inhaltsverzeichnis des Screenreader-Nutzers.

Für sehende Nutzer sind Überschriften ein typografisches Signal: Was groß und fett ist, beginnt einen Abschnitt. Für Screenreader-Nutzer sind Überschriften ein Navigationswerkzeug — mit einer Taste springen sie von Überschrift zu Überschrift und erschließen die Struktur der Seite durch Hören. Eine Überschriftenebene ist deshalb keine visuelle, sondern eine strukturelle Entscheidung.

Das Problem beginnt meist so: Eine Überschrift soll visuell kleiner wirken, also wird ihre Ebene gesenkt. Ein Text, der Abschnittsüberschrift sein müsste, wird h4, weil das h2 zu groß aussieht. Das visuelle Ergebnis ist das gewollte; das strukturelle ist ein kaputter Dokumentbaum.

Die Regeln

Die Regeln der Überschriftenhierarchie sind wenige, und alle sind testbar. Komplex sind nicht die Regeln, sondern ihre Einhaltung auf einer bestehenden Website.

1. Ein h1 pro Seite — es sagt, worum es auf der Seite geht. Meist der Haupttitel.
2. Abwärts wird nicht übersprungen — nach h2 kommt kein h4. Beim Hinabsteigen je eine Stufe.
3. Aufwärts darf übersprungen werden — nach h4 kann h2 kommen; ein neuer Oberabschnitt hat begonnen.
4. Die visuelle Größe ist von der Ebene unabhängig — ein h3 darf so klein aussehen wie gewünscht; die Größe regelt das CSS.
5. Eine Überschrift muss wirklich eine sein — ein fett gesetzter Absatz ist keine Überschrift; ein Abschnitt ohne Überschriftselement ist für den Screenreader kein Abschnitt.
6. Keine leeren Überschriften — eine Überschrift mit Icon, aber ohne Text erzeugt in der Navigationsliste eine leere Zeile.

Die zweite Regel wird am häufigsten gebrochen, und fast immer aus visuellen Gründen. Die Lösung ist einfach: die Ebene richtig wählen, die Größe mit CSS regeln. An einem h2 mit 18 Pixeln ist nichts falsch; an einem h4 an der Stelle eines h2 schon.

Was im Screenreader geschieht

Um zu verstehen, warum die Regeln zählen, muss man sehen, was eine kaputte Hierarchie im Hörerlebnis erzeugt. Landet ein Screenreader-Nutzer auf einer Seite, ist einer seiner ersten Schritte das Öffnen der Überschriftenliste — des Inhaltsverzeichnisses der Seite.

Stimmt die Hierarchie, zeigt die Liste die Struktur der Seite: der Haupttitel, darunter die Abschnitte, darunter die Unterabschnitte. Der Nutzer springt direkt zum Abschnitt, der ihn interessiert. Ist die Hierarchie kaputt, wird die Liste sinnlos — Einzüge an falschen Stellen, Abschnitte, die wie Unterabschnitte aussehen, Unterabschnitte wie Hauptabschnitte.

Schlimmer sind Abschnitte ganz ohne Überschriftselement. Ein groß und fett gesetzter, aber als Absatz ausgezeichneter Text ist für den sehenden Nutzer eine Überschrift, für den Screenreader nicht. Dieser Abschnitt erscheint nie in der Navigationsliste und lässt sich nicht anspringen — für jemanden, der hörend navigiert, verschwindet dieser Teil der Seite praktisch.

Ein fett gesetzter Absatz ist für den Screenreader keine Überschrift; dieser Abschnitt der Seite steht schlicht nicht in der Liste.

Die h1-Debatte

„Wie viele h1 soll eine Seite haben“ wird seit Langem diskutiert, mit zwei Antworten im Umlauf: Nach dem HTML5-Outline-Algorithmus darf jeder Abschnitt sein eigenes h1 tragen; nach dem klassischen Ansatz gehört auf eine Seite ein einziges h1.

Die praktische Antwort ist klar: Verwenden Sie ein einziges h1. Der Outline-Algorithmus von HTML5 wurde von keinem Browser und keinem Screenreader je wirklich umgesetzt und aus der Spezifikation entfernt. Eine Seite mit mehreren h1 erzeugt in der Hilfstechnologie eine flache Liste, und die Hierarchie geht verloren.

Auf dieser Website schützt der Code die Regel: Das Messwerkzeug zählt auf JEDER generierten Seite die h1 und die Hierarchiesprünge. In der letzten Messung gibt es keine Seite mit einer h1-Zahl ungleich eins und keinen Hierarchiesprung — beides null. Die Regel lebt in einem Test, nicht in einem Styleguide.

Wie geprüft wird

Die Überschriftenhierarchie zu prüfen ist der leichteste, sich am schnellsten auszahlende Teil einer Barrierefreiheitsprüfung. Es gibt drei Methoden, jede dauert wenige Minuten.

1. Mit einer Browser-Erweiterung eine Gliederung ziehen — Erweiterungen, die die Überschriften mit ihren Ebenen listen, zeigen die Sprünge sofort.
2. Mit einem kurzen Skript durchmustern — Überschriften in Quellreihenfolge sammeln und aufeinanderfolgende Ebenensprünge größer 1 melden ist Arbeit weniger Zeilen, und es durchmustert die ganze Website.
3. Die Überschriftenliste des Screenreaders öffnen — das ist die echte Verifikation. Erzählt die Liste die Seite, oder ist sie durcheinander?

Die zweite Methode ist als automatisierbare die dauerhafteste. Eine einmal von Hand gerichtete Hierarchie bricht mit den nächsten Inhaltseingaben wieder — besonders in Systemen, in denen Redakteure die Ebenen selbst wählen. Läuft die Musterung bei jedem Deployment, zeigt sich der Bruch sofort.

Eine letzte Anmerkung: Die Überschriftenhierarchie ist kein auf Barrierefreiheit begrenzter Gewinn. Auch Suchmaschinen leiten die Dokumentstruktur aus den Überschriften ab, und Antwortmaschinen nehmen beim Zitieren die Abschnitte unter Überschriften als Einheit. Eine korrekte Hierarchie dient drei Lesern zugleich: dem Menschen, dem Crawler und dem Modell.

Zerfall in Inhaltssystemen

Der Ort, an dem die Überschriftenhierarchie am häufigsten bricht, ist nicht der Code, sondern die Eingabeoberfläche. Die meisten Rich-Text-Editoren lassen Redakteure die Ebene frei wählen, und gewählt wird nach der visuellen Vorschau — „das wirkt zu groß, machen wir es kleiner“. Das Ergebnis ist ein kaputter Dokumentbaum auf einer Seite, die das technische Team nie berührt hat.

Die dauerhafte Lösung ist, die Wahl zu beschränken. Liefert der Inhaltsbereich das h1 der Seite ohnehin, sollte der Editor h1 gar nicht anbieten. Ebenso lässt sich das Springen zwei Stufen unter die aktuell tiefste Ebene in der Oberfläche verhindern. Dem Redakteur weniger Optionen zu geben ist hier keine Einschränkung, sondern eine Erleichterung — denn die richtige Wahl ist ohnehin eine einzige Option.

Wo Beschränken nicht möglich ist, ist die zweite Verteidigungslinie die Messung. Eine Kontrolle, die veröffentlichte Seiten auf die Hierarchie durchmustert und bei Sprüngen warnt, meldet das Problem an den Redakteur zurück. Auf dieser Website lebt diese Kontrolle im Messwerkzeug und durchmustert bei jedem Lauf sämtliche generierten Seiten.

Visuelle Größe und Ebene trennen

Im Kern der Überschriften-Debatte liegt eine praktische Spannung: Die Gestaltung will eine visuelle Skala, die Entwicklung eine strukturelle Ebene, und HTML drückt beides mit demselben Element aus. Die Spannung löst sich, indem man die Skala von der Ebene trennt.

Die Methode: Überschriftselemente bestimmen nur die STRUKTUR und tragen kein Standardaussehen. Die visuelle Größe kommt aus einer eigenen Klasse. So kann ein h2 groß oder klein aussehen, und die Gestaltung muss die Ebene nie ändern. Diese Trennung ist in Designsystemen ein Standardmuster und löst die meisten Hierarchieprobleme an der Quelle.

Auf dieser Website ist die Typografieskala auf Token-Ebene definiert und wird unabhängig von der Überschriftenebene angewandt. Bühnenüberschriften tragen ihre eigenen Skalen, Fließtextüberschriften ihre — aber die HTML-Ebene beider wird nach der Dokumentstruktur gewählt, nicht nach der Größe, in der sie erscheinen.

Die Ebene erzählt die Struktur, die Größe das Aussehen. Beides ist nicht dasselbe und darf nicht aus derselben Quelle kommen.