Was ist CSS in der Barrierefreiheit?

Cascading Style Sheets (CSS) ist die Stylesheet Sprache für das Web. CSS steuert das visuelle Erscheinungsbild von HTML, also Layout, Typografie, Farben, Abstände und Animationen. In der digitalen Barrierefreiheit entscheidet CSS direkt darüber, ob Menschen mit Seh-, Motorik- oder kognitiven Einschränkungen eine Webseite bedienen können. Schlechtes CSS macht Tastaturnavigation unsichtbar, erzeugt schlechte Kontraste und ignoriert System Einstellungen wie reduzierte Animationen.

Seit dem 28. Juni 2025 verpflichtet das Barrierefreiheitsstärkungsgesetz private Unternehmen in Deutschland zu barrierefreien Webseiten und Apps. CSS ist dabei einer der zentralen Hebel, weil die meisten WCAG Erfolgskriterien für visuelle Wahrnehmung und Bedienbarkeit direkt über CSS umgesetzt werden.

WCAG 2.2 hat 2023 vier neue Erfolgskriterien eingeführt, die fast alle CSS Code betreffen: Fokus Indikatoren müssen größer und kontrastreicher werden, Klickflächen mindestens 24 mal 24 CSS Pixel groß sein, und der Tastatur Fokus darf nicht von Sticky Headern verdeckt werden. Mit modernem CSS und Media Queries wie prefers-reduced-motion und prefers-color-scheme erfüllst du diese Anforderungen sauber.

Never Code Alone arbeitet seit Jahren an barrierefreien Webprojekten für Mittelstand und Konzerne. Unser eigener Stack mit Astro, React und Vue setzt die WCAG 2.2 Kriterien für Fokus Indikatoren, Kontraste und reduzierte Animationen produktiv um. Wir kennen die typischen CSS Fallen aus Dutzenden Audits und wissen, welche Patterns 2026 wirklich Compliance liefern statt Pseudo Konformität.

Wenn dein Team CSS so schreiben will, dass es das Barrierefreiheitsstärkungsgesetz erfüllt und Screenreader, Tastatur Nutzer und Menschen mit Seheinschränkungen gleichermaßen abholt, hilft NCA mit barrierefreiem Webdesign Consulting, mit WCAG Audits, mit Frontend Beratung in Astro und mit Symfony und Sulu CMS Migrationen, in denen wir veraltete CSS Strukturen direkt mit ablösen. Auch unsere Vibe Coding Beratung nutzen Teams, die KI gestützt schneller zu barrierefreien Komponenten kommen wollen.

HTML liefert die semantische Struktur, CSS macht sie nutzbar. Eine technisch korrekte HTML Seite ohne CSS ist zwar prinzipiell zugänglich, aber für sehende Nutzer kaum bedienbar. Eine optisch perfekte Seite mit CSS, das Tastaturfokus versteckt oder Kontraste zerstört, schließt dagegen Millionen Menschen aus. Beide Extreme verfehlen das Ziel.

Folgende Aspekte von Barrierefreiheit werden zu 80 Prozent oder mehr über CSS gesteuert:

• Sichtbarkeit des Tastaturfokus: :focus-visible, outline, box-shadow
• Farbkontraste: Hintergrund- und Textfarben, Border, Fokus Indikatoren
• Skalierbarkeit der Typografie: relative Einheiten wie rem, em, clamp()
• Klickflächen Größen: min-width, min-height, padding
• Reduzierte Bewegung: prefers-reduced-motion
• Dark Mode und Kontrast: prefers-color-scheme, prefers-contrast
• Responsive Layout: Container Queries, Flexbox, Grid

Wer CSS strategisch einsetzt, verbessert die Nutzererfahrung für alle. Tastatur Nutzer profitieren von klaren Fokus Indikatoren, ältere Menschen von skalierbarer Typografie, Menschen mit vestibulären Störungen von prefers-reduced-motion. Gleichzeitig sinken Support Anfragen und Abbrüche im Checkout. Inklusion und Conversion gehen hier Hand in Hand.

WCAG 2.2 wurde im Oktober 2023 vom W3C verabschiedet und ist seit 2025 in der europäischen EN 301 549 verankert, die wiederum die Basis für das deutsche Barrierefreiheitsstärkungsgesetz ist. Vier der neun neuen Erfolgskriterien betreffen direkt CSS Code.

2.4.11 Focus Not Obscured, Level AA: Wenn ein Element den Tastaturfokus erhält, darf es nicht vollständig durch andere Inhalte verdeckt werden. Sticky Header, fixe Footer oder ein Cookie Banner können diese Anforderung schnell brechen. Lösung mit CSS: scroll-padding-top auf das Wurzel Element setzen, damit der Browser beim Fokus Sprung passend scrollt.

2.4.13 Focus Appearance, Level AAA: Der Fokus Indikator muss mindestens so groß sein wie ein 2 CSS Pixel dicker Rahmen um das Element und ein Kontrast Verhältnis von 3:1 zwischen fokussiertem und nicht fokussiertem Zustand haben. In der Praxis bedeutet das: kein outline: 0 ohne Ersatz, und der Ersatz braucht Dicke und Kontrast.

2.5.8 Target Size Minimum, Level AA: Klick und Tippflächen müssen mindestens 24 mal 24 CSS Pixel groß sein, mit Ausnahmen für Inline Links im Fließtext. CSS Umsetzung: min-width und min-height auf Buttons, ausreichendes padding auf Icon Buttons.

2.5.7 Dragging Movements, Level AA: Funktionen mit Drag Gesten müssen alternativ per einfachem Klick erreichbar sein. CSS sorgt hier dafür, dass die alternativen Buttons sichtbar genug sind und die Klickflächen die 24 mal 24 Pixel Regel erfüllen.

Der häufigste CSS Fehler in Sachen Barrierefreiheit ist nach wie vor das pauschale Entfernen des Browser Fokus Indikators mit outline: none ohne adäquaten Ersatz. Damit wird der Tastatur Cursor unsichtbar. Für rund 7 Prozent aller Webnutzer, die regelmäßig per Tastatur navigieren, ist die Seite damit faktisch unbedienbar.

Die moderne Lösung heißt :focus-visible. Diese Pseudo Klasse zeigt den Fokus Indikator nur dann, wenn ein Element per Tastatur fokussiert wird, nicht aber bei Maus Klick. So bekommen Designer ihre sauberen Klick Zustände und Tastatur Nutzer ihren sichtbaren Fokus. :focus-visible wird von allen modernen Browsern unterstützt.

Ein universeller Fokus Indikator nach Sara Soueidan kombiniert eine schwarze und eine weiße Linie. So funktioniert er auf jedem Hintergrund, hell wie dunkel, und erfüllt das 3:1 Kontrast Kriterium aus WCAG 2.2:

Wichtig: der Fokus Indikator gehört auf alle interaktiven Elemente, also Links, Buttons, Form Felder, custom Komponenten mit tabindex und Skip Links. Skip Links machen erst Sinn, wenn sie bei Fokus sichtbar werden.

Animationen und Parallax Effekte können bei Menschen mit vestibulären Störungen Schwindel, Übelkeit oder Migräne auslösen. WCAG 2.3.3 verlangt, dass nicht essentielle Animationen abschaltbar sind. Moderne Betriebssysteme haben dafür eine System Einstellung, die per Media Query prefers-reduced-motion abgefragt wird.

Die Faustregel: wenn die Animation länger als 5 Sekunden dauert oder mehr als drei Mal pro Sekunde flackert, ist sie kritisch. Aber auch dezente Scroll Animationen, langsame Carousels und Hover Transitionen werden für betroffene Nutzer schnell zur Belastung. Eine global wirksame Schutz Regel deckt 90 Prozent der Fälle ab:

Vergiss scroll-behavior: smooth nicht. Sanftes Scrollen wirkt elegant, kann aber bei Sprung Navigationen für betroffene Nutzer extrem unangenehm sein. Die Regel oben deaktiviert das automatisch.

Dark Mode ist nicht nur Stil Frage, sondern ein Accessibility Feature. Menschen mit Photophobie, Migräne oder bestimmten Sehbedingungen brauchen dunkle Oberflächen, um eine Webseite überhaupt lesen zu können. Andere Nutzer brauchen extra hohe Kontraste. Beides löst du mit zwei Media Queries.

Wichtig ist die Zeile color-scheme: light dark. Sie signalisiert dem Browser, dass die Seite beide Modi unterstützt, und sorgt dafür, dass auch Scrollbars, Form Controls und Default Styles passend dargestellt werden. Ohne diesen Hinweis bleiben System Elemente im falschen Modus stehen.

WCAG 1.4.3 verlangt für normalen Text mindestens 4.5:1 Kontrast, für großen Text und UI Elemente 3:1. Werkzeuge wie der Color Contrast Analyzer von TPGi oder das DevTools Panel in Chrome und Firefox prüfen das in Sekunden. Für 2026 gilt zusätzlich: APCA als modernes Kontrast Modell wird in WCAG 3 voraussichtlich Standard, ist aktuell aber noch optional.

Bei der Typografie gilt eine simple Regel: niemals Pixel für Schriftgrößen. Sobald Nutzer ihre Browser Schriftgröße erhöhen, was Millionen Menschen mit Sehschwäche tun, ignoriert font-size: 14px diese Einstellung komplett. Mit rem skalieren alle Schriftgrößen proportional mit.

Die ch Einheit ist eine Geheimwaffe: sie misst Zeichenbreite und sorgt automatisch für lesbare Zeilenlängen. Lange Zeilen über 80 Zeichen verlieren Menschen mit Legasthenie oder Konzentrations Schwierigkeiten oft mitten im Lesen.

Wenn deine Seite WCAG 2.1 erfüllt, bist du auf dem richtigen Weg, aber noch nicht am Ziel. WCAG 2.2 ist additiv: alle 2.1 Kriterien bleiben gültig, vier neue kommen hinzu, die direkt CSS betreffen. Die folgende Tabelle zeigt, was du im Stylesheet ergänzen musst.

Moderne CSS Layouts mit Grid und Flexbox können die visuelle Reihenfolge unabhängig vom HTML steuern. Genau hier lauert eine der gefährlichsten Accessibility Fallen: die Tab Reihenfolge folgt immer dem HTML, nicht dem CSS. Wer per order oder flex-direction: row-reverse die visuelle Reihenfolge umdreht, erzeugt für Tastatur Nutzer einen Sprung Marathon.

WCAG 1.3.2 Meaningful Sequence verlangt: visuelle und programmatische Reihenfolge müssen übereinstimmen. Die Regel ist simpel: strukturiere immer im HTML, gestalte mit CSS. Wenn ein Element visuell zuerst kommen soll, sollte es auch im HTML zuerst stehen. Ausnahmen sind selten und gehören diskutiert.

Tipp: Container Queries lösen seit Anfang 2023 viele Probleme, die früher nur über JavaScript gingen. Komponenten passen sich an ihre Container Breite an, nicht an die Viewport Breite. Das vereinfacht barrierefreie, modulare Designs deutlich.

Diese acht Regeln decken den Großteil aller CSS Accessibility Themen in der Praxis ab. Sie sind das, was wir in NCA Audits am häufigsten als kritisch oder hochpriorisiert markieren.

1. Niemals outline: 0 oder outline: none ohne Ersatz. Wenn doch, sofort :focus-visible mit sichtbarem Indikator setzen.
2. Relative Einheiten überall: rem und em für Schriftgrößen, ch für Zeilenlängen, vw und % nur mit Bedacht.
3. Mindestens 4.5:1 Kontrast für Text, 3:1 für UI Komponenten und Fokus Indikatoren.
4. Klickflächen mindestens 24 mal 24 CSS Pixel, besser 44 mal 44 für Touch.
5. Animationen immer mit prefers-reduced-motion absichern.
6. Visuelle und HTML Reihenfolge synchron halten, order nur in absoluten Ausnahmen.
7. Skip Links mit sichtbarem Fokus Zustand statt display: none.
8. Form Controls niemals visuell verstecken ohne visually-hidden Utility Klasse, die für Screen Reader erreichbar bleibt.

In unseren WCAG Audits bei mittelständischen und Konzern Kunden sehen wir immer wieder dieselben CSS Probleme. Drei davon kommen in fast jedem Projekt vor: erstens fehlt der Fokus Indikator komplett oder ist so dezent, dass er auf 5 Meter Entfernung nicht erkennbar wäre. Zweitens wurde die Schriftgröße in Pixel angegeben und respektiert User Browser Einstellungen nicht. Drittens fehlt prefers-reduced-motion für die Hero Animation auf der Startseite.

Spannend: die Lösungen sind meist klein. Ein :focus-visible Block in der globalen CSS Datei, der Wechsel von px auf rem in den Typografie Tokens, ein globales @media (prefers-reduced-motion: reduce) Block. Drei Änderungen, die das Compliance Risiko nach BFSG dramatisch senken.

NCA hilft Teams bei genau solchen Schritten mit barrierefreiem Webdesign Consulting, mit Astro Frontend Beratung, mit Symfony und Sulu Refactorings, in denen veralteter CSS Code mit abgelöst wird, und mit Vibe Coding Beratung für Teams, die KI gestützt schneller zu barrierefreien Komponenten kommen wollen. Auch unsere Cypress E2E Tests prüfen Accessibility Regeln gleich mit, statt sie als nachgelagertes Audit zu behandeln.

Die zwölf häufigsten Fragen, die uns Teams und Auftraggeber zu barrierefreiem CSS stellen, kurz und konkret beantwortet.