Vom Div-Soup zum sinnvollen Markup: Ein praktischer Leitfaden für semantisches HTML

Öffnen Sie den Elementinspektor in einer typischen modernen Webanwendung – oft sehen Sie dasselbe Bild: einen tiefen, anonymen Stapel von <div>-Elementen, die jeweils nur durch einen Klassennamen identifiziert werden. Die Seite mag perfekt aussehen, doch für Screenreader, Suchmaschinencrawler sowie den nächsten Entwickler im Team sagt sie fast nichts darüber aus, um welchen Inhalt es sich handelt. Dieser Leitfaden erklärt, was Sie dadurch verlieren, welche semantischen Elemente die meisten dieser Divs ersetzen können, wie Sie sich durch die verwirrenden Entscheidungen (〈article〉 oder 〈section〉, Link oder Button) zurechtfinden und wie Sie schrittweise ein realistisches Komponentenmodell umstrukturieren.

Hier ist das Muster in seiner reinsten Form: Ein Header, Navigation, Hauptinhalt und Footer – alles als allgemeine Kästchen dargestellt.

<!-- The modern web's favorite anti-pattern -->
<div class="header">
  <div class="nav-container">
    <div class="nav-item">Home</div>
    <div class="nav-item">About</div>
  </div>
</div>
<div class="main-content">
  <div class="article-title">Stop Using Divs</div>
  <div class="article-body">
    <div class="paragraph">Divs everywhere.</div>
  </div>
</div>
<div class="footer">
  <div class="copyright">© 2026</div>
</div>

Jeder Strukturelelement in diesem Auszug befindet sich in Klassennamen. Wenn man die Klassen entfernt, bleibt nichts übrig, das einer Maschine oder einem Menschen mitteilt, wo die Navigation endet und der Artikel beginnt. Dieser Stil wird üblicherweise als „Div-Soup“ bezeichnet und ist weitaus verbreiteter, als es eigentlich der Fall sein sollte.

Warum HTML zu einem Styling-Gerüst wurde

Da Frameworks wie React, Vue, Angular und Svelte die Arbeit am Frontend dominierten und utility-first CSS das Styling nahezu mühelos machte, verlor die Markup-Sprache stillschweigend ihre ursprüngliche Funktion. HTML begann, eher als neutrales Gerüst zu dienen, auf das Klassen und Ereignishandler angehängt werden können, anstatt als Sprache zur Beschreibung von Inhalten. Das ist ein Missverständnis der Plattform: HTML wurde ursprünglich entwickelt, um Bedeutung auszudrücken – nicht als Layout-Engine.

Sobald diese Bedeutung verschwindet, breitet sich der Schaden gleichzeitig auf mehrere Bereiche aus. Assistive Technologien verlieren ihre Navigationshilfen, Suchmaschinen erhalten ein schwächeres Signal darüber, was auf der Seite wichtig ist, der Browser kann keine integrierten Funktionen mehr bereitstellen, und die Codebasis wird für Kollegen schwerer lesbar. Keines dieser Probleme ist auf einem Screenshot sichtbar – genau deshalb bestehen sie weiterhin.

Die Komponentenwurzeln verwenden standardmäßig div

Die Komponentenarchitektur teilt die Benutzeroberfläche in kleine Teile wie <Button/>, <Card/>, <Navbar/> und <Sidebar/> auf. Jede Komponente benötigt ein Wurzelelement für ihren JSX-Code, wobei <div> der einfachste Weg ist. Wenn man mehrere Komponenten übereinander anordnet, entsteht im renderierten DOM ein System aus zehn Schichten anonymer Wrapper – obwohl jede einzelne Komponente für sich genommen bereits sinnvoll aussah. (Falls Sie mit React arbeiten, sollten Sie bedenken, dass Fragmente die Notwendigkeit eines Wrappers ganz beseitigen, wenn kein Rahmen erforderlich ist.)

Hilfsklassen lenken den Fokus auf das Erscheinungsbild

CSS mit Fokus auf Funktionalität ist hervorragend für die Geschwindigkeit, legt aber den gesamten Schwerpunkt auf das Aussehen eines Elements. Wenn die Markup-Struktur <div class="flex items-center space-x-4"> lautet, wird die Frage gestellt: „Wie ist das angeordnet?“, während die Frage „Was ist das?“ nie gestellt wird. Die Wahl des Elements rückt in den Hintergrund.

Pixel sind nur die oberste Schicht

Die gefährlichste Angewohnheit ist es, seine Arbeit danach zu beurteilen, was ein Mausnutzer auf einem großen Monitor sieht. Ein <div> mit blauem Hintergrund, abgerundeten Ecken und fettgedrucktem Text sieht sicherlich wie eine Schaltfläche aus. Doch unter den dargestellten Pixeln befinden sich das DOM, der Zugänglichkeitsbaum, den der Browser für Assistenztechnologien bereitstellt, die Sichtweise des Crawlers auf das Dokument sowie die Eingabeverarbeitung durch den Browser. Für jede dieser Schichten bleibt das gestylte Div einfach nur ein Div.

Was semantisches HTML wirklich bedeutet

„Semantisch“ bezieht sich auf Bedeutung. Semantisches HTML bedeutet, Elemente zu verwenden, deren Namen die Rolle des darin enthaltenen Inhalts beschreiben, damit Browser, Assistenztechnologien und menschliche Leser den Dokumentinhalt ohne Raten verstehen können.

Generische Container

Zwei Elemente sind absichtlich bedeutungslos:

• <div> ist eine generische Blöckebene-Gruppierung.
• <span> ist eine generische Zeilen-Gruppierung.

Der Text innerhalb eines <div> kann ein Seitenüberschrift, ein Navigationsschluss, ein Absatz eines Blogbeitrags, eine Notiz in einer Seitenleiste oder eine rechtliche Haftungsausschlussklausel sein. Der Browser hat keine Möglichkeit, dies zu erkennen, weshalb er sie alle gleich behandelt.

Elemente mit Bedeutung

Semantische Elemente geben an, um was es in ihrem Inhalt geht:

• <header> enthält einleitenden Inhalt für die Seite oder einen Abschnitt, oft inklusive Navigation.
• <nav> kennzeichnet einen Block mit den wichtigsten Navigationssсылungen.
• <main> umschließt den primären, einzigartigen Inhalt der Seite.
• <article> stellt eine eigenständige Komposition wie einen Beitrag oder eine Nachricht dar.
• <section> gruppiert Inhalt um ein einziges Thema.
• <aside> enthält Material, das nur indirekt mit dem Hauptinhalt zusammenhängt, wie beispielsweise eine Seitenleiste.
• <footer> enthält abschließende Informationen wie Autorenangaben, Urheberrechte oder rechtliche Links.
• <button> ist eine interaktive Steuerelement, das eine Aktion ausführt.

Wenn der Browser auf ein <article> stößt, weiß er, dass der Inhalt für sich allein stehen kann. Wenn er auf ein <nav> stößt, weiß er, dass diese Links dazu dienen, sich auf der Seite zu bewegen. Auf diesem Wissen basiert der Rest dieses Leitfadens.

Vier Gründe, warum semantische Markierung sich lohnt

Die richtige Elementauswahl erfordert einen Moment des Nachdenkens, und ein gestyltes div zeigt dieselben Pixel an. Die Vorteile zeigen sich in vier Bereichen.

Bereichbarkeit: Orientierungspunkte und eingebaute Steuerelemente

Viele Menschen nutzen das Internet mit Bildschirmlesern wie NVDA, JAWS oder VoiceOver oder navigieren ausschließlich mit der Tastatur. Bildschirmleser ignorieren Ihren CSS. Sie arbeiten anhand des Zugänglichkeitsbaums, den der Browser aus Ihrem HTML ableitet.

Mit gut strukturierter Markup-Struktur kann der Browser Orientierungspunkte bereitstellen, und assistive Technologien können diese als eine Liste darstellen, zwischen der der Benutzer wechseln kann. Auf einer semantischen Seite sieht diese Liste ungefähr so aus:

Landmark Navigation Map:
- Header
- Navigation (3 links)
- Main Content
  - Heading 1: Stop Using Divs
  - Article
- Sidebar (Aside)
- Footer

Ein Benutzer kann mit einer einzigen Tastenkombination Dutzende von Navigationssсылungen überspringen und direkt in <main> gelangen oder direkt zum Artikel wechseln. Vergleichen Sie nun dieselbe Seite, die ausschließlich aus divs erstellt wurde:

Landmark Navigation Map:
- Division
  - Division
  - Division
- Division

In der Praxis ist die Situation sogar noch schlimmer, als dieser Überblick vermuten lässt: Einfache divs sind überhaupt keine Orientierungspunkte, sodass die Liste einfach leer ist. Der Benutzer muss Element für Element durch die Seite gehen, um das zu finden, wonach er sucht.

Buttons weisen dasselbe Problem in geringerem Maße auf. Hier ist eine falsche Schaltfläche neben einer echten:

<!-- BAD: Fake Button -->
<div class="my-button" onclick="submitForm()">Submit</div>

<!-- GOOD: Native Button -->
<button type="submit">Submit</button>

Der native <button>-Element enthält ohne zusätzliche Kosten:

• Fokussierbarkeit, sodass er in der Tab-Reihenfolge angezeigt wird.

Aktivierung mit Enter und Leerzeichen.

Eine korrekte Rolle, damit ein Bildschirmleser etwas wie „Senden, Schaltfläche“ ankündigt und der Benutzer weiß, dass eine Aktion ausgeführt wird.

Die div-Version kann keinen Fokus erhalten, reagiert nicht auf die Tastatur und wird als reiner Text vorgelesen, ohne Anhaltspunkt darauf, dass sie interaktiv ist. Damit sie sich richtig verhält, wären tabindex="0", role="button", Tastenbehandlungen für Enter und Leerzeichen, Fokussierungsstilisierung sowie Handhabung des deaktivierten Zustands erforderlich. Das ist viel Code, um etwas zu reproduzieren, was die Plattform in der Regel bereits bereitstellt – und meist unvollkommen.

Suchmaschinen: ein klareres Bild der Seite

Crawler wie Googlebot sind im Grunde spezialisierte Textleser, die herausfinden wollen, worum es auf jeder Seite geht. Semantische Struktur gibt ihnen nützliche Hinweise:

• <h1> weist auf das Hauptthema hin.
• <main> trennt den einzigartigen Inhalt von dem in jeder Seite wiederholten Header und Footer.
• <article> kennzeichnet einen eigenständigen redaktionellen Inhaltsteil.
• <nav> zeigt die interne Verlinkungsstruktur an.

Eine Seite, die aus ununterschiedlichen divs besteht, zwingt den Crawler dazu, all das allein aus Layout und Text abzuleiten. Seien Sie jedoch realistisch bezüglich der Auswirkungsgröße: Die Markup-Struktur ist nur eine von vielen Einflussfaktoren, und Suchmaschinen geben keine Regel vor, nach der semantisch korrekte Seiten höher rangiert sind. Betrachten Sie eine saubere Struktur als etwas, das es ermöglicht, Ihren Inhalt leichter zu analysieren und korrekt zu indizieren – nicht als Garantie für eine bessere Platzierung.

Wartbarkeit: Selbst dokumentierendes Markup

Code ist eine Kommunikation mit anderen Entwicklern sowie mit sich selbst Monate später. Betrachten Sie zwei Versionen derselben Gestaltung. Die erste verlässt sich ausschließlich auf Klassennamen:

<div class="top-bar">
  <div class="logo-box">...</div>
  <div class="menu-list">
    <div class="menu-item"><a href="#">Home</a></div>
    <div class="menu-item"><a href="#">Blog</a></div>
  </div>
</div>
<div class="wrapper">
  <div class="content-box">
    <div class="title-text">My Post</div>
    <div class="body-text">Hello world...</div>
  </div>
  <div class="right-bar">
    <div class="widget">...</div>
  </div>
</div>
<div class="bottom-bar">
  <div class="legal">© 2026</div>
</div>

Die zweite drückt dieselbe Struktur mit semantischen Elementen aus:

<header>
  <div class="logo">...</div>
  <nav>
    <ul>
      <li><a href="#">Home</a></li>
      <li><a href="#">Blog</a></li>
    </ul>
  </nav>
</header>
<main>
  <article>
    <h1>My Post</h1>
    <p>Hello world...</p>
  </article>
  <aside>
    <div class="widget">...</div>
  </aside>
</main>
<footer>
  <small>© 2026</small>
</footer>

In der ersten Version muss man jeden Klassennamen lesen, um die Absicht zu verstehen. Wenn jemand eine Klasse weglässt oder falsch benennt, wird die Struktur zu einer Wand aus identischen Kästen. In der zweiten Version ist die Form der Seite auf den ersten Blick erkennbar: wo sie beginnt (<header>), wo der Hauptinhalt liegt (<main>), was ergänzend ist (<aside>) und wo sie endet (<footer>). Beachten Sie außerdem, dass die Navigation zu einer echten Liste wurde, wodurch Screen Reader mitteilen können, wie viele Elemente sie enthält.

Selbstbeschreibende Markup-Elemente verringern die kognitive Belastung bei der Überprüfung und senken das Risiko, dass etwas kaputtgeht, wenn sich das Layout ändert.

Leistung und eingebautes Browserverhalten

Browser-Engines wie Chromium, Gecko und WebKit sind für Standardelemente optimiert, die bereits mit voreingestellten Styles, Ereignisverarbeitung und Zustandsverwaltung ausgestattet sind. Formularelemente sind das deutlichste Beispiel dafür. <input type="email"> und <input type="date"> stellen mobilen Nutzern eine geeignete Tastatur auf dem Bildschirm oder einen integrierten Datumsauswähler zur Verfügung, und <details> bietet ein funktionsfähiges Ansichts-Widget – all das ohne jegliches Drittanbieter-JavaScript.

Jedes Mal, wenn Sie ein Dropdown oder eine Schaltfläche aus einem Div zusammen mit Scripts neu erstellen, senden Sie zusätzlichen Code über das Netzwerk, vergrößern den Dateibündel, belasten die CPU und Batterie des Geräts stärker und schaffen ein weiteres Komponente, das Sie nun warten und testen müssen. Für eine ausführlichere Erklärung zu diesem Konzept siehe sechs native HTML-Funktionen, die gängige JavaScript-UI-Bibliotheken ersetzen.

Lösung der schwierigen semantischen Entscheidungen

Die Liste der Elemente zu kennen, ist der einfachere Teil. Die eigentliche Verwirrung entsteht durch einige Paare, die austauschbar erscheinen.

article oder section

Dies ist die Frage, über die Entwickler am meisten diskutieren. Ein nützlicher Test: Könnte dieser Inhalt von der Seite genommen, auf einer anderen Website platziert werden und dennoch vollständig verständlich bleiben? Wenn ja, verwenden Sie <article>. Wenn er nur im aktuellen Kontext Sinn ergibt, verwenden Sie <section>.

Gute Kandidaten für <article>:

• Ein Blogbeitrag oder eine Nachrichtenmeldung.
• Ein einzelner Benutzerkommentar.
• Eine Produktkarte in einem Shop-Grid.
• Ein eigenständiges Widget, wie ein Live-Wetter-Panel.

Jeder dieser Inhalte könnte verbreitet, in einen Feed aufgenommen oder ohne die umgebende Seite an anderer Stelle eingebettet werden.

Gute Kandidaten für <section>:

• Der „Über uns“-Abschnitt einer Startseite.
• Ein Kapitel in einem E-Book.
• Der Funktionen-Bereich einer Landingpage.
• Eine Gruppe von Kundenbewertungen.

Eine <section> gruppiert Inhalte unter einem Thema, weshalb sie fast immer mit einem Überschriftstext von <h2> bis <h6> beginnen sollte. Wenn Ihnen keine sinnvolle Überschrift einfällt, handelt es sich vermutlich nicht um eine Section – in diesem Fall ist <div> die richtige Wahl.

Beide Elemente lassen sich nativ ineinander verschachteln. Ein Artikel kann in Abschnitte unterteilt werden, wobei jeder Abschnitt seine eigene Überschrift hat:

<!-- Proper Nesting Example -->
<main>
  <!-- Main article describing a topic -->
  <article>
    <h1>Understanding Semantic HTML</h1>
    <p>Introductory paragraph...</p>

    <!-- Sections dividing the article into sub-topics -->
    <section>
      <h2>Why Accessibility Matters</h2>
      <p>Content about accessibility...</p>
    </section>

    <section>
      <h2>SEO Benefits</h2>
      <p>Content about SEO...</p>
    </section>
  </article>
</main>

Link oder Button

Die Verwechslung von Links und Buttons gehört zu den häufigsten Barrierefreiheitsfehlern. Die Regel ist einfach:

• Verwenden Sie <a> zusammen mit einem echten href, wenn die Aktivierung die URL ändert oder den Benutzer auf eine andere Seite oder einen anderen Ort führt.
• Verwenden Sie <button>, wenn die Aktivierung etwas auf der aktuellen Seite auslöst: Daten sendet, ein Modalfenster öffnet, ein Menü schaltet oder den Zustand auf andere Weise ändert.

Sowohl diese Arten von Fehlern als auch ihre Behebungen sind häufig:

<!-- WRONG: A link styled like a button that triggers JavaScript -->
<a href="#" onclick="openModal()">Open Modal</a>

<!-- WRONG: A button that navigates to a new webpage -->
<button onclick="window.location.href='/about'">About Us</button>

<!-- RIGHT -->
<button type="button" onclick="openModal()">Open Modal</button>
<a href="/about">About Us</a>

Der Unterschied ist wichtig, denn Sprachausgaben geben die Rolle an. „Link“ weckt die Erwartung, dass sich der Standort ändern wird; „Button“ deutet darauf hin, dass hier etwas geschehen wird. Wenn man das falsch macht, wird diese Erwartung enttäuscht. Es gibt auch praktische Nebeneffekte: Ein Link mit href="#" springt die Seite an den Anfang und kann nicht mit der Leertaste aktiviert werden, und ein Button, der navigiert, lässt sich nicht in einem neuen Tab öffnen oder seine Adresse kopieren.

Erstellung einer sinnvollen Übersicht der Überschriften

Überschriften bilden den Inhaltstext Ihrer Seite, und sowohl assistive Technologien als auch Suchmaschinen-Scrapers verlassen sich darauf. Nutzer von Sprachausgaben navigieren häufig allein anhand der Überschriften. Einige Regeln sorgen dafür, dass die Übersicht nützlich bleibt:

• Verwenden Sie ein <h1> für das Hauptthema der Seite, wie zum Beispiel den Artikeltitel oder den Namen des Dashboards. Die HTML-Spezifikation verbietet zwar nicht strikt mehrere, doch eine einzige Überschrift oberster Ebene ist die weithin empfohlene Vorgehensweise und liefert den klarsten Überblick.
• Überspringen Sie keine Ebenen. Von <h2> direkt auf <h4> zu wechseln, weil Sie kleinere Schriftgrößen wünschen, ist eine als Struktur getarnte Styling-Entscheidung; ändern Sie stattdessen die Schriftgröße mit CSS.
• Nesteln Sie logisch: Unter dem <h1>-Titel kommen die Hauptabschnitte mit <h2>, jeder mit eigenen Unterkapiteln unter <h3>, gefolgt vom nächsten <h2>.

Beachten Sie außerdem, dass das <header>-Element und die Überschriftselemente unterschiedliche Dinge sind. Ein <header> ist ein Bereich der Seite; <h1> bis <h6> sind die Titel, die den Aufbau der Seite bestimmen.

Wann ein div das richtige Werkzeug ist

Das bedeutet keineswegs, dass <div> verboten ist. Es hat eine legitime Aufgabe: den Inhalt ausschließlich zum Layout oder Styling einzubetten, wenn keine semantische Bedeutung vorliegt. Etwas mit Flexbox zentrieren, einen Abstand in einem Raster erstellen, ein gradientbeschichtetes Hintergrundbild verwenden oder eine CSS-Animation einbinden – all das sind durchaus gute Gründe, auf <div> (oder <span> für inlinesierten Inhalt) zurückzugreifen.

In der folgenden Karte werden die sinnvollen Teile mit semantischen Elementen dargestellt, während ein einzelnes div lediglich dazu dient, zwei Buttons nebeneinander anzuordnen:

<!-- PERFECTLY VALID USE OF A DIV -->
<article>
  <h1>Card Title</h1>
  <p>Card description goes here...</p>

  <!-- This div exists purely to align two buttons side-by-side with Flexbox -->
  <div class="button-group flex gap-4 mt-4">
    <button type="button">Save</button>
    <button type="button">Cancel</button>
  </div>
</article>

Die Elemente <article>, <h1>, <p> und <button> beschreiben den Inhalt; das <div> dient ausschließlich dem Layout. Das ist das ganze Prinzip in einem Satz: Verwenden Sie semantische Elemente für den Inhalt und Divs für das Layout. (Auf einer echten Seite, in der diese Karte innerhalb eines größeren Dokuments steht, wäre ihr Titel in der Regel ein <h2> oder <h3>, um zum Seitenüberblick zu passen.)

Refactoring einer Blog-Post-Karte, Schritt für Schritt

Betrachten Sie ein Kartenkomponenten, wie man sie auf fast jeder Inhaltsseite findet: ein Bild, eine Beschriftung, einen Titel, Autor und Datum, einen Auszug sowie zwei Aktionen. Hier ist die Version mit vielen Divs:

<div class="card">
  <div class="card-image">
    <img src="tech.jpg" alt="Technology background" />
    <div class="badge">Article</div>
  </div>
  <div class="card-content">
    <div class="post-title" onclick="goToPost()">10 Tips for Better Code</div>
    <div class="post-author">By Jane Doe</div>
    <div class="post-date">August 12, 2026</div>
    <div class="post-excerpt">
      Learn how to write cleaner, more maintainable frontend code today...
    </div>
    <div class="card-footer">
      <div class="share-btn" onclick="sharePost()">Share</div>
      <div class="read-more" onclick="goToPost()">Read More</div>
    </div>
  </div>
</div>

Die Probleme lassen sich leicht aufzählen, sobald man danach sucht:

• Die äußere Hülle ist ein <div>, obwohl die Karte ein eigenständiges Inhaltsstück darstellt, wofür genau <article> bestimmt ist.
• Der Titel ist ein klickbares Div, sodass Nutzer mit Tastatur nicht darauf zugreifen können und Screen Reader nicht erkennen, ob es sich um eine Überschrift oder einen Link handelt.
• Autor und Datum befinden sich in generischen Containern ohne maschinenlesbaren Sinn.
• "Teilen" und "Mehr lesen" sind falsche Buttons mit den zuvor beschriebenen Problemen bei der Nutzung der Tastatur sowie bei Ankündigungen.

Nun die überarbeitete Version:

<article class="card">
  <figure class="card-image">
    <img src="tech.jpg" alt="Abstract technology grid pattern" />
    <span class="badge">Article</span>
  </figure>

  <div class="card-content">
    <h2>
      <a href="/posts/10-tips-for-better-code">10 Tips for Better Code</a>
    </h2>

    <p class="meta-info">
      Written by <span class="author">Jane Doe</span> on
      <time datetime="2026-08-12">August 12, 2026</time>
    </p>

    <p class="post-excerpt">
      Learn how to write cleaner, more maintainable frontend code today...
    </p>

    <footer class="card-footer">
      <button type="button" onclick="sharePost()" aria-label="Share this article">
        Share
      </button>
      <a href="/posts/10-tips-for-better-code" class="btn-primary">
        Read More
      </a>
    </footer>
  </div>
</article>

Was hat sich geändert und warum hilft das:

• Die <article>-Hülle teilt Assistenztechnologien und Crawlern mit, dass die Karte ein eigenständiges Element ist.

Bild und dessen Icon werden in einer <figure> gruppiert, und der Alt-Text beschreibt nun das Bild anstelle einer allgemeinen Bezeichnung.

Der Titel ist ein echter <h2>, der eine echte Verlinkung enthält, sodass er im Übersichtsverzeichnis der Überschriften angezeigt wird, mit Tab erreichbar ist und seine Zieladresse für Crawler sichtbar macht.

Das Datum wird mit <time datetime="2026-08-12"> dargestellt, wodurch Scrapern, Übersetzungstools und Kalender-Integrationen unabhängig von der Formatierung des sichtbaren Textes ein eindeutiger, maschinenlesbarer Wert zur Verfügung steht.

"Teilen" ist ein <button>, da es auf der aktuellen Seite wirkt, während „Mehr lesen“ ein <a> ist, da es zur Navigation dient.

Die aria-label des Teilen-Buttons liefert Benutzern von Bildschirmlesern mehr Kontext darüber, was geteilt werden soll. Behalten Sie den sichtbaren Text innerhalb der Beschriftung bei, wie es hier der Fall ist („Teilen“ ist Teil von „Diesen Artikel teilen“), damit Benutzer mit Sprachsteuerung ihn trotzdem durch Aussprechen dessen, was sie sehen, aktivieren können.

Eine Verbesserung, die in Betracht gezogen werden sollte: Die Karte enthält nun zwei Links zur gleichen URL. Einige Teams behalten nur den Link zum Titel oder machen die gesamte Karte über diesen einzigen Link klickbar, damit Benutzer mit Tastatur und Bildschirmleser nicht zweimal am selben Ziel ankommen.

Gewohnheiten, die Ihre Markup-Struktur semantisch halten

Um besseren HTML zu schreiben, müssen Sie das Webentwickeln nicht neu erlernen. Ein paar routinemäßige Überprüfungen erkennen die meisten Probleme.

Führen Sie eine automatisierte Prüfung durch

Browsererweiterungen wie axe DevTools oder WAVE, die für Chrome und Firefox verfügbar sind, scannen eine Seite in Sekundenschnelle und heben Probleme wie ungültige ARIA-Attribute, fehlende Button-Typen, fehlerhafte Überschriftenreihenfolgen sowie interaktive Elemente ohne angemessene Semantik hervor. Automatisierte Tools erfassen nur einen Teil dessen, was wichtig ist, daher sollten Sie einen sauberen Bericht als Ausgangspunkt und nicht als Beweis für Barrierefreiheit betrachten.

Probieren Sie die Seite ohne CSS aus

Lassen Sie die Maus beiseite

Probieren Sie, Ihre Anwendung ausschließlich mit den Tasten Tab, Shift + Tab, Enter, Leerzeichen und Pfeiltasten zu bedienen, und überprüfen Sie Folgendes:

• Ob auf jedes interaktive Element zugegriffen werden kann.
• Ob Sie immer erkennen können, welches Element den Fokus hat.
• Ob Formulare, Dropdowns und Modale alle funktionieren.

Falls Sie bei einem div feststecken, das Enter oder Leerzeichen ignoriert, ersetzen Sie es durch ein <button>. Das ist oft eine der schnellsten Lösungen für Probleme im Bereich Barrierefreiheit.

Fragen Sie vor dem Schreiben eines div nach dessen Inhalt

Vor dem Erstellen eines neuen Containers pausieren Sie und fragen Sie sich, was sein Inhalt eigentlich darstellt:

• Navigationsbereiche erfordern <nav>.
• Eine Seitenleiste erfordert <aside>.
• Eine klickbare Aktion erfordert <button>.
• Ein eigenständiges Karten- oder Beitragselement erfordert <article>.

Der Hauptinhalt der Seite erfordert <main>.

Nur ein Layout-Wrapper ohne eigene Bedeutung erfordert <div>.

Das gilt auch innerhalb von Komponenten: Das Wurzelelement einer React-Komponente ist Teil des endgültigen Dokuments, daher sollte es mit derselben Sorgfalt gewählt werden. Weitere Informationen dazu, wie JSX und echtes HTML sich unterscheiden, finden Sie unter JSX ist nicht HTML: die wahren Kompromisse hinter Component-Markup.

Kernpunkte

• Gedruckte Pixel sind nur eine Schicht; der Zugänglichkeitsbaum, Suchmaschinen und die Eingabeverarbeitung des Browsers lesen alle Ihre Elemente – nicht Ihre Styles.
• Einheimische Elemente wie <button>, <a>, <input> und <details> bieten Fokussierung, Tastaturunterstützung, Rollen sowie ein mobiles Verhalten, die man nur mit hohem Aufwand manuell nachbauen könnte.
• Verwenden Sie <article> für Inhalte, die für sich stehen, und <section> für thematische Teile eines größeren Ganzen, und geben Sie jeder Section einen Überschriftsabschnitt.
• Links dienen zum Navigieren, Buttons zur Ausführung von Aktionen; ihre Vermischung verwirrt Benutzer und stört das erwartete Browserverhalten.
• Bewahren Sie eine klare Übersicht der Überschriftsebenen ohne übersprungenen Ebenen auf und nutzen Sie CSS anstelle von Überschriftsebenen, um die Größe zu steuern.
• Divs bleiben die richtige Wahl für reines Layout. Frameworks ändern sich alle paar Jahre, doch diese Grundlage gilt bereits seit Jahrzehnten – und Markup, das seine Bedeutung klar macht, bringt Vorteile für Benutzer, Suchmaschinen und Ihr Team.

Weitere Literatur

• Sechs native HTML-Funktionen, die gängige JavaScript-UI-Bibliotheken ersetzen — Erfahren Sie, wie popover, exclusive details, Dialogfelder, Declarative Shadow DOM, fetchpriority und datalist auf benutzerdefiniertes JavaScript verzichten lassen sowie welche Einschränkungen jede dieser Funktionen noch aufweist.
• JSX ist kein HTML: Die tatsächlichen Kompromisse hinter der Komponenten-Markup-Sprache — Erkennen Sie, was Sie aufgeben müssen, wenn das Markup in JSX umgewandelt wird – von Werkzeugen und Parsing-Verfahren über Formulare, Barrierefreiheit und Portabilität bis hin zu Mustern, die den größten Teil davon wieder zurückgewinnen.