Web Accessibility (a11y): Ein praktischer Leitfaden für Entwickler

Person using a laptop with assistive technology

Über 1,3 Milliarden Menschen — 16 % der Weltbevölkerung — leben mit einer Form von Behinderung. Web Accessibility stellt sicher, dass Ihre Website für Nutzer funktioniert, die auf Screenreader, Tastaturnavigation, Switch-Zugang oder andere assistive Technologien angewiesen sind. Über die Inklusion hinaus ranken barrierefreie Websites besser in Suchmaschinen, funktionieren besser auf Mobilgeräten und sind oft gesetzlich vorgeschrieben.

Die vier POUR-Prinzipien

Die Web Content Accessibility Guidelines (WCAG) basieren auf vier Grundprinzipien. Inhalte müssen:

Wahrnehmbar sein — Informationen müssen so dargestellt werden, dass Nutzer sie wahrnehmen können (nicht nur visuell).
Bedienbar sein — Alle Funktionen müssen per Tastatur erreichbar sein.
Verständlich sein — Inhalte und Oberflächen müssen verständlich sein.
Robust sein — Inhalte müssen von assistiven Technologien interpretierbar sein.

WCAG 2.2 definiert drei Konformitätsstufen:

A — Minimum (Pflichtanforderung)
AA — Standardziel für die meisten Organisationen
AAA — Maximum (für bestimmte Inhalte angestrebt)

Die meisten gesetzlichen Anforderungen (ADA, EN 301 549, EAA) verlangen AA-Konformität.

Semantisches HTML zuerst

Das Wirkungsvollste, was Sie für Barrierefreiheit tun können, ist das richtige HTML-Element für den jeweiligen Zweck zu verwenden. Browser und Screenreader wissen bereits, was sie mit semantischen Elementen anfangen sollen:

<!-- ❌ Div soup — keine Semantik -->
<div class="header">
  <div class="nav">
    <div class="nav-item" onclick="navigate()">Home</div>
  </div>
</div>

<!-- ✅ Semantisches HTML — Screenreader verstehen das -->
<header>
  <nav>
    <a href="/">Home</a>
  </nav>
</header>

Wichtige semantische Elemente und ihre Rollen:

Element	Rolle
`<header>`, `<footer>`	Landmark-Regionen
`<nav>`	Navigations-Landmark
`<main>`	Hauptinhalt (einmal pro Seite)
`<aside>`	Ergänzender Inhalt
`<h1>`–`<h6>`	Überschriftenhierarchie
`<button>`	Interaktives Steuerelement
`<a href>`	Navigationslink
`<label>`	Formularfeld-Bezeichnung
`<table>`	Tabellarische Daten

Bilder und Alt-Text

Jedes bedeutungstragende Bild benötigt ein alt-Attribut, das seinen Inhalt beschreibt. Dekorative Bilder erhalten ein leeres alt="", damit Screenreader sie überspringen:

<!-- Bedeutungsvolles Bild -->
<img src="chart.png" alt="Balkendiagramm mit 40 % Umsatzanstieg in Q1 2026">

<!-- Dekoratives Bild -->
<img src="divider.svg" alt="">

<!-- Icon-Button — Aktion beschreiben, nicht das Icon -->
<button>
  <img src="trash.svg" alt="Element löschen">
</button>

<!-- Vermeiden: redundantes "Bild von" -->
<!-- ❌ --> <img src="cat.jpg" alt="Bild einer Katze">
<!-- ✅ --> <img src="cat.jpg" alt="Orangefarbene Tigerkatze sitzt auf einer Fensterbank">

Farbkontrast

Nutzer mit Sehschwäche oder Farbenblindheit sind auf ausreichenden Kontrast zwischen Text und Hintergrund angewiesen.

WCAG-AA-Anforderungen:

Normaler Text (< 18pt): mindestens 4,5:1 Kontrastverhältnis
Großer Text (≥ 18pt oder 14pt fett): mindestens 3:1 Kontrastverhältnis
UI-Komponenten und grafische Elemente: mindestens 3:1

Verlassen Sie sich nicht allein auf Farbe, um Informationen zu vermitteln:

<!-- ❌ Nur-Farbe-Statusanzeige -->
<span class="text-red-500">Fehler</span>

<!-- ✅ Farbe + Icon + Text -->
<span class="text-red-500 flex items-center gap-1">
  <svg aria-hidden="true"><!-- Fehler-Icon --></svg>
  Fehler: Ungültige E-Mail-Adresse
</span>

Formulare: Labels, Fehlermeldungen und Beschreibungen

Jedes Formularsteuerelement benötigt ein sichtbares, zugeordnetes Label:

<!-- ✅ Explizite Label-Zuordnung -->
<label for="email">E-Mail-Adresse</label>
<input id="email" type="email" aria-describedby="email-hint email-error">
<p id="email-hint" class="text-sm text-gray-500">Wir teilen Ihre E-Mail niemals weiter.</p>
<p id="email-error" role="alert" class="text-sm text-red-600" hidden>
  Bitte geben Sie eine gültige E-Mail-Adresse ein.
</p>

Wichtige Muster für barrierefreie Formulare:

for/id verwenden, um Labels mit Eingabefeldern zu verknüpfen
aria-describedby für Hinweistexte und Fehlermeldungen verwenden
role="alert" oder aria-live="polite" für dynamische Fehlermeldungen verwenden
aria-required="true" oder das native required-Attribut verwenden
Zusammengehörige Eingaben mit <fieldset> und <legend> gruppieren

Tastaturnavigation

Alle interaktiven Elemente müssen per Tastatur erreichbar und bedienbar sein:

Tab — vorwärts durch fokussierbare Elemente navigieren
Shift+Tab — rückwärts navigieren
Enter/Leertaste — Buttons, Checkboxen aktivieren
Pfeiltasten — innerhalb von Komponenten navigieren (Menüs, Tabs, Schieberegler)
Escape — Modals schließen, Dropdowns ausblenden

Fokusindikatoren müssen sichtbar sein. Folgendes sollte niemals ohne Alternative gemacht werden:

/* ❌ Verbirgt den Fokusindikator vollständig */
*:focus { outline: none; }

/* ✅ Benutzerdefinierter Fokus-Stil, der dennoch sichtbar ist */
*:focus-visible {
  outline: 2px solid #3b82f6;
  outline-offset: 2px;
}

ARIA: wann und wie man es verwendet

ARIA (Accessible Rich Internet Applications) Attribute fügen semantische Bedeutung hinzu, wenn HTML allein nicht ausreicht. Die erste Regel von ARIA: Verwenden Sie ARIA nicht, wenn natives HTML die Aufgabe erfüllen kann.

<!-- Elemente ohne sichtbare Labels beschriften -->
<button aria-label="Dialog schließen">✕</button>

<!-- Aufgeklappten Zustand beschreiben -->
<button aria-expanded="false" aria-controls="menu">Menü</button>
<ul id="menu" hidden>...</ul>

<!-- Live-Region für dynamische Inhalte -->
<div aria-live="polite" aria-atomic="true">
  <!-- Screenreader kündigen Änderungen in diesem Bereich an -->
  3 Ergebnisse gefunden
</div>

<!-- Landmark-Rolle, wenn kein semantisches Element verfügbar ist -->
<div role="search">
  <input type="search" placeholder="Suchen...">
</div>

Fokus-Management für SPAs und Modals

In Single-Page Applications löst die Seitennavigation keinen Browser-Fokus-Reset aus. Wenn eine „Seite" geladen wird, sollte der Fokus an eine sinnvolle Stelle gesetzt werden:

// Nach der Navigation den Fokus auf die Hauptüberschrift setzen
document.querySelector("h1")?.focus();

Bei Modals:

Wenn das Modal geöffnet wird, Fokus auf das erste fokussierbare Element darin setzen
Fokus innerhalb des Modals einschließen, solange es geöffnet ist (verhindern, dass Tab auf Inhalte dahinter zugreift)
Wenn das Modal geschlossen wird, Fokus auf das auslösende Element zurücksetzen

Barrierefreiheit testen

Automatisierte Tools (erfassen ~30–40 % der Probleme)

axe DevTools Browser-Erweiterung
Lighthouse Accessibility-Audit in Chrome DevTools
WAVE Browser-Erweiterung

Manuelle Tests (für vollständige Abdeckung erforderlich)

Nur-Tastatur-Navigation — Maus abstöpseln und die gesamte Website navigieren
Screenreader-Tests — NVDA + Firefox (Windows), VoiceOver + Safari (Mac/iOS)
Zoom auf 200 % — sicherstellen, dass kein Inhalt verloren geht oder sich überlappt
Farbenblindheits-Simulation — Browser DevTools → Rendering → Sehbeeinträchtigungen emulieren

Lesbarkeit

Einfache Sprache verbessert die Barrierefreiheit für Nutzer mit kognitiven Einschränkungen. Verwenden Sie unser Readability Score-Tool, um das Leseniveau Ihrer Inhalte zu prüfen — für allgemeine Zielgruppen wird Klassenstufe 8–10 empfohlen.

Schnelle Verbesserungen, die Sie heute umsetzen können

alt-Text zu allen Bildern hinzufügen
Sicherstellen, dass alle Formularfelder zugehörige <label>-Elemente haben
Prüfen, ob der Farbkontrast bei Fließtext 4,5:1 erfüllt
:focus-visible-Stile hinzufügen und Outlines niemals ohne Ersatz entfernen
<button> für Aktionen und <a href> für Navigation verwenden (niemals umgekehrt)
lang="de" (oder die entsprechende Sprache) zum <html>-Element hinzufügen
Ein <h1> pro Seite verwenden und eine logische Überschriftenhierarchie einhalten

Barrierefreiheit ist kein Zusatz — sie ist ein Qualitätsmerkmal. Barrierefreie Produkte von Anfang an zu entwickeln ist weitaus günstiger als ein nachträgliches Umrüsten, und es macht Ihre Produkte für alle besser.