Barrierefreie Typografie: Schriftgrößen, Zeilenabstände und BFSG-Anforderungen im Design System

Die normativen WCAG-Anforderungen für Typografie

SC 1.4.12 Text Spacing (Level AA)

Das SC 1.4.12 definiert vier exakte Schwellenwerte. Bei Content, der mit Markup-Sprachen implementiert ist, darf kein Verlust von Inhalt oder Funktionalität auftreten, wenn ein Nutzer folgende Werte per Override setzt:

Diese Werte sind keine Pflicht-Defaults für Autoren. Die WCAG Note 1 stellt klar: Content ist nicht verpflichtet, diese Text-Spacing-Werte zu verwenden. Die Anforderung ist sicherzustellen, dass beim Override durch den Nutzer kein Inhalt oder keine Funktionalität verloren geht. Ein Design System muss also nicht zwingend line-height: 1.5 als Default setzen — es muss nur sicherstellen, dass Layouts bei diesen Override-Werten nicht brechen. In der Praxis empfiehlt es sich dennoch, die Werte als Mindest-Defaults zu setzen, da dies die Lesbarkeit verbessert und die Wahrscheinlichkeit von Override-Problemen reduziert.

SC 1.4.4 Resize Text (Level AA)

Text muss ohne assistive Technologie auf 200 % vergrößerbar sein, ohne Verlust von Inhalt oder Funktionalität. Browser-Zoom zählt als valider Mechanismus. Explizit als Failure dokumentiert: F94 — Verwendung von Viewport-Units (vw) für font-size, da diese beim Zoomen nicht skalieren.

SC 1.4.8 Visual Presentation (Level AAA)

Dieses optionale AAA-Kriterium geht deutlich weiter und verlangt einen Mechanismus, über den Nutzende folgende Einstellungen erreichen können: maximale Zeilenbreite von 80 Zeichen (40 bei CJK), kein Blocksatz, Zeilenabstand mindestens 1,5× innerhalb von Absätzen, Absatzabstand mindestens 1,5× des Zeilenabstands (effektiv 2,5× des einfachen Abstands) sowie 200 % Vergrößerung ohne horizontales Scrollen.

WCAG definiert keine Mindest-Schriftgröße

Weder WCAG 2.1 noch 2.2 spezifizieren eine Mindest-Schriftgröße für Fließtext. Die häufig zitierten 16 px sind eine Industrie-Empfehlung, kein normativer Wert. WCAG definiert lediglich „Large Text” für Kontrastschwellen: ≥ 18 pt (~24 px) bei normalem Schriftschnitt oder ≥ 14 pt Bold (~18,5 px).

BFSG vs. BITV 2.0 — das regulatorische Umfeld in Deutschland

Der Normkettenmechanismus des BFSG

Das BFSG selbst nennt keine WCAG-Version direkt. Die technische Bindung entsteht über eine Kette: Das BFSG verweist auf „harmonisierte Normen”, die eine Konformitätsvermutung auslösen. Die aktuell harmonisierte Norm ist EN 301 549 V3.2.1 (2021-03), die in Abschnitt 9 (Web) vollständig auf WCAG 2.1 Level A und AA verweist. Die geplante EN 301 549 V4.1.1, die WCAG 2.2 integriert, ist von ETSI in Arbeit. Empfehlung: Bereits jetzt nach WCAG 2.2 implementieren — sie ist vollständig rückwärtskompatibel zu 2.1.

Geltungsbereich und Ausnahmen

Ab dem 28. Juni 2025 gilt das BFSG für den B2C-Bereich der Privatwirtschaft. Betroffen sind E-Commerce (Online-Shops, Buchungsportale), Bankdienstleistungen, Telekommunikation, E-Books und Personenbeförderungsdienste. Die Kleinstunternehmen-Ausnahme greift nur für Dienstleistungen bei Unternehmen mit weniger als 10 Beschäftigten UND einem Jahresumsatz oder einer Bilanzsumme von maximal 2 Mio. €. Für Produkte gibt es keine Größenausnahme. Bei Verstößen drohen Bußgelder bis 100.000 € und Vertriebsverbote.

BFSG vs. BITV 2.0 — klare Abgrenzung

Die BITV 2.0 geht über reine WCAG-Konformität hinaus: Deutsche Gebärdensprache und Leichte Sprache auf der Startseite sind Pflicht, und der BITV-Test umfasst 38 zusätzliche Prüfschritte gegenüber reiner WCAG-Prüfung. Beide Standards konvergieren jedoch auf EN 301 549 — eine gut nach WCAG 2.1 AA umgesetzte Website erfüllt die Kernanforderungen beider Regelwerke.

CSS-Implementierung für barrierefreie Typografie

Warum rem statt px für Schriftgrößen

WCAG schreibt keine bestimmte CSS-Unit vor, doch die Konsequenzen unterscheiden sich fundamental. Browser-Zoom skaliert alle Units einschließlich px. Schriftgrößen-Einstellungen des Nutzers (im Browser-Menü von z.B. 16 px auf 24 px umgestellt) beeinflussen hingegen nur relative Units (rem, em, %). Pixel-basierte font-size-Deklarationen ignorieren diese Nutzereinstellung vollständig.

Die strategische Empfehlung: font-size immer in rem, Abstände zwischen Textelementen in rem, dekorative Eigenschaften wie border-width in px.

Der 62.5%-Trick — technisch korrekt, praktisch problematisch

Der Trick html { font-size: 62.5%; } setzt 1rem = 10px, was einfache Kopfrechnung ermöglicht. Mathematisch skaliert er korrekt. Das Problem liegt anderswo: Formular-Elemente (input, select, button) erben nicht vom body und rendern in der geschrumpften Root-Größe. Drittanbieter-Komponenten, die 1rem = 16px voraussetzen, werden 37,5 % zu klein dargestellt. Die moderne Alternative:

:root {
  /* Relative Größen ohne Root-Manipulation */
  --font-size-sm:   calc(14 / 16 * 1rem);  /* 0.875rem */
  --font-size-base: 1rem;                   /* 16px     */
  --font-size-lg:   calc(24 / 16 * 1rem);  /* 1.5rem   */
}

clamp() und Fluid Typography — die 2,5×-Regel

Fluid Typography via clamp() birgt ein spezifisches Accessibility-Risiko: Der vw-Anteil im bevorzugten Wert skaliert nicht beim Browser-Zoom, da sich die Viewport-Breite in CSS-Pixeln beim Zoom verkleinert und den Größenzuwachs teilweise kompensiert. Maxwell Barvian hat nachgewiesen, dass die Textgröße SC 1.4.4 erfüllt, wenn der Maximalwert ≤ 2,5× dem Minimalwert entspricht:

/* ✅ Konform: 2.5rem / 1rem = 2.5× */
h1 { font-size: clamp(1rem, 3vw + 0.5rem, 2.5rem); }

/* ❌ Nicht konform: 4rem / 1rem = 4× — WCAG Failure F94 */
h1 { font-size: clamp(1rem, 4vw, 4rem); }

min und max in clamp() müssen in rem (nicht px) definiert werden, damit Nutzer-Schriftgrößen-Einstellungen respektiert werden. Reine vw-Units ohne rem-Fallback sind als W3C Failure Technique F94 dokumentiert und schlagen SC 1.4.4 definitiv fehl.

Text Spacing Override korrekt implementieren

Das WCAG 1.4.12 Text Spacing Bookmarklet (Steve Faulkner / TPGi) injiziert folgendes CSS zum Testen:

* {
  line-height:    1.5   !important;
  letter-spacing: 0.12em !important;
  word-spacing:   0.16em !important;
}
p {
  margin-bottom: 2em !important;
}

Damit dieser Override funktioniert, muss das Design System bestimmte Anti-Patterns vermeiden: keine !important-Deklarationen auf Spacing-Eigenschaften im Autorencode, keine festen height-Werte auf Textcontainern (stattdessen min-height), kein overflow: hidden auf Containern mit variablem Textinhalt, keine pixelbasierten line-height-Werte (stattdessen unitless wie 1.5).

Design-Token-Architektur für WCAG 1.4.12

Drei-Schichten-Modell: Primitive → Semantic → Component

Ein robustes Token-System für barrierefreie Typografie folgt einer dreistufigen Hierarchie:

:root {
  /* Primitive Tokens — rohe Werte ohne Kontext */
  --font-size-300:          1rem;
  --line-height-normal:     1.5;
  --letter-spacing-normal:  0em;

  /* Semantic Tokens — zweckgebunden */
  --typography-body-size:        var(--font-size-300);
  --typography-body-line-height: var(--line-height-normal);

  /* Component Tokens — komponentengebunden */
  --card-body-font-size:    var(--typography-body-size);
  --card-body-line-height:  var(--typography-body-line-height);
}

Unitless line-height-Werte sind essenziell: line-height: 1.5 skaliert automatisch mit der aktuellen font-size, während line-height: 24px statisch bleibt und beim User-Override bricht.

Wie IBM Carbon, Material Design 3 und Atlassian Typografie-Tokens strukturieren

Kein etabliertes Design System erfüllt SC 1.4.12 vollständig über alle Textstile hinweg — die reale Compliance hängt davon ab, ob Layouts beim Override nicht brechen.

IBM Carbon verwendet zwei Type-Sets (Productive für UIs, Expressive für Marketing) mit einer mathematischen Skala (12, 14, 16, 18, 20, 24, 28, 32 px). Carbon nutzt Mixins wie @include type.type-style('body-01'), die Font-Size, Line-Height, Letter-Spacing und Font-Weight als Bundle setzen.

Material Design 3 organisiert 15 Typescale-Rollen in einer 5×3-Matrix (Display/Headline/Title/Body/Label × Large/Medium/Small). Nur Body Large (16 px/24 px) erreicht exakt 1,5× line-height. Body Medium (14 px/20 px) liegt bei 1,43×.

Atlassian nutzt rem-basierte Composite-Tokens: font.body.large (1rem/1.5rem = 1,5×) und font.body (0.875rem/1.25rem = 1,43×) auf einer Minor-Third-Skala.

Theme-basierte Accessibility — über Farbe hinaus

Durchdachte Accessibility-Themes gehen weit über reine Farbmodi hinaus. Ein leistungsfähiges Token-System ermöglicht separate Themes für erhöhte Lesbarkeit und verstärkten Kontrast — ohne das Corporate Design auf Schwarz-Weiß zu reduzieren:

/* Default */
:root {
  --typography-body-size:           1rem;
  --typography-body-line-height:    1.5;
  --typography-body-letter-spacing: 0em;
}

/* High-Readability Theme — mehr Luft, nicht mehr Grau */
[data-theme="high-readability"] {
  --typography-body-size:           1.25rem;
  --typography-body-line-height:    1.8;
  --typography-body-letter-spacing: 0.05em;
  --typography-paragraph-spacing:   2em;
}

/* High-Contrast Theme — Gewicht, Rahmen, Fokus */
[data-theme="high-contrast"] {
  --typography-body-weight: 500;
  --border-width-default:   2px;
  --focus-ring-width:       3px;
}

/* OS-Ebene: automatische Erkennung */
@media (prefers-contrast: more) {
  :root { /* High-Contrast-Werte */ }
}

@media (forced-colors: active) {
  /* Windows High Contrast Mode */
  :root {
    --color-text: CanvasText;
    --color-bg:   Canvas;
  }
}

Automatisierte Tests und häufige Bruchstellen

Was automatisiert testbar ist — und was nicht

axe-core (und damit Lighthouse) prüft SC 1.4.12 nur in einem sehr engen Scope: Erkannt werden ausschließlich Inline-Styles mit !important auf Spacing-Eigenschaften, die User-Overrides aktiv blockieren. Das fundamentale 1.4.12-Problem — ob Layouts beim Override visuell brechen — ist nicht vollständig automatisierbar, da es eine visuelle Bewertung erfordert.

Ein semi-automatisierter Ansatz mit Playwright:

// 1. WCAG-Override-CSS injizieren
await page.addStyleTag({
  content: `* {
    line-height: 1.5 !important;
    letter-spacing: 0.12em !important;
    word-spacing: 0.16em !important;
  }
  p { margin-bottom: 2em !important; }`
});

// 2. Abgeschnittene Container finden
const clipped = await page.evaluate(() => {
  return [...document.querySelectorAll('*')]
    .filter(el => {
      const s = getComputedStyle(el);
      return (s.overflow === 'hidden' || s.overflowY === 'hidden')
        && el.scrollHeight > el.clientHeight;
    })
    .map(el => el.tagName + '.' + el.className);
});

Die zehn häufigsten Bruchstellen beim Text Spacing Override

Präventions-Checkliste für das Design System

• Niemals feste height auf Textcontainern — immer min-height
• overflow: hidden auf Textcontainern durch auto oder visible ersetzen
• Unitless line-height-Werte verwenden (1.5, nicht 24px)
• Relative Units (em, rem) für alle Spacing-Eigenschaften
• Flexbox / Grid mit auto oder minmax() statt fixer Dimensionen
• Kein !important auf Spacing-relevanten Properties
• Text Spacing Bookmarklet-Tests an jedem Breakpoint durchführen

Kernpunkte

• Barrierefreie Typografie ist kein Feature, sondern eine architektonische Entscheidung.
• Die WCAG spezifiziert keine magischen Schriftgrößen — sie verlangt resiliente Layouts, die Nutzer-Anpassungen überleben.
• rem-basierte Font-Sizes, unitless line-height-Werte und flexible Container ohne feste Höhen erfüllen SC 1.4.12 praktisch nebenbei.
• Bei Fluid Typography mit clamp() gilt die 2,5×-Regel als sichere Grenze für SC 1.4.4.
• Das BFSG macht diese Anforderungen ab Juni 2025 über die Normkette EN 301 549 → WCAG 2.1 AA für den gesamten B2C-Sektor rechtsverbindlich.
• Wer nach WCAG 2.2 implementiert, ist bereits zukunftssicher für die kommende EN 301 549 V4.1.1.