Grundlagen der Web-Barrierefreiheit für Entwickler

Die meisten Barrierefreiheits-Fixes sind keine heldenhaften Refactorings. Es sind kleine, fast peinlich simple Änderungen, die du übersprungen hast, weil sich noch niemand beschwert hat – bislang. Tatsächlich haben 15–20 % der Nutzer irgendeine Form von Beeinträchtigung, und unzugängliche Oberflächen drängen sie still und leise ab, ohne dass je ein Bug gemeldet wird.

Barrierefreiheit ist kein Feature, das man später anflanscht. Sie ist ein Basis-Qualitätsstandard, genau wie Fehlerbehandlung oder das Schreiben von Tests.

Semantisches HTML ist die Grundlage

Die wirkungsvollste Barrierefreiheits-Verbesserung kostet keinen zusätzlichen Aufwand: die richtigen HTML-Elemente verwenden. Ein <button> kümmert sich bereits um Tastaturfokus, Aktivierung per Enter/Leertaste und Ansagen durch den Screenreader. Ein <div onClick> tut nichts davon.

<!-- ❌ Inaccessible — no keyboard support, no role, no focus -->
<div class="btn" onclick="handleClick()">
  Submit
</div>
 
<!-- ✅ Accessible by default — focus, keyboard, screen reader support -->
<button type="submit" onclick="handleClick()">
  Submit
</button>

Das gleiche Prinzip gilt überall: <nav> statt <div class="nav">, <main> statt <div class="content">, <h2> statt <div class="heading">. Jedes semantische Element bringt implizite ARIA-Rollen mit, auf die assistive Technologien sich verlassen.

Häufige semantische Fehler

<!-- ❌ Heading hierarchy skipped — confuses screen reader navigation -->
<h1>Page Title</h1>
<h4>Section Title</h4>
 
<!-- ✅ Sequential heading levels -->
<h1>Page Title</h1>
<h2>Section Title</h2>

Screenreader erzeugen aus Überschriften ein Inhaltsverzeichnis. Übersprungene Ebenen erzeugen eine kaputte Gliederung, die die Navigation für Nutzer, die darauf angewiesen sind, mühsam macht.

Muster für die Tastaturnavigation

Jedes interaktive Element muss allein per Tastatur erreichbar und bedienbar sein. Das bedeutet, die Fokusreihenfolge, sichtbare Fokusindikatoren und Tastatur-Event-Handler zu verwalten.

/* ❌ Destroys keyboard accessibility — users can't see where they are */
*:focus {
  outline: none;
}
 
/* ✅ Custom focus style that's visible and on-brand */
*:focus-visible {
  outline: 2px solid #4A90D9;
  outline-offset: 2px;
  border-radius: 2px;
}

Die Pseudoklasse :focus-visible ist die richtige Lösung – sie zeigt den Outline nur bei Tastaturnavigation, nicht bei Mausklicks. Das löst die Designer-Beschwerde über "hässliche Outlines", ohne die Barrierefreiheit zu opfern.

Fokus-Trapping in Modals

Wenn sich ein Modal öffnet, muss der Fokus darin bleiben. Andernfalls tabben Tastaturnutzer hinter das Modal in unsichtbaren Inhalt.

function trapFocus(modalElement: HTMLElement) {
  const focusableSelectors = [
    'button', '[href]', 'input', 'select',
    'textarea', '[tabindex]:not([tabindex="-1"])'
  ];
  const focusable = modalElement.querySelectorAll(
    focusableSelectors.join(', ')
  );
  const first = focusable[0] as HTMLElement;
  const last = focusable[focusable.length - 1] as HTMLElement;
 
  modalElement.addEventListener('keydown', (e: KeyboardEvent) => {
    if (e.key !== 'Tab') return;
 
    if (e.shiftKey && document.activeElement === first) {
      e.preventDefault();
      last.focus();
    } else if (!e.shiftKey && document.activeElement === last) {
      e.preventDefault();
      first.focus();
    }
  });
 
  first.focus();
}

Modernes HTML bietet <dialog> mit eingebautem Fokus-Trapping, aber benutzerdefinierte Modals brauchen weiterhin explizite Verwaltung.

ARIA: sparsam und korrekt einsetzen

ARIA-Attribute sollen Lücken schließen, an denen die HTML-Semantik nicht ausreicht – sie sollen sie nicht ersetzen. Die erste Regel von ARIA lautet wörtlich "benutze kein ARIA", wenn ein natives HTML-Element den Job bereits erledigt.

<!-- ❌ Redundant — button already has role="button" -->
<button role="button" aria-label="Submit">Submit</button>
 
<!-- ✅ ARIA adds missing context where needed -->
<button aria-expanded="false" aria-controls="dropdown-menu">
  Options
</button>
<ul id="dropdown-menu" role="menu" hidden>
  <li role="menuitem">Edit</li>
  <li role="menuitem">Delete</li>
</ul>

Die nützlichsten ARIA-Attribute für die tägliche Entwicklung:

• aria-label – beschriftet Elemente ohne sichtbaren Text
• aria-expanded – vermittelt den Umschaltzustand
• aria-live – kündigt dynamische Inhaltsänderungen an
• aria-hidden="true" – verbirgt dekorative Elemente vor Screenreadern

Live-Regionen für dynamische Inhalte

Wenn sich Inhalte ohne Neuladen der Seite ändern (Toast-Benachrichtigungen, Formularvalidierung, Live-Daten), brauchen Screenreader eine explizite Benachrichtigung.

function announceMessage(message: string, priority: 'polite' | 'assertive' = 'polite') {
  const announcer = document.getElementById('live-announcer');
  if (!announcer) return;
 
  announcer.setAttribute('aria-live', priority);
  announcer.textContent = '';
  // Force DOM to register the empty state before updating
  requestAnimationFrame(() => {
    announcer.textContent = message;
  });
}

Platziere einmalig eine unsichtbare Live-Region in deinem Layout und nutze sie für alle dynamischen Ansagen wieder.

Farbkontrast und visuelles Design

WCAG 2.1 verlangt ein Mindestkontrastverhältnis von 4.5:1 für normalen Text und 3:1 für großen Text. Das ist kein Vorschlag – es ist der Unterschied zwischen lesbar und unleserlich für Millionen von Nutzern.

/* ❌ Fails contrast — ratio 2.3:1 */
.subtle-text {
  color: #B0B0B0;
  background: #FFFFFF;
}
 
/* ✅ Passes AA contrast — ratio 4.6:1 */
.subtle-text {
  color: #767676;
  background: #FFFFFF;
}

Verlasse dich niemals allein auf Farbe, um Bedeutung zu vermitteln. Fehlerzustände brauchen sowohl die Farbe Rot als auch ein Icon oder eine Textbeschriftung. Statusanzeigen brauchen Unterschiede in Form oder Muster, nicht nur in der Farbe.

Formulare: das Minenfeld der Barrierefreiheit

Formulare sammeln mehr Barrierefreiheits-Verstöße an als jede andere Komponente. Die Lösung besteht fast immer darin, Labels mit Eingabefeldern zu verknüpfen.

<!-- ❌ No programmatic label — screen reader says "edit text" -->
<input type="email" placeholder="Enter your email" />
 
<!-- ✅ Explicit label association -->
<label for="email-input">Email address</label>
<input id="email-input" type="email" placeholder="you@example.com" />

Placeholder sind keine Labels. Sie verschwinden beim Fokussieren, erfüllen die Kontrastanforderungen nicht und bieten keinen dauerhaften Kontext. Jedes Eingabefeld braucht ein <label> mit einem passenden for-Attribut.

Verwende für Fehlermeldungen aria-describedby, um den Fehler mit dem Eingabefeld zu verknüpfen:

<label for="password">Password</label>
<input
  id="password"
  type="password"
  aria-describedby="password-error"
  aria-invalid="true"
/>
<span id="password-error" role="alert">
  Password must be at least 8 characters
</span>

Barrierefreiheit testen

Automatisierte Tools erkennen etwa 30 % der Barrierefreiheits-Probleme. Der Rest erfordert manuelle Tests. Eine sinnvolle Teststrategie kombiniert beides.

Automatisiert: Führe axe-core- oder Lighthouse-Audits zur Barrierefreiheit in deiner CI aus. Sie erkennen die naheliegendsten Probleme: fehlenden Alt-Text, kaputte Label-Zuordnungen, Kontrastfehler.

Manuelle Prüfungen:

1. Die gesamte Seite mit Tab durchgehen – erreichst und bedienst du alles?
2. Einen Screenreader (VoiceOver, NVDA) zumindest für die kritischen Abläufe verwenden
3. Auf 200 % zoomen – funktioniert das Layout noch?
4. CSS deaktivieren – ist die Reihenfolge der Inhalte weiterhin logisch?

Der Accessibility-Tree der Browser-DevTools zeigt genau, was assistive Technologie sieht. Wenn ein Element im Baum fehlt oder die falsche Rolle hat, ist das der Bug.

Die wichtigsten Erkenntnisse

1. Semantisches HTML löst 50 % der Barrierefreiheits-Probleme – verwende die richtigen Elemente, bevor du zu ARIA greifst
2. Entferne niemals Fokus-Outlines – nutze :focus-visible für einen nur bei Tastaturnutzung sichtbaren Stil
3. Labels sind Pflicht – jedes Formularfeld braucht ein explizites <label>, nicht nur einen Placeholder
4. Farbe allein reicht nicht – kombiniere Farbe immer mit Text, Icons oder Mustern
5. Teste mit Tastatur und Screenreadern – automatisierte Tools erkennen nur einen Bruchteil der echten Probleme
6. ARIA ist das letzte Mittel – die erste Regel von ARIA lautet, kein ARIA zu benutzen, wenn natives HTML funktioniert