Accessibility

Einfach erklärt

Rund 15% der Weltbevölkerung leben mit einer Behinderung – Sehbeeinträchtigungen, motorische Einschränkungen, Hörprobleme, kognitive Einschränkungen. Dazu kommen situative Einschränkungen, die jeden treffen: Sonne auf dem Bildschirm, laute Umgebung, eine Hand belegt, Brille vergessen.

Eine barrierefreie Website funktioniert für alle diese Menschen. Das ist nicht nur ethisch richtig – es ist oft auch gesetzlich vorgeschrieben und verbessert die Nutzererfahrung für alle.

a11y ist die gebräuchliche Abkürzung: a + 11 Buchstaben + y = accessibility.

Die vier POUR-Prinzipien (WCAG)

P – Perceivable (Wahrnehmbar)
  Inhalte müssen mit verschiedenen Sinnen wahrnehmbar sein
  → Alt-Texte für Bilder
  → Untertitel für Videos
  → Ausreichender Farbkontrast

O – Operable (Bedienbar)
  Alle Funktionen müssen ohne Maus nutzbar sein
  → Tastaturnavigation
  → Keine Zeitlimits (oder verlängerbar)
  → Keine Inhalte die Anfälle auslösen können

U – Understandable (Verständlich)
  Inhalte und Bedienung müssen verständlich sein
  → Klare Sprache
  → Fehlermeldungen mit Lösungshinweisen
  → Konsistente Navigation

R – Robust (Robust)
  Inhalte müssen mit verschiedenen Technologien funktionieren
  → Valides HTML
  → ARIA-Attribute korrekt eingesetzt
  → Kompatibel mit Screenreadern

Technischer Deep Dive

Semantisches HTML – die Grundlage

<!-- ❌ Nicht barrierefrei: div-Suppe -->
<div class="header">
  <div class="nav">
    <div class="nav-item" onclick="goto('/')">Home</div>
  </div>
</div>
<div class="main">
  <div class="article">
    <div class="title">Mein Artikel</div>
    <div class="text">Inhalt...</div>
  </div>
</div>

<!-- ✅ Barrierefrei: Semantisches HTML -->
<header>
  <nav aria-label="Hauptnavigation">
    <ul>
      <li><a href="/">Home</a></li>
    </ul>
  </nav>
</header>
<main>
  <article>
    <h1>Mein Artikel</h1>
    <p>Inhalt...</p>
  </article>
</main>

Farbkontrast

WCAG AA erfordert:

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

/* ❌ Zu geringer Kontrast */
.text { color: #999; background: #fff; }  /* Kontrast: 2,85:1 */

/* ✅ Ausreichender Kontrast */
.text { color: #595959; background: #fff; }  /* Kontrast: 7,0:1 */

/* Kontrast prüfen: https://webaim.org/resources/contrastchecker/ */

Tastaturnavigation

<!-- Alle interaktiven Elemente müssen per Tab erreichbar sein -->

<!-- ✅ Natürliche Tab-Reihenfolge durch semantisches HTML -->
<button type="button">Klick mich</button>
<a href="/seite">Link</a>
<input type="text" />

<!-- ✅ Skip-Link: Screenreader und Tastaturnutzer können Navigation überspringen -->
<a href="#main-content" class="skip-link">Zum Hauptinhalt springen</a>
<nav>...</nav>
<main id="main-content">...</main>

<!-- CSS für Skip-Link (sichtbar nur bei Fokus) -->
<style>
.skip-link {
  position: absolute;
  top: -40px;
  left: 0;
  background: #000;
  color: #fff;
  padding: 8px;
  z-index: 100;
}
.skip-link:focus {
  top: 0;
}
</style>

ARIA – Accessible Rich Internet Applications

<!-- ARIA ergänzt HTML wo native Semantik nicht ausreicht -->

<!-- Modaler Dialog -->
<div
  role="dialog"
  aria-modal="true"
  aria-labelledby="dialog-title"
  aria-describedby="dialog-desc"
>
  <h2 id="dialog-title">Bestätigung</h2>
  <p id="dialog-desc">Möchten Sie wirklich löschen?</p>
  <button type="button" autofocus>Löschen</button>
  <button type="button">Abbrechen</button>
</div>

<!-- Live-Regionen: Screenreader liest Änderungen vor -->
<div aria-live="polite" aria-atomic="true">
  <!-- Statusmeldungen, die dynamisch erscheinen -->
  Formular erfolgreich gespeichert.
</div>

<!-- Expandierbarer Bereich -->
<button
  aria-expanded="false"
  aria-controls="menu"
  type="button"
>
  Menü öffnen
</button>
<ul id="menu" hidden>...</ul>

Formulare barrierefrei gestalten

<!-- ❌ Nicht barrierefrei -->
<input type="text" placeholder="E-Mail-Adresse">
<span style="color:red">Pflichtfeld</span>

<!-- ✅ Barrierefrei -->
<div>
  <label for="email">
    E-Mail-Adresse
    <span aria-hidden="true">*</span>
    <span class="sr-only">(Pflichtfeld)</span>
  </label>
  <input
    type="email"
    id="email"
    name="email"
    required
    aria-required="true"
    aria-describedby="email-error"
    autocomplete="email"
  >
  <span id="email-error" role="alert" hidden>
    Bitte gib eine gültige E-Mail-Adresse ein.
  </span>
</div>

<!-- Screen-Reader-only Text (visuell versteckt, aber lesbar) -->
<style>
.sr-only {
  position: absolute;
  width: 1px;
  height: 1px;
  padding: 0;
  margin: -1px;
  overflow: hidden;
  clip: rect(0, 0, 0, 0);
  white-space: nowrap;
  border: 0;
}
</style>

Accessibility-Testing-Workflow

1. Automatisch (schnell, ~30-40% der Fehler):
   - Lighthouse in Chrome DevTools
   - axe DevTools Browser-Extension
   - CI-Integration: axe-core in Jest/Playwright

2. Manuell (notwendig für den Rest):
   - Tastaturnavigation: Tab durch alle Elemente
   - Screenreader: NVDA (Windows) oder VoiceOver (Mac/iOS)
   - Zoom auf 200%: Layout bricht nicht?
   - Kontrast: Alle Texte prüfen

3. Mit echten Nutzern:
   - Usability-Tests mit Menschen mit Behinderungen
   - Goldstandard, aber aufwändig

Automatisiertes Testing mit axe-core

// Playwright + axe-core
import { test, expect } from '@playwright/test';
import AxeBuilder from '@axe-core/playwright';

test('Startseite hat keine Accessibility-Fehler', async ({ page }) => {
  await page.goto('/');

  const results = await new AxeBuilder({ page })
    .withTags(['wcag2a', 'wcag2aa', 'wcag21a', 'wcag21aa'])
    .analyze();

  expect(results.violations).toEqual([]);
});

BFSG – Was Unternehmen jetzt tun müssen

Betroffene Produkte (ab 28. Juni 2025):
  ✓ E-Commerce-Websites und Apps
  ✓ Online-Banking
  ✓ E-Books und E-Reader-Software
  ✓ Streaming-Dienste
  ✓ Messenger und Kommunikationsdienste

Ausnahmen:
  ✗ Kleinstunternehmen (<10 MA und <2 Mio. € Umsatz)
  ✗ Inhalte vor dem 28. Juni 2025 (Bestandsschutz bis 2030)

Konformitätsstufe: WCAG 2.1 Level AA

Sanktionen bei Verstoß:
  Abmahnungen, Bußgelder, Klagen von Verbänden