Barrierefreiheit im Web (WCAG 2.2) für Designer

Barrierefreiheit im Web bedeutet, digitale Inhalte und Interfaces so zu gestalten, dass Menschen mit unterschiedlichen körperlichen, kognitiven und technischen Voraussetzungen gleichwertig darauf zugreifen können.

Rubrik: Mediendesign & Digitale Medien · Unterrubrik: Web-Grundlagen · Niveau: Fortgeschritten Synonyme / Auch bekannt als: Web Accessibility, A11y (kurz für Accessibility), Inklusive Gestaltung, WCAG-Konformität

Was ist Barrierefreiheit im Web?

Das Web wurde von Tim Berners-Lee mit dem Prinzip entworfen, universell zugänglich zu sein. In der Realität scheitern viele Websites daran: kleiner Text, fehlende Kontraste, fehlende Alt-Texte, keine Tastaturnavigation. Das schließt Millionen von Menschen aus.

Nach Schätzungen der WHO (2023) leben etwa 1,3 Milliarden Menschen mit einer Behinderung weltweit – rund 16 % der Weltbevölkerung. Dazu kommen temporäre Einschränkungen (gebrochener Arm, helles Sonnenlicht auf dem Smartphone-Bildschirm) und altersbedingte Einschränkungen.

Die Web Content Accessibility Guidelines (WCAG) des W3C sind der internationale Standard für barrierefreies Web-Design. Die aktuell gültige Version ist WCAG 2.2 (2023). In Deutschland ist Barrierefreiheit für öffentliche Websites gesetzlich vorgeschrieben (BITV 2.0, die WCAG 2.1 umsetzt).

Erklärung

Die vier WCAG-Prinzipien (POUR)

P – Perceivable (Wahrnehmbar) Alle Inhalte müssen wahrgenommen werden können, unabhängig von Sinnesmodalität.

• Alt-Texte für Bilder
• Untertitel für Videos
• Ausreichende Kontraste

O – Operable (Bedienbar) Alle Funktionen müssen bedienbar sein, auch ohne Maus.

• Tastaturnavigation
• Keine Zeitlimits für wichtige Aktionen
• Keine Animations-Fallen (CSS-Animationen für Designer verstehen)

U – Understandable (Verständlich) Inhalte und Bedienung müssen verständlich sein.

• Klare Sprache
• Vorhersehbares Verhalten
• Fehler-Erklärungen in Formularen

A – Robust Inhalte müssen von aktuellen und zukünftigen Technologien interpretierbar sein.

• Semantisches HTML
• Korrekte ARIA-Labels

Konformitätsstufen

WCAG definiert drei Stufen:

• Level A: Minimum, ohne das Barrierefreiheit schwer oder unmöglich ist
• Level AA: Standard-Ziel für die meisten Projekte, gesetzliche Anforderung in vielen Ländern
• Level AAA: Höchste Stufe, für spezialisierte Zielgruppen

Wichtige Design-relevante Kriterien

Kontrastverhältnisse (WCAG 1.4.3 / 1.4.11)

• Normaler Text: mindestens 4,5:1 (Level AA)
• Großer Text (18 pt / 14 pt bold): mindestens 3:1 (Level AA)
• UI-Komponenten (Rahmen, Icons): mindestens 3:1 (Level AA, 1.4.11)
• Für Level AAA: 7:1 für normalen Text

Wichtig: Kontrast gilt nicht nur für Textfarbe auf Hintergrundfarbe, sondern auch für Fokus-Indikatoren (sichtbarer Fokusring bei Tastaturnavigation) und interaktive Elemente.

Mindest-Textgröße (WCAG 1.4.4) Text muss auf 200 % vergrößert werden können, ohne dass Inhalte abgeschnitten werden. Das betrifft die Zoom-Funktion des Browsers, nicht nur die Schriftgröße.

Touch-Target-Größe (WCAG 2.5.8 – neu in 2.2) Interaktive Elemente müssen mindestens 24 × 24 px groß sein (Level AA in WCAG 2.2). Empfehlung: 44 × 44 px (Apple) oder 48 × 48 dp (Google).

Fokus-Sichtbarkeit (WCAG 2.4.11 / 2.4.12 – neu in 2.2) Der Tastaturfokus muss sichtbar sein. Viele Designs entfernen den Browser-Standard-Fokusring aus ästhetischen Gründen ohne Ersatz – ein gravierendes Barrierefreiheitsproblem.

Farbunabhängigkeit (WCAG 1.4.1) Information darf nicht ausschließlich über Farbe vermittelt werden. Ein roter Rahmen bei Fehlern ist nicht ausreichend – zusätzlich braucht es ein Fehler-Icon oder Text.

Animated Content (WCAG 2.3.3) Animationen, die mehr als dreimal pro Sekunde blinken, können Krampfanfälle auslösen. Bewegte Elemente müssen mit prefers-reduced-motion deaktivierbar sein (CSS-Animationen für Designer verstehen).

Neue Kriterien in WCAG 2.2

• 2.4.11 Focus Appearance (Minimum): Fokus-Indikator muss mindestens 2 px breit und ausreichend kontrastreich sein
• 2.5.7 Dragging Movements: Aktionen, die Ziehen erfordern, müssen auch ohne Ziehen ausführbar sein
• 2.5.8 Target Size (Minimum): 24 × 24 px Mindestgröße für Klickziele
• 3.2.6 Consistent Help: Hilfefunktionen müssen konsistent platziert sein

Beispiele

Alt-Text für Bilder: Ein Produktfoto ohne Alt-Text ist für Screenreader-Nutzer nicht zugänglich. Der Alt-Text sollte den Inhalt beschreiben: alt="Rotes Ledersofa mit drei Sitzplätzen" – nicht alt="Bild" oder alt="IMG_0042.jpg".

Formular-Fehler: Statt Die Eingabe ist ungültig in roter Farbe: Ein Fehler-Icon + fett gedruckter Text + eine Erklärung: Bitte geben Sie eine gültige E-Mail-Adresse ein (Beispiel: name@domain.de).

Fokus-Ring: In einem Custom-Design wurde outline: none für alle Elemente gesetzt. Keyboard-Nutzer können nicht mehr erkennen, welches Element fokussiert ist. Fix: Custom-Fokus-Indikator mit mindestens 3:1 Kontrast zum umgebenden Element.

In der Praxis

Barrierefreiheit im Design-Prozess

Barrierefreiheit sollte von Anfang an mitgedacht werden, nicht als Nachbesserung. In der Designphase:

1. Kontraste prüfen: Bei jeder Farbkombination im Figma-Design den Kontrast prüfen (Stark Plugin oder Figma Accessibility Checker)
2. Focus States designen: Alle interaktiven Elemente haben einen sichtbaren Fokuszustand – als eigenen State in Figma
3. Alt-Texte dokumentieren: Im Handoff an Entwickler: Figma, Zeplin, Storybook für alle Bilder Alt-Text-Entwürfe mitgeben
4. Farbunabhängigkeit prüfen: Design in Graustufen betrachten – funktioniert es noch?
5. Touch-Targets messen: Alle Buttons/Links mindestens 44 × 44 px

Barrierefreiheits-Tools für Designer

• Stark (Figma Plugin): Kontrast-Check, Colorblind-Simulation, Focus-Order
• Figma Accessibility Checker: Automatische WCAG-Prüfungen
• Color Oracle: Desktop-App für Farbenblindheits-Simulation
• WebAIM: https://webaim.org – Ressourcen, Checker, Tutorials

Rechtliche Lage in Deutschland

Die BITV 2.0 (Barrierefreie-Informationstechnik-Verordnung) verpflichtet öffentliche Stellen des Bundes zur WCAG 2.1 AA Konformität. Das Barrierefreiheitsstärkungsgesetz (BFSG) erweitert ab 2025 diese Pflicht auf bestimmte private Angebote (E-Commerce, Bankwesen, Telekommunikation).

Vergleich & Abgrenzung

Häufige Fragen (FAQ)

Gilt Barrierefreiheit nur für Behinderungen? Nein. Barrierefreiheit hilft allen: alten Nutzern mit Sehproblemen, Eltern mit Kind auf dem Arm (Einhandnutzung), Menschen in lautem Umfeld (Untertitel), Nutzern mit langsamem Internetzugang.

Wie viel Aufwand ist barrierefreies Design? Bei konsequenter Integration von Anfang an: etwa 10–20 % Mehraufwand. Als Nachbesserung am Ende: oft das Mehrfache. "Bake in, don't bolt on" ist die Devise.

Muss meine Website WCAG 2.2 AA erfüllen? Abhängig von der Rechtsform und dem Land. Für öffentliche Stellen: ja. Für private Unternehmen: ab 2025 in vielen Branchen ja (BFSG). Für alle: aus ethischen und geschäftlichen Gründen empfohlen.

Verwandte Einträge

• Dark Mode Design: Farben und Kontraste – Kontraste im Dark Mode
• Farben im Web: HEX, RGB, HSL, oklch – Farben und Kontrastverhältnisse
• Webfonts: Einbindung, Performance, Lizenzen – Lesbare Typografie
• CSS-Animationen für Designer verstehen – Reduced Motion
• Mobile First: Design-Philosophie – Touch-Targets und Bedienbarkeit
• Handoff an Entwickler: Figma, Zeplin, Storybook – Barrierefreiheits-Anforderungen übergeben
• Design Systems: Von Figma zu Code – Barrierefreiheit systematisch verankern

Weiterführend

• W3C (2023). Web Content Accessibility Guidelines (WCAG) 2.2.
• Treviranus, J. (Hrsg.) (2014). Inclusive Design: Implementation Guide. IDRC.
• Faulkner, S. & Eggert, E. (2019). HTML5 Accessibility.
• WebAIM (2024). Introduction to Web Accessibility.
• Bundesfachstelle Barrierefreiheit (2024). BITV 2.0 und WCAG.