NCA Social Media
Erstellt:
Aktualisiert:
Autor:
Roland Golla
Grüne isometrische Bausteine für header, nav, main und footer

Was ist Semantic HTML?

Semantic HTML (semantisches HTML) bedeutet, HTML Elemente nach ihrer Bedeutung einzusetzen und nicht nach ihrem Aussehen. Ein Button ist ein button, eine Navigation ein nav, eine Überschrift ein h2. Browser, Screenreader, Suchmaschinen und KI Agenten lesen daraus die Struktur einer Seite.

Das Gegenteil ist die sogenannte div Suppe: Seiten, die fast nur aus div und span bestehen und ihre Bedeutung allein über CSS Klassen und JavaScript bekommen. Für sehende Mausnutzer sieht das gleich aus. Für alle anderen fehlt die Hälfte der Information.

Semantisches HTML ist die günstigste Form von Barrierefreiheit. Es kostet keine Extra Zeile Code, bringt Tastaturbedienung, Fokus und Screenreader Ansagen gratis mit und erfüllt viele WCAG 2.2 Kriterien automatisch.

Inhalt

Semantik im Code Review: Hilfe von NCA

Semantisches HTML ist bei uns keine Theorie, sondern der erste Blick in jedem Code Review. Ob Astro Komponente oder Twig Template für Symfony und Sulu: Wer mit den richtigen Elementen startet, spart sich später ARIA Workarounds und Bugfixes.

In bestehenden Projekten suchen wir gezielt nach div Nachbauten, fehlenden Landmarks und kaputten Überschriftenhierarchien und ersetzen sie Komponente für Komponente. Neue Projekte starten bei uns mit einer semantisch sauberen Basis, etwa mit Accessible Astro Components. Wo HTML nicht reicht, setzen wir ARIA gezielt und sparsam ein. Für Überschriften greifen wir auf unsere Erfahrung mit barrierefreien Überschriftenstrukturen zurück. Den Stand halten wir mit einem Accessibility Audit und Struktur Tests im Rahmen unseres barrierefreien Webdesigns fest.

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

Was der Accessibility Tree aus HTML macht

Ein Screenreader sieht keine Seite. Er liest den Accessibility Tree, eine vereinfachte Fassung des DOM, in der jedes Element eine Rolle, einen Namen und einen Zustand hat. Diese drei Informationen kommen zum Großteil direkt aus dem HTML Element.

Was ein natives Element automatisch mitbringt:

  • Rolle: Der Screenreader sagt Schaltfläche, Link oder Überschrift Ebene 2
  • Tastaturbedienung: Fokussierbar, per Enter oder Leertaste auslösbar
  • Navigation: Nutzer springen per Taste von Überschrift zu Überschrift oder von Landmark zu Landmark
  • Zustände: Aktiviert, deaktiviert, ausgewählt, ohne Extra Code
  • Robustheit: Funktioniert in jedem Browser und jeder assistiven Technologie

Die Zahlen zeigen, wie groß das Problem ist. Laut dem WebAIM Million Report 2026 hatten 95,9 Prozent der eine Million meistbesuchten Startseiten erkennbare WCAG Fehler. Übersprungene Überschriftenebenen fanden sich auf 41,8 Prozent der Seiten. Ein main Landmark nutzten nur 46,1 Prozent.

Die wichtigsten semantischen Elemente im Überblick

Landmarks für die Seitenstruktur:

  • header: Kopfbereich mit Logo und oft der Hauptnavigation
  • nav: Navigationsblöcke, bei mehreren mit aria-label unterscheiden
  • main: Der Hauptinhalt, genau einmal pro Seite
  • aside: Ergänzende Inhalte wie Randspalten
  • footer: Fußbereich
  • search: Neu im HTML Standard, für Suchbereiche

Elemente für den Inhalt:

  • h1 bis h6: Überschriften in logischer Hierarchie, ohne Ebenen zu überspringen
  • article und section: Eigenständige Inhalte und thematische Abschnitte
  • ul, ol, dl: Listen, der Screenreader sagt die Anzahl der Einträge an
  • table mit th und caption: Echte Datentabellen, keine Layouttabellen
  • figure und figcaption: Bilder mit Bildunterschrift

Elemente für Interaktion:

  • button für Aktionen, a href für Navigation. Nie vertauschen.
  • label für jedes Formularfeld, fieldset und legend für Gruppen
  • details und summary: Aufklapper ohne JavaScript
  • dialog: Modale Dialoge mit eingebautem Fokus Management

Zwischen div Suppe und getesteter Struktur

Kaum ein Projekt startet bei null oder ist perfekt. Die meisten Seiten stehen irgendwo dazwischen. Diese vier Stufen helfen bei der Einordnung und zeigen den nächsten sinnvollen Schritt.

Semantik Reifegrad: Merkmale und Werkzeuge

Level Merkmale Werkzeuge
1 div Suppe Fast nur div und span, Klick Handler auf beliebigen Elementen, Überschriften nur optisch Keine, Bedeutung nur über CSS Klassen
2 Grundstruktur Landmarks wie header, nav, main, footer und eine saubere Überschriftenhierarchie HTML Validator, Browser DevTools
3 Native Interaktion button, a, label, dialog und details statt Nachbauten, ARIA nur wo HTML nicht reicht axe DevTools, Accessibility Tree im Browser
4 Getestet Struktur und Rollen laufen als automatisierte Tests in der Pipeline Cypress mit axe core, GitHub Actions oder GitLab CI

Semantisches HTML in der Praxis: Code Beispiele

Das Seitengerüst. Mit wenigen Landmarks können Screenreader Nutzer direkt zu Navigation, Inhalt oder Suche springen.

Code: 
          
<body>
  <header>
    <a href="/">Never Code Alone</a>
    <nav aria-label="Hauptnavigation">...</nav>
  </header>

  <main>
    <h1>Semantisches HTML</h1>
    <article>
      <h2>Warum Semantik zählt</h2>
      <p>...</p>
    </article>
  </main>

  <footer>...</footer>
</body>

Button statt div. Der Nachbau braucht Rolle, tabindex und zwei Event Handler, um halbwegs zu funktionieren. Das native Element kann alles von Haus aus.

Code: 
          
<!-- Nachbau: viel Code, trotzdem fehleranfällig -->
<div role="button" tabindex="0"
     onclick="save()" onkeydown="handleKey(event)">
  Speichern
</div>

<!-- Nativ: alles eingebaut -->
<button type="button" onclick="save()">Speichern</button>

Aufklapper ohne JavaScript. FAQ Bereiche und Akkordeons lassen sich mit details und summary bauen. Zustand, Tastatur und Screenreader Ansage liefert der Browser.

Code: 
          
<details>
  <summary>Was ist semantisches HTML?</summary>
  <p>HTML Elemente nach Bedeutung statt nach Aussehen.</p>
</details>

Formularfelder mit echtem Label. Ein Platzhalter ersetzt kein Label. Er verschwindet beim Tippen und wird nicht zuverlässig vorgelesen. Mehr dazu bei den barrierefreien Formularen.

Code: 
          
<label for="email">Mail Adresse</label>
<input id="email" type="email" autocomplete="email" required>

Semantisches HTML mit Cypress absichern

Semantik geht leise kaputt. Ein Refactoring macht aus dem button ein gestyltes div, ein neues Layout verliert das main. Niemand merkt es, bis der nächste Audit kommt. Mit ein paar Cypress Tests fällt das beim Pull Request auf.

Code: 
          
describe('Semantische Struktur', () => {
  beforeEach(() => cy.visit('/'))

  it('hat genau ein main und ein h1', () => {
    cy.get('main').should('have.length', 1)
    cy.get('h1').should('have.length', 1)
  })

  it('überspringt keine Überschriftenebenen', () => {
    cy.get('h1, h2, h3, h4, h5, h6').then(($h) => {
      const levels = [...$h].map((el) => Number(el.tagName[1]))
      levels.slice(1).forEach((level, i) => {
        expect(level - levels[i]).to.be.at.most(1)
      })
    })
  })

  it('hat keine Axe Verstöße', () => {
    cy.injectAxe()
    cy.checkA11y()
  })
})

Der letzte Test nutzt das Plugin cypress axe mit axe core. Es findet unter anderem fehlende Labels, doppelte IDs und falsche ARIA Rollen. Wie das Setup genau aussieht, zeigen wir bei axe DevTools und Cypress.

Semantik Fallen aus dem Entwicklungsalltag

  1. Überschriften nach Optik gewählt. Ein h4, weil er schön klein ist. Die Hierarchie ist danach kaputt.
  2. Links, die Aktionen auslösen. a href="#" mit Click Handler statt button.
  3. ARIA als Pflaster. role="button" auf einem div, statt gleich einen Button zu nehmen. Der WebAIM Report 2026 zeigt: Seiten mit ARIA hatten im Schnitt mehr Fehler als Seiten ohne.
  4. Layouttabellen. Tabellen für Spalten Layouts statt CSS Grid oder Flexbox.
  5. Mehrere h1 oder gar keins. Laut WebAIM hatten 18,1 Prozent der Startseiten mehr als ein h1.
  6. Placeholder statt Label. Formularfelder ohne dauerhaft sichtbare Beschriftung.

Die meisten dieser Fehler entstehen nicht aus Unwissen, sondern aus Komponentenbibliotheken und CSS Frameworks, die optisch sauber, aber semantisch leer sind. Ein Blick in den Accessibility Tree der Browser DevTools zeigt schnell, was wirklich ankommt.

Home pages with ARIA present had significantly more errors.

Jared Smith, Co-Direktor WebAIM – WebAIM Million 2026 Report

Erst HTML, dann CSS, dann ARIA

Unsere Faustregel: Erst das richtige HTML Element suchen, dann CSS, und ARIA nur, wenn es wirklich kein passendes Element gibt. Diese Reihenfolge löst die meisten Barrieren, bevor sie entstehen. Sie ist auch die Grundlage für saubere Tastaturnavigation, eine korrekte Lesereihenfolge und die Kernkonzepte Name, Rolle, Zustand.

Semantik zahlt auf die Robustheit ein, eines der vier POUR Prinzipien. Wer tiefer einsteigen will, findet bei den barrierefreien Headlines, beim Alt Text und bei CSS und Barrierefreiheit die nächsten Schritte.

Ein Nebeneffekt, der 2026 immer wichtiger wird: Semantisches HTML hilft auch Maschinen. Suchmaschinen verstehen die Struktur besser, und KI Agenten, die Websites bedienen, orientieren sich an denselben Rollen und Namen. Mehr dazu bei der Agent Readiness. Für die Prüfung helfen die Firefox Accessibility Tools und der Lighthouse Accessibility Audit.

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 Semantic HTML

Landmarks, Überschriften, button oder Link: kurze Antworten für den Entwicklungsalltag.

Was ist Semantic HTML 2026?

Semantic HTML bedeutet, HTML Elemente nach ihrer Bedeutung zu verwenden, also button für Aktionen, nav für Navigation und h2 für Überschriften. Browser, Screenreader, Suchmaschinen und KI Agenten lesen daraus die Struktur einer Seite. Es ist 2026 die Grundlage für WCAG 2.2 Konformität und die günstigste Form von Barrierefreiheit.

Warum ist semantisches HTML 2026 für Barrierefreiheit so wichtig?

Screenreader lesen nicht die Optik, sondern den Accessibility Tree. Rolle, Name und Zustand eines Elements kommen größtenteils direkt aus dem HTML. Native Elemente bringen Tastaturbedienung und Ansagen automatisch mit. Wer div und span nachbaut, muss all das mühsam mit ARIA und JavaScript ergänzen und macht dabei oft Fehler.

Welche WCAG 2.2 Kriterien hängen 2026 an semantischem HTML?

Vor allem 1.3.1 Info und Beziehungen, 4.1.2 Name, Rolle, Wert und 2.4.6 Überschriften und Beschriftungen. Indirekt auch 2.1.1 Tastatur, weil native Elemente automatisch bedienbar sind, und 2.4.1 Blöcke umgehen über Landmarks. Mit sauberem HTML erfüllt man viele dieser Kriterien, ohne eine Zeile ARIA zu schreiben.

Was sind Landmarks 2026 und welche brauche ich?

Landmarks sind Bereiche, zu denen Screenreader Nutzer direkt springen können. Die wichtigsten sind header, nav, main, aside, footer und das neue search Element. Jede Seite sollte genau ein main haben. Mehrere nav Bereiche unterscheidet man mit aria-label, etwa Hauptnavigation und Fußnavigation.

Hilft semantisches HTML 2026 auch bei SEO?

Ja. Suchmaschinen erkennen über Überschriften, main, article und Listen besser, worum es auf einer Seite geht und was der Hauptinhalt ist. Auch KI Suchsysteme und Agenten orientieren sich an dieser Struktur. Semantisches HTML ist kein Ranking Trick, aber eine saubere Basis, auf der gute Inhalte besser verstanden werden.

Wann brauche ich ARIA statt semantischem HTML?

Nur dann, wenn es für eine Funktion kein passendes HTML Element gibt. Beispiele sind Tabs, Comboboxen oder Baumansichten. Die erste Regel von ARIA lautet deshalb: Wenn ein natives Element existiert, nutze es. Falsch eingesetztes ARIA verschlechtert die Barrierefreiheit, wie der WebAIM Million Report 2026 erneut zeigt.

Was ist der Unterschied zwischen section und div?

Ein div hat keine Bedeutung und dient nur zur Gruppierung für CSS oder JavaScript. Eine section kennzeichnet einen thematischen Abschnitt, der typischerweise eine eigene Überschrift hat. Mit einem zugänglichen Namen, etwa über aria-labelledby, wird eine section sogar zum Landmark. Für reine Layoutzwecke bleibt das div die richtige Wahl.

Darf eine Seite mehrere h1 haben?

Technisch erlaubt HTML das, für Barrierefreiheit ist genau ein h1 pro Seite aber die klare Empfehlung. Screenreader Nutzer springen oft direkt zum h1, um den Seitentitel zu finden. Mehrere h1 machen die Orientierung schwerer. Danach folgt eine lückenlose Hierarchie aus h2, h3 und so weiter, ohne Ebenen zu überspringen.

Wann nehme ich button und wann a?

Ein Link mit a href führt zu einer anderen Seite oder Stelle. Ein button löst eine Aktion auf der aktuellen Seite aus, etwa Speichern, Öffnen oder In den Warenkorb. Die Regel ist wichtig, weil Screenreader beide unterschiedlich ansagen und Nutzer unterschiedliches Verhalten erwarten. Ein Link mit href Raute und Click Handler ist ein klassischer Fehler.

Wie prüfe ich, ob meine Seite semantisch ist?

Der schnellste Weg ist der Accessibility Tree in den Browser DevTools. Er zeigt, welche Rolle und welchen Namen jedes Element für Screenreader hat. Dazu kommen automatisierte Checks mit axe DevTools oder Lighthouse und ein kurzer Test mit einem Screenreader wie NVDA oder VoiceOver. Für Regressionen eignen sich Cypress Tests mit axe core.

Sind Komponentenbibliotheken semantisch?

Das ist sehr unterschiedlich. Manche Bibliotheken setzen konsequent auf native Elemente und ARIA Patterns, andere liefern optisch saubere, aber semantisch leere div Strukturen. Vor dem Einsatz lohnt ein Blick in den Accessibility Tree und in die Dokumentation zur Barrierefreiheit. Für Astro sind die Accessible Astro Components ein gutes Beispiel.

Ist details und summary barrierefrei?

Ja, das native Aufklapp Element wird von modernen Browsern und Screenreadern gut unterstützt. Es ist per Tastatur bedienbar und sagt den Zustand offen oder geschlossen an. Für einfache Akkordeons und FAQ Bereiche ist es oft die robustere Wahl gegenüber einem Nachbau mit JavaScript und ARIA. Nur beim Styling sollte man den Marker nicht ersatzlos entfernen.

Was bringt semantisches HTML für KI Agenten?

KI Agenten, die Websites selbstständig bedienen, lesen häufig den Accessibility Tree oder das DOM und orientieren sich an Rollen und Namen. Ein echter Button mit klarem Text ist für sie genauso leicht zu finden wie für einen Screenreader. Ein unbeschriftetes div mit Click Handler dagegen nicht. Barrierefreiheit und Agent Readiness gehen hier Hand in Hand.