Barrierefreiheit: WCAG 2.2

Rund 7,8 Millionen Menschen in Deutschland leben mit einer schweren Behinderung. Dazu kommen Millionen mit Sehschwächen, motorischen Einschränkungen oder temporären Beeinträchtigungen. Barrierefreie Websites sind kein Nice-to-have – sie sind eine Notwendigkeit und seit 2025 in vielen Fällen gesetzlich vorgeschrieben.

In diesem Artikel erkläre ich die WCAG 2.2 Richtlinien verständlich, zeige, was das Barrierefreiheitsstärkungsgesetz (BFSG) für Sie bedeutet, und gebe praktische Tipps für die Umsetzung.

Was bedeutet Barrierefreiheit im Web?

Barrierefreiheit (englisch: Accessibility, oft abgekürzt als a11y) bedeutet, dass Websites und Webanwendungen von allen Menschen genutzt werden können – unabhängig von körperlichen oder kognitiven Einschränkungen.

Wer profitiert von Barrierefreiheit?

Gruppe	Beispiele	Barriere
Sehbehinderte	Blindheit, Farbenblindheit, Sehschwäche	Bilder ohne Alt-Text, schlechter Kontrast
Hörbehinderte	Gehörlose, Schwerhörige	Videos ohne Untertitel
Motorisch eingeschränkte	Tremor, Lähmungen	Kleine Klickflächen, keine Tastatursteuerung
Kognitiv eingeschränkte	Legasthenie, ADHS	Komplexe Sprache, überladenes Design
Temporär eingeschränkte	Gebrochener Arm, grelles Licht	Alle oben genannten

Wichtig: Barrierefreiheit hilft allen. Untertitel nutzen auch Menschen in lauten Umgebungen. Guter Kontrast hilft bei Sonneneinstrahlung. Einfache Sprache verbessert die allgemeine Verständlichkeit.

WCAG 2.2: Der internationale Standard

Die Web Content Accessibility Guidelines (WCAG) sind der internationale Standard für Barrierefreiheit im Web. Version 2.2 wurde im Oktober 2023 veröffentlicht und ist die aktuelle Referenz.

Die vier Grundprinzipien (POUR)

WCAG basiert auf vier Grundprinzipien:

1. Perceivable (Wahrnehmbar) Informationen müssen so präsentiert werden, dass Nutzer sie wahrnehmen können.

2. Operable (Bedienbar) Alle Funktionen müssen über verschiedene Eingabemethoden bedienbar sein.

3. Understandable (Verständlich) Informationen und Bedienung müssen verständlich sein.

4. Robust Inhalte müssen mit verschiedenen Technologien (auch Hilfsmitteln) funktionieren.

Konformitätsstufen

WCAG definiert drei Konformitätsstufen:

Stufe	Bedeutung	Anforderung
A	Minimum	Grundlegende Barrierefreiheit
AA	Standard	Gesetzlich oft gefordert (BFSG)
AAA	Optimal	Höchste Barrierefreiheit

Empfehlung: Streben Sie mindestens Stufe AA an. Das ist der gesetzliche Standard und ein guter Kompromiss zwischen Aufwand und Nutzen.

Die wichtigsten WCAG 2.2 Kriterien

1. Alternativtexte für Bilder (1.1.1)

Jedes informative Bild benötigt einen beschreibenden Alt-Text.

<!-- Schlecht -->
<img src="team.jpg">

<!-- Gut -->
<img src="team.jpg" alt="Das webdienster.de Team bei der Projektbesprechung">

<!-- Dekoratives Bild (leerer Alt-Text) -->
<img src="decoration.jpg" alt="">

Tipps für gute Alt-Texte:

• Beschreiben Sie, was auf dem Bild zu sehen ist
• Bei Grafiken: Nennen Sie die dargestellte Information
• Bei Buttons: Beschreiben Sie die Funktion
• Dekorative Bilder: Leerer Alt-Text (alt="")

2. Farbkontrast (1.4.3, 1.4.6)

Text muss ausreichend Kontrast zum Hintergrund haben.

Stufe	Normaler Text	Großer Text (18pt+)
AA	4.5:1	3:1
AAA	7:1	4.5:1

Tools zum Testen:

• WebAIM Contrast Checker
• Colour Contrast Analyser

3. Tastaturzugänglichkeit (2.1.1, 2.1.2)

Alle Funktionen müssen per Tastatur erreichbar sein.

<!-- Schlecht: Nicht fokussierbar -->
<div onclick="openMenu()">Menü</div>

<!-- Gut: Natürlich fokussierbar -->
<button onclick="openMenu()">Menü</button>

<!-- Alternative mit tabindex -->
<div role="button" tabindex="0" onclick="openMenu()"
     onkeypress="if(event.key==='Enter') openMenu()">Menü</div>

Checkliste:

• Tab-Navigation funktioniert logisch
• Fokus ist immer sichtbar
• Keine Tastatur-Falle (Nutzer kann Element verlassen)
• Enter/Space aktivieren interaktive Elemente

4. Seitenstruktur und Überschriften (1.3.1, 2.4.6)

Verwenden Sie semantisches HTML und eine logische Überschriften-Hierarchie.

<!-- Schlecht -->
<div class="title">Hauptüberschrift</div>
<div class="subtitle">Unterüberschrift</div>

<!-- Gut -->
<h1>Hauptüberschrift</h1>
<h2>Unterüberschrift</h2>
<h3>Weiterer Abschnitt</h3>

Regeln:

• Nur eine H1 pro Seite
• Keine Ebenen überspringen (H1 → H2 → H3)
• Überschriften beschreiben den folgenden Inhalt

5. Formulare zugänglich gestalten (1.3.1, 3.3.2)

<!-- Schlecht -->
<input type="text" placeholder="E-Mail">

<!-- Gut -->
<label for="email">E-Mail-Adresse</label>
<input type="email" id="email" name="email"
       aria-describedby="email-hint">
<span id="email-hint">Wir senden Ihnen eine Bestätigung.</span>

Checkliste für Formulare:

• Jedes Eingabefeld hat ein Label
• Pflichtfelder sind gekennzeichnet
• Fehlermeldungen sind verständlich
• Fehler werden mit dem Feld verknüpft

6. Neue Kriterien in WCAG 2.2

Version 2.2 bringt wichtige neue Anforderungen:

Focus Not Obscured (2.4.11 AA): Der Fokus-Indikator darf nicht vollständig verdeckt sein (z.B. durch Sticky Headers).

Target Size Minimum (2.5.8 AA): Interaktive Elemente müssen mindestens 24x24 CSS-Pixel groß sein.

Accessible Authentication (3.3.8 AA): Authentifizierung darf nicht ausschließlich auf kognitiven Tests basieren (Captchas).

BFSG: Das deutsche Barrierefreiheitsstärkungsgesetz

Seit dem 28. Juni 2025 gilt das Barrierefreiheitsstärkungsgesetz (BFSG) für bestimmte Produkte und Dienstleistungen. Es setzt die europäische Richtlinie (European Accessibility Act) in deutsches Recht um.

Wer ist betroffen?

Das BFSG betrifft unter anderem:

• E-Commerce-Websites mit Warenverkauf
• Bankdienstleistungen (Online-Banking)
• E-Books und E-Reader
• Kommunikationsdienste
• Personenbeförderungsdienste

Was ist gefordert?

• Konformität mit WCAG 2.1 Level AA (mindestens)
• Dokumentation der Barrierefreiheitsmaßnahmen
• Erklärung zur Barrierefreiheit auf der Website

Ausnahmen

Ausgenommen sind:

• Kleinstunternehmen (unter 10 Mitarbeiter UND unter 2 Mio. € Umsatz)
• Websites ohne wirtschaftliche Transaktion
• Unverhältnismäßig aufwendige Anpassungen (muss nachgewiesen werden)

Praktische Tipps zur Umsetzung

1. Automatisierte Tests

Starten Sie mit automatisierten Tools:

# axe-core über npm
npm install @axe-core/cli
npx axe https://www.ihre-website.de

# Lighthouse in Chrome DevTools
# Öffnen Sie DevTools → Lighthouse → Accessibility

Wichtig: Automatisierte Tests finden nur ~30% der Probleme. Manuelle Tests sind unerlässlich.

2. Manuelle Tests

Tastatur-Test:

1. Legen Sie die Maus weg
2. Navigieren Sie mit Tab durch die Seite
3. Prüfen Sie: Ist der Fokus sichtbar? Ist die Reihenfolge logisch?

Screenreader-Test:

• Windows: NVDA (kostenlos)
• Mac: VoiceOver (integriert)
• Hören Sie sich an, wie Ihre Seite vorgelesen wird

3. Checkliste für den Start

• Alle Bilder haben Alt-Texte
• Farbkontrast mindestens 4.5:1
• Seite ist per Tastatur bedienbar
• Logische Überschriften-Hierarchie
• Formulare haben Labels
• Videos haben Untertitel
• Sprache ist im HTML definiert (<html lang="de">)

Fazit: Barrierefreiheit ist Qualität

Barrierefreie Websites sind bessere Websites – für alle. Sie sind besser strukturiert, performanter und SEO-freundlicher. Die Investition zahlt sich aus:

• Größere Zielgruppe erreichen
• Bessere SEO durch semantisches HTML
• Rechtssicherheit (BFSG)
• Positive Markenwahrnehmung

Starten Sie mit den Grundlagen und verbessern Sie kontinuierlich. Perfektion ist nicht das Ziel – Fortschritt ist das Ziel.

Nächste Schritte:

• Testen Sie Ihre Website mit dem WAVE Tool
• Prüfen Sie Ihre Farbkontraste
• Navigieren Sie Ihre Seite nur mit der Tastatur

---

Sie benötigen Unterstützung bei der barrierefreien Gestaltung Ihrer Website? Kontaktieren Sie mich für eine Analyse und Umsetzungsberatung.

Verwandte Inhalte

• Responsive Design - Mobile Optimierung unterstützt Accessibility
• SEO-Optimierung - Semantisches HTML verbessert beides
• Performance-Optimierung - Schnelle Ladezeiten helfen allen Nutzern