Barrierefreiheit in HTML

Zuletzt aktualisiert am 3. Februar 2026

Barrierefreiheit (oft als a11y abgekürzt — “accessibility” mit 11 Buchstaben dazwischen) bedeutet, dass deine Website von allen Menschen genutzt werden kann. Dazu gehören Menschen mit Sehbehinderungen, motorischen Einschränkungen, Hörbeeinträchtigungen oder kognitiven Beeinträchtigungen. Die gute Nachricht: Vieles davon erreichst du automatisch, wenn du korrektes, semantisches HTML schreibst.

Warum Barrierefreiheit wichtig ist

• Menschen: Rund 15% der Weltbevölkerung lebt mit einer Form von Behinderung. Dazu kommen temporäre Einschränkungen (gebrochener Arm, Augenoperation) und situative (grelles Sonnenlicht, laute Umgebung).
• Gesetz: In der EU verpflichtet der European Accessibility Act (ab Juni 2025) viele Unternehmen zur digitalen Barrierefreiheit.
• SEO: Suchmaschinen sind im Grunde “blinde” Nutzer — sie profitieren von denselben Techniken (Alt-Texte, Überschriftenstruktur, semantisches HTML).
• Nutzererfahrung: Barrierefreie Websites sind für alle Nutzer besser — klarere Struktur, bessere Navigation, lesbarere Texte.

Semantisches HTML als Grundlage

Wie im Artikel Semantisches HTML beschrieben, ist die richtige Wahl der HTML-Elemente der wichtigste Schritt zur Barrierefreiheit. Semantische Elemente haben eingebaute Rollen, die Screenreader automatisch erkennen:

Ein <div onclick="..."> hat dagegen keine eingebaute Rolle. Ein Screenreader weiß nicht, dass es klickbar ist, und ein Tastaturnutzer kann es nicht fokussieren.

Alt-Texte für Bilder

Jedes <img>-Element braucht ein alt-Attribut. Es wird angezeigt, wenn das Bild nicht laden kann, und von Screenreadern vorgelesen:

<!-- Guter Alt-Text: beschreibt den Inhalt -->
<img src="diagramm.png"
     alt="Balkendiagramm: JavaScript 65%, Python 48%, TypeScript 35%">

<!-- Dekoratives Bild: leerer Alt-Text -->

<img src="trennlinie.svg" alt="">

<!-- Schlecht: nichtssagend -->

<img src="diagramm.png" alt="Bild">

Regeln für Alt-Texte:

• Informative Bilder: Beschreibe den Inhalt und Zweck. Was würdest du jemandem sagen, der das Bild nicht sehen kann?
• Dekorative Bilder: Verwende alt="" (leerer String). Der Screenreader überspringt das Bild dann komplett.
• Bilder mit Text: Der Text im Bild sollte im Alt-Text enthalten sein.
• Keine Redundanz: Wenn der umgebende Text dasselbe sagt, reicht alt="".
• Kein “Bild von…” nötig: Screenreader sagen automatisch “Grafik” oder “Bild” an.

Formulare zugänglich machen

Formulare sind eines der häufigsten Problemfelder bei der Barrierefreiheit. Der wichtigste Punkt: Jedes Eingabefeld braucht ein Label.

<form>
  <div>
    <label for="name-input">Name</label>
    <input type="text" id="name-input">
  </div>

  <div>
    <label for="email-input">E-Mail</label>
    <input type="email" id="email-input" required>
  </div>

  <button type="submit">Absenden</button>
</form>

Wichtige Punkte:

• Das for-Attribut des Labels muss mit der id des Inputs übereinstimmen
• Klick auf das Label fokussiert automatisch das Eingabefeld
• Screenreader lesen das Label vor, wenn der Nutzer das Feld fokussiert
• placeholder ist kein Ersatz für ein Label — er verschwindet beim Tippen

Fehlermeldungen

Fehlermeldungen sollten programmatisch mit dem Eingabefeld verknüpft sein:

<label for="email">E-Mail</label>
<input
  type="email"
  id="email"
  aria-describedby="email-error"
  aria-invalid="true"
/>
<p id="email-error" role="alert">Bitte gib eine gültige E-Mail-Adresse ein.</p>

• aria-describedby verknüpft die Fehlermeldung mit dem Input
• aria-invalid="true" signalisiert, dass der Wert ungültig ist
• role="alert" sorgt dafür, dass Screenreader die Meldung sofort vorlesen

Tastaturnavigation

Nicht alle Nutzer verwenden eine Maus. Manche navigieren ausschließlich mit der Tastatur — z.B. Menschen mit motorischen Einschränkungen oder Power-User.

Standardmäßig fokussierbare Elemente:

• Links (<a href>)
• Buttons (<button>)
• Eingabefelder (<input>, <select>, <textarea>)

Nicht fokussierbar:

• <div>, <span>, <p> und andere generische Elemente

Das bedeutet: Wenn du ein klickbares Element brauchst, verwende <button> oder <a>, nicht <div onclick="...">. Wenn du doch ein anderes Element klickbar machen musst, brauchst du:

<!-- Schlecht: nicht per Tastatur erreichbar -->
<div onclick="handleClick()">Klick mich</div>

<!-- Besser: einfach einen Button verwenden -->
<button onclick="handleClick()">Klick mich</button>

<!-- Falls es wirklich ein div sein muss: -->
<div
  role="button"
  tabindex="0"
  onclick="handleClick()"
  onkeydown="if(event.key==='Enter') handleClick()"
>
  Klick mich
</div>

Die Button-Variante ist fast immer die richtige Wahl. Sie ist fokussierbar, reagiert auf Enter und Space, und Screenreader erkennen sie automatisch.

Fokus-Sichtbarkeit

Der Browser zeigt einen Fokus-Ring um das aktuell fokussierte Element. Entferne ihn nie ohne Ersatz:

/* Schlecht: Focus-Ring entfernen */
*:focus {
  outline: none;
}

/* Gut: Focus-Ring nur für Maus-Nutzer ausblenden */
*:focus:not(:focus-visible) {
  outline: none;
}
*:focus-visible {
  outline: 2px solid #0ea5e9;
}

:focus-visible zeigt den Ring nur, wenn der Nutzer per Tastatur navigiert — nicht bei Mausklicks.

ARIA — Wenn HTML nicht reicht

ARIA (Accessible Rich Internet Applications) ergänzt HTML um zusätzliche Informationen für Screenreader. Die wichtigste Regel:

Kein ARIA ist besser als schlechtes ARIA.

Verwende ARIA nur, wenn kein natürliches HTML-Element die Rolle übernehmen kann.

Nützliche ARIA-Attribute

<!-- Label für Icon-Button -->
<button aria-label="Menü öffnen">☰</button>

<!-- Aufklappbares Element -->
<button aria-expanded="false" aria-controls="menu">Navigation</button>
<nav id="menu" hidden>...</nav>

<!-- Ladevorgang -->
<div aria-live="polite">Daten werden geladen...</div>

<!-- Dekoratives Element vor Screenreader verstecken -->
<span aria-hidden="true">🎨</span>

Skip-Link

Ein Skip-Link erlaubt Tastaturnutzern, die Navigation zu überspringen und direkt zum Hauptinhalt zu springen:

<body>
  <a href="#main-content" class="skip-link"> Zum Inhalt springen </a>

  <header>
    <nav><!-- Viele Links... --></nav>
  </header>

  <main id="main-content">
    <!-- Hauptinhalt -->
  </main>
</body>

.skip-link {
  position: absolute;
  top: -100%;
  left: 0;
}
.skip-link:focus {
  top: 0;
}

Der Link ist normalerweise nicht sichtbar, erscheint aber beim Fokussieren mit der Tab-Taste.

Checkliste

Hier ist eine praktische Checkliste, die du bei jeder Seite durchgehen kannst:

• Semantische HTML-Elemente verwenden (nav, main, header, footer)
• Nur ein <h1> pro Seite, Überschriften-Hierarchie einhalten
• Alle Bilder haben ein alt-Attribut (beschreibend oder leer)
• Alle Formularfelder haben ein <label>
• Klickbare Elemente sind <button> oder <a>, nicht <div>
• Die Seite ist komplett per Tastatur bedienbar
• Fokus-Ring ist sichtbar
• Farbkontrast mindestens 4.5:1 (normale Schrift) bzw. 3:1 (große Schrift)
• lang-Attribut am <html>-Element gesetzt
• Seite funktioniert bei 200% Zoom

Häufige Fehler

• Placeholder statt Label: <input placeholder="Name"> ohne Label ist für Screenreader nicht zugänglich. Der Placeholder verschwindet beim Tippen.
• Click-Handler auf divs: <div onclick="..."> ist für Tastaturnutzer nicht erreichbar und für Screenreader nicht als interaktiv erkennbar.
• Bilder ohne Alt-Text: Screenreader lesen dann den Dateinamen vor — “IMG_20240315_142537.jpg” ist wenig hilfreich.
• Fokus-Styles entfernen: outline: none ohne Alternative macht die Seite für Tastaturnutzer unbenutzbar.
• Nur Farbe für Information nutzen: “Die rot markierten Felder sind Pflichtfelder” — Menschen mit Farbfehlsichtigkeit sehen den Unterschied nicht.

Zusammenfassung

Barrierefreiheit ist kein Feature, das du am Ende draufpackst — sie ist Teil von gutem HTML. Die meisten Probleme lassen sich vermeiden, indem du:

1. Semantische Elemente verwendest
2. Alt-Texte für Bilder schreibst
3. Labels für Formulare vergibst
4. Native HTML-Elemente für Interaktivität nutzt (button, a)

Im letzten Artikel dieser Reihe geht es darum, wie du dein HTML validieren und auf Fehler prüfen kannst.