mitmario.dev

HTML-Grundlagen · 7 von 9

Barrierefreiheit in HTML

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.

Steckbrief Grundlagen
Reihe
HTML-Grundlagen
Teil
7 von 9
Kapitel
10
Vorschauen
2
Lesezeit
5 Min
Stand
03.02.2026

Warum Barrierefreiheit wichtig ist

01 / 10
  • 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

02 / 10

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:

ElementEingebaute Rolle
<nav>Navigation Landmark
<main>Main Landmark
<header>Banner (wenn Top-Level)
<footer>Contentinfo (wenn Top-Level)
<button>Button (klickbar, fokussierbar)
<a href>Link (klickbar, fokussierbar)
<h1>–<h6>Heading (Überschrift)

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

03 / 10

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

index.html
Beschreibender Alt-Text
<!-- 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

04 / 10

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

index.html
Zugängliches Formular
<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, denn 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

05 / 10

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

06 / 10

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>
AttributWann verwenden
aria-labelWenn kein sichtbarer Text vorhanden ist (Icon-Buttons)
aria-expandedBei auf-/zuklappbaren Elementen
aria-hiddenDekorative Elemente, die Screenreader ignorieren sollen
aria-liveBereiche, die sich dynamisch ändern
aria-describedbyZusätzliche Beschreibung verknüpfen
aria-requiredWenn required nicht verwendet werden kann
07 / 10

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

08 / 10

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

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

Zusammenfassung

10 / 10

Barrierefreiheit ist kein Feature, das du am Ende draufpackst, sondern 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.

Newsletter

einmal die Woche, kostenlos

Neue Artikel und Videos, was sich auf der Lernplattform tut, und ab und zu ein Sonderpreis zum Kursstart. Kurz genug, dass du es auch liest.

Zuletzt verschickt · KW 40

Einmal alles neu, und die Lernplattform ist da

Danach kommt eine Mail mit Bestätigungslink, erst dann bist du eingetragen. Abmelden geht unten in jeder Ausgabe. Mehr dazu in der Datenschutzerklärung.