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 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.

Inhalt

CSS Barrierefreiheit mit NCA: Schnelle Hilfe vom Experten

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.

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 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: vier neue Kriterien, die jeden CSS Entwickler betreffen

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.

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 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:

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 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:

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 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.

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 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.

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. Lange Zeilen über 80 Zeichen verlieren Menschen mit Legasthenie oder Konzentrations Schwierigkeiten oft mitten im Lesen.

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, keine Mindestgröße 2.4.13 Fokus mindestens 2 CSS Pixel dick, Kontrast 3:1 zu beiden Zuständen
Fokus verdeckt keine Regel 2.4.11 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 empfohlen 2.5.8 AA Pflicht: mindestens 24 mal 24 CSS Pixel
Drag Gesten keine Regel 2.5.7 Alle Drag Funktionen müssen per Klick erreichbar sein
Reduzierte Bewegung 2.3.3 nur AAA unverändert AAA, aber per prefers-reduced-motion Standard 2026
Kontrast Text 1.4.3 mindestens 4.5:1 für Text, 3:1 für großen Text unverändert, APCA als Kandidat für WCAG 3
Outline none ohne Ersatz Verstoß gegen 2.4.7 Verstoß gegen 2.4.7 und 2.4.13 doppelt

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 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.
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;
}

Accessibility is the cornerstone of any website.

Manuel Matuzović, Frontend Entwickler und Accessibility Auditor, Autor Web Accessibility Cookbook – Web Accessibility Cookbook, O'Reilly

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

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.

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 zwölf häufigsten Fragen, die uns Teams und Auftraggeber zu barrierefreiem CSS stellen, kurz und konkret beantwortet.

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

WCAG 2.2 ist seit Oktober 2023 W3C Standard und in der europäischen EN 301 549 verankert, die wiederum die Basis fürs Barrierefreiheitsstärkungsgesetz ist. Wer heute neue Komponenten baut, sollte direkt auf WCAG 2.2 zielen. Die vier neuen CSS Kriterien sind mit modernem Code sauber umsetzbar.

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

Mindestens so groß wie ein 2 CSS Pixel dicker Rahmen um das Element, mit Kontrast 3:1 zwischen fokussiertem und nicht fokussiertem Zustand. In der Praxis bedeutet das: 3 Pixel solid outline plus zusätzliches box-shadow für hellen oder dunklen Hintergrund.

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

24 mal 24 CSS Pixel als AA Pflicht, 44 mal 44 als AAA Empfehlung. Bei Touch Bedienung empfehlen wir generell 44 mal 44, da das auch der Apple Human Interface Guideline entspricht. Icon Buttons mit ausreichend padding versehen, statt das Icon selbst zu vergrößern.

Ist outline none in 2026 noch erlaubt?

Nur in Kombination mit einem sichtbaren Ersatz Indikator über :focus-visible. Pauschales outline none ohne Ersatz war schon vor 2026 ein WCAG Verstoß und ist mit WCAG 2.2 noch deutlich gravierender, weil das Focus Appearance Kriterium hinzukommt.

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

WCAG schreibt keinen Dark Mode vor, aber prefers-color-scheme zu respektieren ist Stand der Technik. Für Menschen mit Photophobie oder Migräne ist Dark Mode oft die einzige Möglichkeit, lange am Bildschirm zu arbeiten. Mit CSS Custom Properties ist die Umsetzung minimal.

Wie nutze ich prefers-reduced-motion richtig?

Eine globale CSS Regel mit @media (prefers-reduced-motion: reduce) deaktiviert oder verkürzt animation, transition und scroll-behavior. Für gezielte Animationen die Variante @media (prefers-reduced-motion: no-preference) nutzen, damit Animationen nur Nutzern ohne Präferenz angezeigt werden.

Pixel oder rem für Schriftgrößen?

Immer rem oder em. Pixel ignoriert die Browser Schriftgröße, die viele Menschen mit Sehschwäche auf 125 oder 150 Prozent stellen. Mit rem skaliert die gesamte Typografie automatisch mit. Basis Schriftgröße auf html-Ebene auf 100 Prozent lassen.

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

:focus löst bei jedem Fokus aus, auch bei Maus Klick. :focus-visible nur bei Tastatur oder Screen Reader Fokus. Moderne Browser unterstützen :focus-visible flächendeckend. So bekommen Designer ihre cleanen Maus Klick Zustände und Tastatur Nutzer ihren sichtbaren Fokus.

Reicht für barrierefreies CSS ein automatischer Linter?

Linter wie axe oder Pa11y finden 30 bis 40 Prozent der Probleme zuverlässig. Kontraste, Fokus Sichtbarkeit, Touch Target Größen werden teils erkannt. Reading Order Probleme, prefers-reduced-motion oder subtile Kontrast Verläufe brauchen weiterhin manuelles Audit, idealerweise kombiniert mit Cypress E2E Tests.

Wie teste ich Tastaturnavigation am besten?

Tab durch die komplette Seite, ohne Maus. Jedes Element muss einen sichtbaren Fokus haben, keines darf hinter Headern oder Modals verschwinden. Skip Links müssen bei Fokus auftauchen. Form Controls müssen logisch erreichbar sein. Browser DevTools haben dafür mittlerweile gute Emulationen.

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

Die Einheit ch, weil sie die durchschnittliche Zeichenbreite der aktuellen Schriftart misst. Eine max-width von 70ch ergibt fast immer eine gut lesbare Zeilenlänge zwischen 45 und 75 Zeichen, unabhängig von Schriftart und Schriftgröße. Lange Zeilen über 80 Zeichen verlieren Leser mit kognitiven Einschränkungen.

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

Mit scroll-padding-top auf dem html Element, in derselben Höhe wie der Sticky Header. Der Browser scrollt dann beim Tab Sprung automatisch passend. Damit ist WCAG 2.4.11 Focus Not Obscured Minimum auf AA Niveau erfüllt, ohne zusätzliches JavaScript.