Fluide Typografie und WCAG 1.4.4: Der Zoom-Test

Fluide Typografie kann WCAG 1.4.4 (Textgröße ändern) erfüllen, und ob sie es tut, entscheidet die Arithmetik innerhalb des clamp: Die rem-Terme reagieren auf Zoom und auf Schriftgrößen-Einstellungen, der vw-Term tut es nicht. Je größer der rem-Anteil einer fluiden Größe, desto näher kommt der Text an echte 200 %, wenn du auf 200 % zoomst. Ein sanfter Verlauf wie 16→18px ist etwa zu 90 % rem-getrieben und zoomt nahezu proportional; ein steiler Verlauf verlagert Gewicht auf den Viewport-Term und verschlechtert die Zoom-Reaktion stillschweigend.

Dieses Verhältnis — wie viel einer Größe in rem statt in vw steckt — ist das Thema dieses Leitfadens. Es ist der Barrierefreiheits-Tiefgang unseres Leitfadens zur fluiden Typografie: der Fehlermodus, der fluider Typografie eigen ist, die clamp-Barrierefreiheitszahlen, die darüber entscheiden, und ein Testprotokoll, das du in zehn Minuten durchlaufen kannst.

Was verlangt WCAG 1.4.4?

Erfolgskriterium 1.4.4, Textgröße ändern verlangt, dass Text sich bis auf 200 Prozent vergrößern lässt, ohne dass Inhalt oder Funktionalität verloren geht. Zwei Nutzer-Mechanismen zählen, und sie sind verschieden: der Ganzseiten-Zoom, der das CSS-Pixel selbst skaliert, und die Schriftgrößen-Einstellung des Browsers, die die Standardgröße ändert, auf die sich rem-Einheiten beziehen. Ein robustes System reagiert auf beide. Reiner Viewport-Einheiten-Text reagiert auf keinen von beiden — was unbedachte fluide Typografie zu einer der wenigen modernen Techniken macht, die dieses Kriterium glatt reißen kann.

Warum erreicht der Browser-Zoom den vw-Term nicht?

Zoom funktioniert, indem er das CSS-Pixel skaliert: Bei 200 % Zoom entspricht ein CSS-Pixel zwei Geräte-Pixeln. Alles, was in px oder rem angegeben ist, verdoppelt sich daher physisch. Aber der Viewport ist jetzt halb so viele CSS-Pixel breit — ein Fenster von 800 Geräte-Pixeln Breite wird zu einem 400-CSS-Pixel-Viewport — und vw ist gegen diesen Viewport definiert. Die beiden Effekte heben sich auf: 1vw sind 8 Geräte-Pixel vor dem Zoom (1 % von 800) und 8 Geräte-Pixel danach (1 % von 400, jedes doppelt so viel wert). Ob gezoomt oder nicht, eine reine vw-Größe rendert in derselben physischen Größe. Der Text ist zoom-taub.

Ein fluides clamp mischt beide Term-Arten, also reagiert es teilweise — und „teilweise” lässt sich berechnen.

Wie viel Zoom-Reaktion behält ein clamp?

Nimm das Root-clamp für einen 16→18px-Verlauf über die Viewports 360→1280:

font-size: clamp(1rem, 0.9511rem + 0.2174vw, 1.125rem);

Bei einem 800px breiten Fenster beträgt der bevorzugte Wert ≈15,22px aus dem rem-Term plus ≈1,74px aus dem vw-Term — insgesamt ≈16,96px, aufgeteilt etwa 90/10 zugunsten von rem.

Jetzt zoome auf 200 %. Der rem-Anteil verdoppelt sich auf ≈30,43px physischer Größe; der vw-Anteil bleibt bei ≈1,74px. Summe: ≈32,17px — etwa 190 % des Originals. Knapp unter proportional, und der fehlende Anteil ist genau der vw-Anteil. In der Praxis besteht das: Der Text reagiert kräftig, und echte 200 % kommen eine Stufe später auf der Zoom-Skala an, gut innerhalb dessen, was Browser bieten.

Vergleiche ein hypothetisch steileres clamp — clamp(0.75rem, 0.5rem + 1vw, 2rem) — das am selben 800px-Fenster 8px rem und 8px vw ergibt, eine 50/50-Aufteilung. Bei 200 % Zoom erreicht es 24 Geräte-Pixel: 150 % seiner ursprünglichen Größe. Damit die Nutzerin den Text tatsächlich verdoppelt, muss sie auf 300 % zoomen. Das verfehlt die Absicht des Kriteriums, und Audits kennzeichnen es häufig.

Die allgemeine Regel fällt aus der Arithmetik heraus: Je steiler die Steigung, desto mehr der Größe steckt in vw, und desto schlechter die Zoom-Reaktion. Steigung ist nicht nur eine Design-Entscheidung darüber, wie schnell Text über Bildschirme hinweg wächst — sie ist eine Barrierefreiheits-Entscheidung darüber, wie viel des Textes der Zoom erreichen kann.

Eine weitere Konsequenz, die man kennen sollte: Die Grenzen des clamp sind Barrierefreiheits-Auffangnetze. Während du zoomst, schrumpft der CSS-Viewport, der bevorzugte Wert sinkt, und irgendwann übernimmt die Min-Grenze — jenseits von etwa 220 % Zoom im 800px-Beispiel. Ab da ist die Größe reines rem und die Reaktion vollständig proportional. Die flachen Zonen eines clamp sind sein sicherstes Terrain.

Öffne dieses Root-clamp in Scale Composer — der Fluid-Modus hält die vier Zahlen dahinter (Basis 16→18, Viewports 360→1280), der CSS-Export schreibt das clamp mit auskommentiertem Pixel-Bereich, und der DTCG-Export trägt dieselben vier Parameter, sodass die Arithmetik oben reproduzierbar ist.

Wie testest du fluide Typografie auf Vergrößerung?

Drei Prüfungen, geordnet nach dem, was sie aufdecken:

1. Zoome auf 200 %. Fließtext sollte in nahezu doppelter physischer Größe rendern. Wenn er sichtbar hinterherhinkt — ein bisschen wächst, dann stockt — ist der vw-Anteil irgendwo zu hoch.
2. Stell die Schriftgrößen-Einstellung des Browsers auf Groß. Rem-basierter fluider Text wächst; px-verankerter und vw-verankerter Text ignoriert die Einstellung vollständig. Das deckt einen anderen Fehler auf als der Zoom, ist also nicht redundant.
3. Prüfe bei vp-min, vp-max und im mittleren Bereich. Unter dem Min und über dem Max ist das clamp flach — reines rem, die sichersten Zonen. Im mittleren Bereich trägt der vw-Term seinen größten Anteil, führe die Zoom-Prüfung für fluide Typografie also bei einer mittleren Breite durch, nicht nur bei einer bequemen Desktop-Größe.

Warum macht ein Root-clamp das Audit einfacher?

Ein fluides System pro Element beschert dir Dutzende clamps, jedes mit eigener Steigung und eigenem rem/vw-Verhältnis — Dutzende Stellen, an denen sich eine steile Steigung verstecken kann. Die Root-clamp-Architektur kehrt das um: ein clamp auf der Root-Schriftgröße, alles andere in rem, das darauf reitet. Das Zoom-Verhalten des gesamten Systems ist das Zoom-Verhalten eines einzigen Ausdrucks, einmal verifiziert.

Und ein sanfter Basis-Verlauf ist konstruktionsbedingt gutmütig: 16→18 über 360→1280 legt bei mittleren Breiten etwa 90 % der Größe in den rem-Term. Das Drama auf System-Ebene — wie groß ein h1 wird — steckt im Verhältnis der Schriftgrößenskala, oben drauf multipliziert in zoom-sicherem rem, nicht in der Steigung des Verlaufs.

Rechne die Zahlen für einen steileren Verlauf durch

Der Zusammenhang zwischen Steigung und Barrierefreiheit lässt sich am leichtesten glauben, wenn du ihn selbst berechnest: öffne einen steileren Basis-Verlauf in Scale Composer — 16→24 über denselben Viewport-Bereich — und wiederhole die 800px-Arithmetik aus seinem Export. Der rem-Anteil sinkt auf ≈65 %, und 200 % Zoom ergibt jetzt ≈165 %. Irgendwo zwischen diesem Verlauf und dem sanften liegt die Antwort deines eigenen Systems — und die auskommentierten Bereiche des Exports geben dir jede Zahl, die du brauchst, um sie zu finden.