Webentwicklung

Barrierefreiheit im Web: WCAG, Kontrast und Tastaturbedienung

Barrierefreiheit im Web bedeutet, dass eine Seite von allen Menschen genutzt werden kann – unabhängig davon, ob jemand eine Bildschirmvorlesung verwendet, nur die Tastatur benutzt, farbenblind ist oder auf einem kleinen Bildschirm liest. Sie ist zugleich eine rechtliche Anforderung und ein Qualitätsmerkmal. Dieser Artikel zeigt die vier Grundprinzipien und die wichtigsten Maßnahmen.

Die vier Grundprinzipien (WCAG)

Die Web Content Accessibility Guidelines (WCAG) sind der internationale Standard, heute in Version 2.2. Vier Prinzipien tragen das Regelwerk:

  1. Wahrnehmbar: Inhalte müssen über mindestens einen Sinn erfassbar sein. Text braucht ausreichenden Kontrast, Bilder brauchen Alternativtexte, Videos brauchen Untertitel.
  2. Bedienbar: Alles muss über die Tastatur erreichbar sein, es darf keine Zeitfallen geben, und der Fokus muss sichtbar sein.
  3. Verständlich: Die Sprache ist im Markup anzugeben, Fehler werden erklärt, und die Benutzerführung ist vorhersehbar.
  4. Robust: Inhalte funktionieren mit unterschiedlichen Browsern und Hilfsmitteln – also mit korrektem, eindeutigem Markup.

Jedes Prinzip ist in drei Konformitätsstufen unterteilt: A (Minimum), AA (üblich geforderter Standard) und AAA (höchste Stufe, meist nicht vollständig erreichbar). Die öffentliche Hand fordert in der Regel AA – in Deutschland über die BITV, in der EU über die Richtlinie 2016/2102.

Die wichtigsten Maßnahmen

Semantisches Markup: das Fundament

Der häufigste Fehler ist der aufwendigste: ein div mit Klick-Handler statt eines button. Ein Hilfsmittel erkennt einen div nicht als Schaltfläche – keine Rolle, kein Fokus, keine Tastaturbedienung.

<!-- SCHLECHT: unsichtbar fuer Hilfsmittel -->
<div class="btn" onclick="senden()">Absenden</div>

<!-- GUT: hat Rolle, Fokus und Tastaturbedienung von Haus aus -->
<button type="submit">Absenden</button>

<!-- Struktur statt Gestaltung -->
<header>
  <nav aria-label="Hauptnavigation">
    <ul><li><a href="/">Start</a></li></ul>
  </nav>
</header>
<main>
  <h1>Seitentitel</h1>
  <h2>Abschnitt</h2>     <!-- Ueberschriften nicht ueberspringen! -->
  <section aria-labelledby="t1">
    <h3 id="t1">Unterabschnitt</h3>
  </section>
</main>
<footer>...</footer>

Die Grundregel: Erst semantisches Element, dann ARIA nur als Ergänzung. „No ARIA is better than bad ARIA“ – falsch gesetzte Rollen machen es schlechter als gar keine.

Tastaturbedienung und Fokus

/* Fokus NIE entfernen - das ist einer der haeufigsten Fehler */
/* SCHLECHT: */
:focus { outline: none; }

/* GUT: deutlich sichtbar, aber der Gestaltung angepasst */
:focus-visible {
  outline: 3px solid #2563eb;
  outline-offset: 2px;
}

/* Nur bei Elementen, die nicht fokussierbar sein sollen */
button:focus-visible { outline: 3px solid #2563eb; }
<!-- Sprungmarke zum Hauptinhalt: hilft Tastaturnutzern erheblich -->
<a class="skip-link" href="#main">Zum Hauptinhalt springen</a>
...
<main id="main" tabindex="-1">
.skip-link {
  position: absolute;
  left: -9999px;
}
.skip-link:focus {
  position: static;
  display: inline-block;
  background: #fff;
  padding: .5rem 1rem;
}

Zwei Regeln gehören dazu: Eine tabindex-Angabe über 0 vermeidet man (sie durchbricht die natürliche Reihenfolge). Und die Reihenfolge im Markup sollte der visuellen Reihenfolge entsprechen – sonst springt der Fokus unerwartet.

Alternativtexte

<!-- Informatives Bild: beschreibt den Inhalt -->
<img src="/diagramm.png"
     alt="Ablaufdiagramm: Anfrage geht vom Client an den Load Balancer, der sie an einen von drei Servern verteilt">

<!-- Dekoratives Bild: leerer Alt-Text, damit es uebersprungen wird -->
<img src="/trennlinie.png" alt="">

<!-- Funktionstraegendes Bild (Link/Button): beschreibt die AKTION -->
<a href="https://example.org/konto">
  <img src="/korb.svg" alt="Zum Warenkorb">
</a>

<!-- Komplexes Bild: kurzer Alt-Text plus ausfuehrliche Beschreibung -->
<figure>
  <img src="/architektur.png" alt="Systemarchitektur, Details im folgenden Text">
  <figcaption>Aufbau: ... ausfuehrliche Beschreibung ...</figcaption>
</figure>

<!-- NICHT: "Bild von ..." - das sagen Hilfsmittel selbst an -->

Farbkontrast

Die Anforderungen sind messbar, nicht Geschmackssache:

WCAG AA   normaler Text   4.5:1
WCAG AA   grosser Text    3:1      (ab 24px oder 19px fett)
WCAG AAA  normaler Text   7:1
UI-Elemente und Grafiken 3:1       (Rahmen, Symbole, Diagramme)

# Kontrast berechnen (WCAG-Formel)
python3 -c "
def lum(c):
    c = [x/255 for x in c]
    c = [x/12.92 if x <= 0.03928 else ((x+0.055)/1.055)**2.4 for x in c]
    return 0.2126*c[0] + 0.7152*c[1] + 0.0722*c[2]
def ratio(a, b):
    la, lb = lum(a), lum(b)
    hi, lo = max(la, lb), min(la, lb)
    return (hi + 0.05) / (lo + 0.05)
print(f'{ratio((37,99,235),(255,255,255)):.2f}:1')   # Blau auf Weiss
print(f'{ratio((128,128,128),(255,255,255)):.2f}:1') # Grau auf Weiss - zu wenig!
"

Farbe nie als einziges Signal. Ein Pflichtfeld nur rot umrandet ist für Farbenblinde nicht erkennbar. Zusätzlich ein Symbol oder ein Texthinweis.

Formulare

<!-- Jedes Feld braucht ein programmatisch verbundenes Label -->
<label for="email">E-Mail-Adresse</label>
<input type="email" id="email" name="email"
       autocomplete="email" required
       aria-describedby="email-hilfe">
<span id="email-hilfe">Wir verwenden die Adresse nur zur Anmeldung.</span>

<!-- Fehler nicht nur per Farbe, sondern mit Text und Bezug -->
<input type="email" id="email"
       aria-invalid="true"
       aria-describedby="email-fehler">
<span id="email-fehler" role="alert">
  Bitte eine gültige E-Mail-Adresse eingeben, z.B. Diese E-Mail-Adresse ist vor Spambots geschützt! Zur Anzeige muss JavaScript eingeschaltet sein.
</span>

<!-- Pflichtfelder mit required, nicht nur mit Sternchen -->
<input type="text" id="name" required>

aria-describedby ist hier das entscheidende Attribut: Es verbindet die Fehlermeldung mit dem Feld, sodass ein Hilfsmittel sie beim Fokussieren vorliest.

Dynamische Inhalte

<!-- Statusmeldungen live ankündigen -->
<div role="status" aria-live="polite">Gespeichert.</div>

<!-- Wichtige Warnungen sofort vorlesen -->
<div role="alert">Verbindung unterbrochen.</div>

<!-- Modale Dialoge brauchen Fokusverwaltung -->
<div role="dialog" aria-modal="true" aria-labelledby="titel">
  <h2 id="titel">Einstellungen</h2>
  ...
</div>
<!-- Fokus beim Oeffnen in den Dialog setzen, beim Schliessen
     zurueck auf das ausloesende Element. Tastaturfalle: Escape muss schliessen. -->

Prüfen statt hoffen

# 1. Automatische Pruefung im Browser
#    Lighthouse, axe DevTools, WAVE - finden rund 30-40 % der Probleme.

# 2. Tastaturpruefung von Hand - unverzichtbar
#    - Nur Tab-Taste verwenden
#    - Ist der Fokus immer sichtbar?
#    - Kommt man aus jedem Element wieder heraus?
#    - Funktioniert das Menue ohne Maus?

# 3. Zoompruefung
#    Browser-Zoom auf 200 % - bleibt der Inhalt nutzbar?
#    Kein horizontales Scrollen bei 320 px Breite?

# 4. Automatisierte Pruefung in der Auslieferung
npx @axe-core/cli https://example.org --exit
npx pa11y-ci --sitemap https://example.org/sitemap.xml

Häufige Fehler

  1. Kontrast zu gering. Hellgrau auf Weiß ist der Klassiker – 4,5:1 reicht nicht immer.
  2. Fokus unsichtbar. outline: none aus gestalterischen Gründen macht die Seite für Tastaturnutzer unbedienbar.
  3. Klickbare divs. Keine Rolle, kein Fokus, keine Tastaturbedienung.
  4. Fehlende oder schlechte Alternativtexte. „Bild“ oder ein Dateiname sind keine Beschreibung.
  5. Überschriftenebenen überspringen. Von h1 auf h4 – die Gliederung ist für Hilfsmittel die Navigationsstruktur.
  6. Kein Sprachattribut. <html lang="de"> fehlt oder ist falsch, dann liest die Vorlesung Englisch mit deutscher Aussprache.
  7. Automatisch abspielende Medien. Ton ohne Abschaltmöglichkeit macht die Seite für Vorlesungsnutzer unbrauchbar.
  8. Bewegung ohne Abschaltmöglichkeit. prefers-reduced-motion beachten – manche Menschen werden von Animationen krank.
@media (prefers-reduced-motion: reduce) {
  *, *::before, *::after {
    animation-duration: 0.01ms !important;
    animation-iteration-count: 1 !important;
    transition-duration: 0.01ms !important;
    scroll-behavior: auto !important;
  }
}

Warum sich das lohnt

Barrierefreiheit nützt weit mehr Menschen als den rund zehn Prozent mit anerkannter Behinderung. Sie hilft bei Sonnenlicht auf dem Bildschirm, bei einer gebrochenen Hand, in lauter Umgebung, mit alter Hardware – und Suchmaschinen bewerten semantisch korrekte Seiten besser. Die Maßnahmen, die am meisten bewirken, sind zugleich die einfachsten: semantisches Markup, sichtbarer Fokus, ausreichender Kontrast, Alternativtexte.

Verwandte Grundlagen: HTML5-Semantik, Responsive Design, DOM, Barrierefreiheit.