Heading for Greatness — Ein React-Entwickler-Guide zu HTML-Headings

Hinweis: Dieser Artikel wurde unter Zuhilfenahme von KI aus dem Englischen übersetzt. Hier geht's zum Originaltext.

Die HTML-Überschriften h1 bis h6 gehören zu den grundlegendsten Bausteinen für die Strukturierung von Inhalten im Browser. Sie existieren schon seit 1991, als Tim Berners-Lee sie in seinen ersten Entwurf von "HTML" aufnahm. Einige Jahre später verfassten Berners-Lee und sein Kollege Dan Connolly den ersten Vorschlag für eine offizielle HTML-Spezifikation. Darin wird bereits eine Praxis erwähnt, die jeder Webentwickler kennen sollte, aber die zu oft nicht befolgt wird:

Wenn du hier aufhörst zu lesen, nimm diese Botschaft mit: Verwende genau ein <h1> pro Seite und überspringe keine Überschriftsebenen!

Typischerweise werden diese Überschriften mit absteigender typografischer Betonung gestaltet: h1 ist groß und fett (sehr auffällig), h2 etwas weniger und so weiter. Wenn dein Inhalt wie dieser Artikel oder ein wissenschaftlicher Text ist, ist der Grund dafür offensichtlich: Es hilft dem Leser, die hierarchische Struktur deines Inhalts zu verstehen.

Der zweite Grund ist die maschinelle Lesbarkeit: Richtig gesetzte Überschriften beschreiben den Umriss deines Dokuments auf eine Weise, die geeignet ist für...

• Unterstützende Technologien (z.B. Screenreader für sehbehinderte Nutzer) und
• Crawler wie den Google-Bot. Glücklicherweise gehen gute Barrierefreiheit und gute SEO oft Hand in Hand 💪
• Automatische Inhaltsverzeichnisgenerierung
• Nutzung in beliebten Test-Frameworks, zum Beispiel page.getByRole("heading", ...) in Playwright

In solchen Dokumenten sind das verwendete DOM-Element (z.B. <h2>) und das darauf angewendete Styling (z.B. fett, großer Text, vielleicht in einer anderen Farbe) eng miteinander verbunden. Der Umriss des Dokuments manifestiert sich sowohl auf der semantischen Ebene (dem DOM, dem "versteckten Umriss" sozusagen) als auch auf der visuellen Ebene (was du tatsächlich auf dem Bildschirm sehen kannst).

Probleme treten tendenziell auf Seiten auf, die nicht rein textgetrieben sind. Zum Beispiel Marketing-Seiten, E-Commerce-Seiten, Landing Pages, ... Diese Seiten sind typischerweise designorientiert mit gerade genug Text, um etwas zu verkaufen. Sie müssen ästhetisch ansprechend und prägnant sein. Infolgedessen sind sie oft für Screenreader nicht leicht zu konsumieren.

Der Großteil des Webs ist für sehende Nutzer gemacht, die selten von der Semantik von HTML betroffen sind. Wenn wir als Webentwickler nicht aktiv versuchen, Nutzer von Hilfstechnologien im Auge zu behalten, wenn wir ein Design implementieren, wird es niemand sonst tun. Das sollte auch Designer betreffen!

Es gibt verschiedene Arten von Problemen, und jedes hat eine Lösung:

Dies ist der häufigste Fehler, den Entwickler machen: Eine typografische Wahl übersetzt sich nicht automatisch in eine Überschriftsebene. Nur weil ein Text auf einer Seite auf diese Weise betont wird, ist er nicht unbedingt eine bestimmte Art von Überschrift. Mit anderen Worten: Greif nicht nur deshalb zu diesem <h2>, weil dieser Text groß und fett ist!

Wenn man am Look and Feel eines Projekts arbeitet, entwickeln Designer oft typografische Stile und Skalen. Diese werden oft auch als "h1", "h2" und so weiter bezeichnet — meiner persönlichen Meinung nach ist das ein Fehler. Wir verbinden zu viel semantische Bedeutung mit dem Namen eines bestimmten Stils. Ich würde lieber abstraktere Namen für diese Stile finden, wie "text-xl".

Bei der Implementierung würde das bedeuten, dass du ein CSS-Reset verwenden solltest, um die Ausgangsbasis zu nivellieren und dann nur Styling auf Basis von Klassen anzuwenden, nicht auf Elementnamen:

Die meisten UI-Bibliotheken, die Typografie-Komponenten anbieten, machen es genauso:

Kein Problem, du kannst immer eine unsichtbare Überschrift hinzufügen:

CSS schamlos von Tailwind geklaut ❤️

Auch die UI-Bibliotheken kennen das:

Das ist knifflig. Wenn du entscheidest, welche Überschriftsebene du innerhalb einer Komponente verwendest, schränkst du die Komponente immer auf einen bestimmten Kontext innerhalb der Dokumentstruktur ein. Aber Komponenten werden oft an mehreren Stellen verwendet und würden eine dynamischere Handhabung ihrer Überschriftsebenen erfordern. Wie in diesem Beispiel:

Das funktioniert, fühlt sich aber etwas umständlich an.

Tenon-UI hatte dieses großartige Konzept von Überschriftsebenengrenzen, bei dem du dich nicht um die tatsächlichen Ebenen 1 bis 6 kümmern musst, sondern stattdessen deinen Komponentenbaum in semantische Abschnitte strukturierst. Da dieses Konzept in Tenon-UI eingebaut ist (das anscheinend nicht mehr weiterentwickelt wird), haben wir beschlossen, diese Idee mit unserem eigenen Paket in jeder React-basierten Anwendung nutzbar zu machen:

uberschrift (benannt nach dem deutschen Wort für "headline") gibt dir zwei Komponenten: eine, die wir <Hx> nennen (wie in "heading level x"), die du für deine Überschriften verwenden kannst, ohne überhaupt über Kontext und Ebene nachzudenken; und einen <HxBoundary>, den du verwendest, um dein Dokument zu strukturieren. Innerhalb dieser Grenzen wählt <Hx> immer die richtige Überschriftsebene. Wenn du dein Dokument eine Ebene tiefer strukturieren musst, umschließt du deine Unterkomponenten mit einem neuen <HxBoundary>. Die Einrichtung ist unkompliziert:

... wird magisch wie folgt gerendert 🪄

Es wird vollständig durch den React Context angetrieben, ist bereit für React Server Components, hat keine Abhängigkeiten, ist unter 1kb und tree-shakeable! Es ist auch mit den meisten beliebten UI-Bibliotheken verwendbar, schaue dir unsere Dokumentationsseite für eine Erklärung an oder wirf einen Blick auf unsere Beispiele.

Wenn es um Webentwicklung geht, wie bei jeder Programmierung, steckt der Teufel im Detail. Es gibt viele verschiedene Anforderungen an die Implementierung der einfachsten Dinge: SEO, Barrierefreiheit, Codequalität, ... Die ständig zunehmende Komplexität des Webs ist selbst in seinen kleinsten Elementen eingebettet. Sogar in Überschriften.

Wir hoffen, dass dieser Artikel und das Paket dir helfen werden, diese Komplexität ein wenig besser zu bewältigen.