NCA Social Media
Erstellt:
Aktualisiert:
Autor:
Roland Golla
Grüner Browser mit CSS Schriftzug, Person mit Tastatur navigiert, Rakete rechts

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 gilt das Barrierefreiheitsstärkungsgesetz. Es verpflichtet viele private Unternehmen in Deutschland zu barrierefreien Webseiten, Onlineshops und Apps. CSS ist dabei ein zentraler Hebel. Viele Erfolgskriterien der WCAG für Wahrnehmung und Bedienbarkeit setzt du direkt im Stylesheet um.

WCAG 2.2 ist seit Oktober 2023 W3C Empfehlung und brachte neun neue Erfolgskriterien. Mehrere davon betreffen CSS direkt: Der Tastatur Fokus darf nicht von Sticky Headern verdeckt werden, Klickflächen brauchen mindestens 24 mal 24 CSS Pixel. Mit Media Queries wie prefers-reduced-motion und prefers-color-scheme respektierst du zusätzlich die System Einstellungen deiner Nutzer.

Inhalt

CSS Barrierefreiheit mit NCA: Schnelle Hilfe vom Experten

Never Code Alone baut Frontends täglich mit Astro, React und Vue und testet sie mit Cypress und Cypress Cloud. Fokus Indikatoren, Kontraste, relative Einheiten und reduzierte Animationen gehören bei uns in jedes Design Token Set. Wir kennen die typischen CSS Fallen aus Accessibility Audits und wissen, welche Patterns WCAG 2.2 sauber erfüllen.

Für Teams, die ihr CSS an das Barrierefreiheitsstärkungsgesetz anpassen wollen, bietet NCA barrierefreies Webdesign und Accessibility Webdesign im Frontend. Wir unterstützen mit Frontend Development in Astro, React und Vue, mit Legacy Modernisierung für Symfony und Sulu CMS, in der alte CSS Strukturen gleich mit abgelöst werden, und mit Vibe Coding Consulting für KI-gestützte Komponentenentwicklung.

Lass uns sprechen
Finde das passende Angebot für dein Projekt
Anfrage-Konfiguration
Starten Sie Ihre Anfrage
Projektart
Infos
Nachricht

Eliminierung technischer Schulden mit PHPStan, Rector PHP und PHPUnit. Über 20 Jahre Praxiserfahrung in skalierbaren Backends.

CORE EXPERTISE

Gesetzliche Konformität & Inklusion. Optimierung von Performance und Conversion durch radikal nutzerzentriertes, universelles Design.

BFSG COMPLIANT

Skalierbare KI-Systeme mit echtem Code Ownership. CI/CD, Backup-Strategien und Infrastruktur, die mit deinem Team wächst.

ENTERPRISE READY

Warum CSS für Barrierefreiheit entscheidend ist

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 viele Menschen aus. Beide Extreme verfehlen das Ziel. Die Basis bleibt Semantic HTML.

Diese Aspekte der Barrierefreiheit steuerst du maßgeblich über CSS:

  • 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. Ein sauberes Responsive Design sorgt dafür, dass das auch bei 400 Prozent Zoom und auf kleinen Displays funktioniert.

WCAG 2.2: vier neue Kriterien, die jeden CSS Entwickler betreffen

WCAG 2.2 wurde im Oktober 2023 vom W3C verabschiedet. Im September 2026 erschien die europäische Norm EN 301 549 V4.1.1, die WCAG 2.2 übernimmt. Rechtliche Referenz für den European Accessibility Act und damit das BFSG bleibt bis zur Veröffentlichung im EU Amtsblatt noch V3.2.1 auf Basis von WCAG 2.1. Wer heute baut, zielt trotzdem auf WCAG 2.2. Vier der neun neuen Erfolgskriterien betreffen CSS direkt.

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. Für AA ist das keine Pflicht, aber ein guter Maßstab. 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.

Code: 
          
/* Scroll Padding gegen verdeckten Fokus */
html {
  scroll-padding-top: 5rem;
}

/* Mindestgrößen für Touch Targets */
button,
.icon-button,
[role="button"] {
  min-width: 2.75rem;
  min-height: 2.75rem;
}

Tastaturfokus mit :focus-visible richtig setzen

Der häufigste CSS Fehler in Sachen Barrierefreiheit ist nach wie vor das pauschale Entfernen des Browser Fokus Indikators mit outline: none ohne Ersatz. Damit wird der Tastatur Cursor unsichtbar. Wer per Tastatur, Schalter oder Sprachsteuerung navigiert, verliert die Orientierung. Mehr dazu im Glossar zur Keyboard Navigation.

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:

Code: 
          
/* Default Fokus deaktivieren, aber nur wenn :focus-visible ersetzt */
:focus:not(:focus-visible) {
  outline: none;
}

/* Universeller Fokus Indikator schwarz weiß */
:focus-visible {
  outline: 3px solid #000;
  box-shadow: 0 0 0 6px #fff;
  border-radius: 2px;
}

/* Variante für dunkle Themes umgekehrt */
.theme-dark :focus-visible {
  outline: 3px solid #fff;
  box-shadow: 0 0 0 6px #000;
}

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 mit prefers-reduced-motion respektieren

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

Auf Stufe AA gelten zwei harte Grenzen: Bewegte Inhalte, die länger als 5 Sekunden laufen, brauchen eine Pause Funktion (2.2.2). Nichts darf mehr als drei Mal pro Sekunde blitzen (2.3.1). Aber auch dezente Scroll Animationen, langsame Carousels und Hover Transitionen werden für betroffene Nutzer schnell zur Belastung. Eine globale Schutz Regel fängt die meisten Fälle ab:

Code: 
          
/* Globaler Schutz für alle Nutzer mit reduzierter Bewegung */
@media (prefers-reduced-motion: reduce) {
  *,
  *::before,
  *::after {
    animation-duration: 0.01ms !important;
    animation-iteration-count: 1 !important;
    transition-duration: 0.01ms !important;
    scroll-behavior: auto !important;
  }
}

/* Animationen nur für Nutzer ohne Präferenz */
@media (prefers-reduced-motion: no-preference) {
  .fade-in {
    animation: fade-in 600ms ease-out;
  }
}

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 und Kontrast: prefers-color-scheme und prefers-contrast

Dark Mode ist nicht nur Stil Frage, sondern kann ein Accessibility Feature sein. Menschen mit Lichtempfindlichkeit oder Migräne lesen auf dunklen Oberflächen oft deutlich entspannter. Andere Nutzer brauchen extra hohe Kontraste. Beides löst du mit zwei Media Queries. Mehr zu Farben und Farbsehschwäche steht im Glossar zu Color Accessibility.

Code: 
          
/* Dark Mode auf Basis der System Einstellung */
:root {
  color-scheme: light dark;
  --bg: #ffffff;
  --fg: #1a1a1a;
  --link: #0050b3;
}

@media (prefers-color-scheme: dark) {
  :root {
    --bg: #0f0f0f;
    --fg: #f5f5f5;
    --link: #7cb9ff;
  }
}

/* Höhere Kontraste für Nutzer die das wünschen */
@media (prefers-contrast: more) {
  :root {
    --fg: #000000;
    --link: #0000ff;
  }
}

body {
  background: var(--bg);
  color: var(--fg);
}

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.

Farbkontrast und Typografie: relative Einheiten statt Pixel

WCAG 1.4.3 verlangt für normalen Text mindestens 4.5:1 Kontrast, für großen Text 3:1. Für UI Komponenten und Fokus Indikatoren gilt nach 1.4.11 ebenfalls 3:1. Den Farbkontrast prüfst du mit den DevTools in Chrome und Firefox oder dem Colour Contrast Analyser von TPGi. WCAG 3 ist im Oktober 2026 noch Working Draft. Ein neues Kontrastmodell wie APCA wird diskutiert, ist aber kein verbindlicher Standard.

Bei der Typografie gilt eine simple Regel: niemals Pixel für Schriftgrößen. Sobald Nutzer ihre Browser Schriftgröße erhöhen, was viele Menschen mit Sehschwäche tun, ignoriert font-size: 14px diese Einstellung komplett. Mit rem skalieren alle Schriftgrößen proportional mit. Passende Werte für Zeilenabstände findest du im Beitrag zu line-height und Textabständen nach WCAG.

Code: 
          
/* Basis Schriftgröße auf 100 Prozent lassen, niemals festschreiben */
html {
  font-size: 100%; /* respektiert User Browser Einstellung */
}

body {
  font-size: 1rem;  /* 16px Default, skaliert mit User Einstellung */
  line-height: 1.6; /* mindestens 1.5 für gute Lesbarkeit */
}

/* Fluid Typography mit clamp() statt Media Queries */
h1 {
  font-size: clamp(1.75rem, 1.2rem + 2vw, 2.75rem);
  line-height: 1.2;
}

/* Lesbare Zeilenlänge: 45 bis 75 Zeichen */
article p {
  max-width: 70ch;
}

Die ch Einheit ist eine Geheimwaffe: sie misst Zeichenbreite und sorgt automatisch für lesbare Zeilenlängen. Sehr lange Zeilen erschweren vielen Menschen das Lesen, besonders bei Legasthenie oder Konzentrations Schwierigkeiten.

WCAG 2.1 vs WCAG 2.2: was sich für CSS Entwickler ändert

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.

Anforderung WCAG 2.1 WCAG 2.2 (neu)
Fokus sichtbar 2.4.7 Fokus muss sichtbar sein (AA), keine Mindestgröße 2.4.13 (AAA): Fokus mindestens so groß wie ein 2 CSS Pixel Rahmen, Kontrast 3:1 zwischen beiden Zuständen
Fokus verdeckt keine Regel 2.4.11 (AA): Fokus darf nicht vollständig von Sticky Headern oder Footern verdeckt werden
Klickflächen Größe 2.5.5 nur AAA, 44 mal 44 CSS Pixel 2.5.8 (AA): mindestens 24 mal 24 CSS Pixel
Drag Gesten keine Regel 2.5.7 (AA): Alle Drag Funktionen müssen per Klick erreichbar sein
Reduzierte Bewegung 2.3.3 nur AAA unverändert AAA, prefers-reduced-motion ist trotzdem Stand der Technik
Kontrast Text 1.4.3 mindestens 4.5:1 für Text, 3:1 für großen Text unverändert, Kontrastmodell für WCAG 3 noch offen
Outline none ohne Ersatz Verstoß gegen 2.4.7 Verstoß gegen 2.4.7, auf AAA zusätzlich gegen 2.4.13

Layout und visuelle Ordnung: CSS Grid, Flexbox und Reading Order

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.

Code: 
          
/* Sicher: HTML Reihenfolge wird visuell respektiert */
.card-grid {
  display: grid;
  grid-template-columns: repeat(auto-fit, minmax(20rem, 1fr));
  gap: 1.5rem;
}

/* Vorsicht: order bricht die Tab Reihenfolge */
.sidebar { order: 2; } /* Tastatur Nutzer landen erst woanders */

/* Container Queries für moderne komponenten basierte Responsiveness */
.card {
  container-type: inline-size;
}

@container (min-width: 30rem) {
  .card__title { font-size: 1.5rem; }
}

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.

Best Practices für barrierefreies CSS in 2026

Diese acht Regeln decken den Großteil aller CSS Accessibility Themen in der Praxis ab. Sie sind das, was wir in einem Accessibility Audit am häufigsten als kritisch 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.
Code: 
          
/* Visually Hidden Utility, sichtbar nur für Screen Reader */
.visually-hidden:not(:focus):not(:active) {
  clip: rect(0 0 0 0);
  clip-path: inset(50%);
  height: 1px;
  width: 1px;
  overflow: hidden;
  position: absolute;
  white-space: nowrap;
}

The focus indicator is to keyboard users what the mouse cursor is to mouse users.

Sara Soueidan, Inclusive Design Engineer und Accessibility Trainerin – A guide to designing accessible, WCAG-conformant focus indicators

Aus der NCA Praxis: was wir in CSS Audits regelmäßig finden

In Audits nach WCAG 2.2 tauchen immer wieder dieselben CSS Probleme auf. Drei davon sehen wir besonders oft:

  • Fokus fehlt: Der Fokus Indikator fehlt komplett oder ist kaum zu erkennen.
  • Pixel statt rem: Schriftgrößen in Pixel ignorieren die Browser Einstellung.
  • Animation ohne Schutz: Die Hero Animation läuft auch bei prefers-reduced-motion weiter.

Die Lösungen sind meist klein. Ein :focus-visible Block in der globalen CSS Datei, rem statt px in den Typografie Tokens, ein globaler @media (prefers-reduced-motion: reduce) Block. Drei Änderungen, die das Risiko nach BFSG deutlich senken. Wer mit Tailwind CSS arbeitet, verankert das direkt in der Konfiguration.

Damit Fehler nicht zurückkommen, prüfen wir Accessibility Regeln automatisiert mit Cypress E2E Tests und axe. Wie das aussieht, zeigt unser Beitrag zu axe DevTools und Cypress Accessibility Testing. Einen Überblick über weitere Werkzeuge gibt die Seite zu Accessibility Testing Tools.

CYPRESS.IO Ambassador und IT Consultant für QA Engenieering und Qualität in PHP Projekten.
Erreichen Sie unsere Spezialisten zu barrierefreien Webdesign

Wir sind hier, um Ihnen zu helfen. Gemeinsam meistern wir Ihre digitalen Herausforderungen und fördern die Inklusion im Internet. Lassen Sie uns Ihre Projekte mit barrierefreiem Webdesign erfolgreich machen.

Kostenlose Demo Jetzt anrufen

Häufige Fragen zu CSS und Barrierefreiheit

Die wichtigsten Fragen zu barrierefreiem CSS, kurz und konkret beantwortet.

Reicht WCAG 2.1 oder muss ich 2026 schon auf WCAG 2.2 umstellen?

Ziele 2026 direkt auf WCAG 2.2. Die Version ist seit Oktober 2023 W3C Empfehlung. Im September 2026 erschien EN 301 549 V4.1.1, die WCAG 2.2 übernimmt. Bis zur Veröffentlichung im EU Amtsblatt bleibt V3.2.1 mit WCAG 2.1 die rechtliche Referenz für das BFSG. Die neuen CSS Kriterien sind mit modernem Code aber schnell umgesetzt.

Wie groß muss der Fokus Indikator nach WCAG 2.2 in 2026 sein?

Auf Stufe AA verlangt WCAG 2.2 vor allem einen sichtbaren Fokus nach 2.4.7, der nach 2.4.11 nicht vollständig verdeckt ist. Die genaue Größe regelt 2.4.13 Focus Appearance auf Stufe AAA: mindestens die Fläche eines 2 CSS Pixel dicken Rahmens und 3:1 Kontrast zwischen fokussiertem und nicht fokussiertem Zustand. Ein 3 Pixel outline mit box-shadow erfüllt beides sicher.

Welche Mindestgröße brauchen Buttons 2026 nach WCAG 2.2?

24 mal 24 CSS Pixel sind seit WCAG 2.2 Pflicht auf Stufe AA, geregelt in 2.5.8. Die AAA Anforderung aus 2.5.5 liegt bei 44 mal 44 CSS Pixel. Für Touch Bedienung ist 44 mal 44 die sichere Wahl, Apple empfiehlt in den Human Interface Guidelines ebenfalls 44 Punkte. Gib Icon Buttons genug padding, statt nur das Icon zu vergrößern.

Ist outline none 2026 noch erlaubt?

Nur mit sichtbarem Ersatz über :focus-visible. Ein pauschales outline none ohne Ersatz verstößt gegen 2.4.7 Focus Visible auf Stufe AA. Das galt schon unter WCAG 2.1. Mit WCAG 2.2 kommt 2.4.11 hinzu, und wer AAA anstrebt, muss zusätzlich 2.4.13 Focus Appearance erfüllen. Ein eigener Indikator mit Dicke und Kontrast löst alle drei Anforderungen.

Muss ich 2026 Dark Mode anbieten, um barrierefrei zu sein?

Nein, WCAG schreibt keinen Dark Mode vor. prefers-color-scheme zu respektieren ist aber Stand der Technik. Für Menschen mit Lichtempfindlichkeit kann ein dunkles Theme lange Arbeit am Bildschirm erleichtern. Mit CSS Custom Properties und color-scheme: light dark ist die Umsetzung klein. Wichtig: Auch im Dark Mode gelten die Kontrastwerte aus WCAG 1.4.3.

Wie nutze ich prefers-reduced-motion richtig?

Setze eine globale Regel mit @media (prefers-reduced-motion: reduce), die animation, transition und scroll-behavior abschaltet oder stark verkürzt. Gezielte Animationen packst du in @media (prefers-reduced-motion: no-preference). So sehen nur Nutzer ohne Präferenz die Bewegung. Die Einstellung kommt direkt aus dem Betriebssystem, du musst keinen eigenen Schalter bauen.

Pixel oder rem für Schriftgrößen?

Nimm rem oder em. Pixel ignorieren die Schriftgröße, die Menschen mit Sehschwäche im Browser auf 125 oder 150 Prozent stellen. Mit rem skaliert die gesamte Typografie mit. Lass die Basis Schriftgröße auf dem html Element bei 100 Prozent. Für fluide Überschriften kombinierst du rem mit clamp(), damit sie auf allen Viewports lesbar bleiben.

Was ist der Unterschied zwischen :focus und :focus-visible?

:focus greift bei jedem Fokus, auch beim Mausklick. :focus-visible greift nur, wenn der Browser einen sichtbaren Fokus für sinnvoll hält, typisch bei Tastaturnavigation. Alle aktuellen Browser unterstützen :focus-visible. So bekommt dein Design saubere Klick Zustände, und Tastatur Nutzer sehen trotzdem immer, wo sie gerade sind.

Reicht für barrierefreies CSS ein automatischer Test?

Nein. Automatische Tools wie axe oder Pa11y finden einen Teil der Probleme zuverlässig, etwa zu geringe Kontraste oder fehlende Labels. Reading Order, verdeckter Fokus, sinnvolle Animationen und viele Zustände brauchen weiterhin manuelle Prüfung. Wir kombinieren deshalb axe in Cypress E2E Tests mit manuellen Audits per Tastatur und Screenreader.

Wie teste ich Tastaturnavigation am besten?

Tab einmal komplett durch die Seite, ohne Maus. Jedes Element braucht einen sichtbaren Fokus, keines darf hinter Headern oder Modals verschwinden. Skip Links müssen beim Fokus erscheinen, Formulare logisch erreichbar sein. Danach sicherst du die Tab Reihenfolge mit Cypress Tests ab, damit spätere Änderungen sie nicht unbemerkt brechen.

Welche CSS Einheit ist am besten für Zeilenlängen?

Die Einheit ch, weil sie sich an der Zeichenbreite der aktuellen Schrift orientiert. Eine max-width von 70ch ergibt meist eine gut lesbare Zeilenlänge zwischen 45 und 75 Zeichen, unabhängig von Schriftart und Schriftgröße. Sehr lange Zeilen erschweren vielen Menschen das Lesen, besonders bei Legasthenie oder Konzentrationsproblemen.

Wie stelle ich sicher, dass Sticky Header nicht den Fokus verdecken?

Setze scroll-padding-top auf das html Element, in der Höhe des Sticky Headers. Der Browser scrollt beim Tab Sprung dann passend, und der Fokus bleibt sichtbar. Das deckt WCAG 2.4.11 Focus Not Obscured (Minimum) auf Stufe AA ab, ganz ohne JavaScript. Prüfe zusätzlich Cookie Banner und fixe Footer, sie verdecken den Fokus genauso.