Diese Seite wurde mit AI-Unterstützung übersetzt. Das englische Original ist maßgeblich.
Die erste Auflage dieser Richtlinien setzte einen Bildschirm voraus: einen einzigen, an den Schreibtisch gebundenen, von vorhersehbarer Größe. Diese Annahme ist dahin. Derselbe Absatz muss heute auf einem Telefon in Armlänge, einem Tablet, einem Laptop und einem wandgroßen Display gut lesbar sein — und, wichtiger noch, er muss für eine Person gut lesbar sein, die ihre Systemschrift vergrößert, die Seite auf 400 Prozent gezoomt hat, oder beides. Fluide Typografie ist das Handwerk, Schrift über diese Spanne zu skalieren; barrierefreie fluide Typografie ist es, dies zu tun, ohne die Leserin stillschweigend zu übergehen.
Fluide Skalen und die clamp()-Funktion
Das moderne Idiom setzt die Schriftgröße mit der CSS-Funktion clamp(): ein Minimum, ein bevorzugter Wert, der mit dem Viewport wächst, und ein Maximum. Statt an Breakpoints zwischen festen Größen zu springen, gleitet die Schrift — Überschriften, die auf dem Desktop groß auftreten, werden auf dem Telefon anmutig kleiner, und die unbeholfenen Zwischenbreiten, die Breakpoints nie recht bedienten, werden automatisch abgedeckt.
Gut eingesetzt ist das ein echter Gewinn für die Lesbarkeit. Achtlos eingesetzt erzeugt es eine neue Klasse von Barrierefreiheitsfehlern — und der Fehler ist subtil genug, um beiläufiges Testen zu überstehen.
Der Barrierefreiheitsvorbehalt
Alles in dieser Publikation ruht auf einem Vertrag: Die Größeneinstellungen der Lesenden gewinnen. Browser lassen Nutzer eine Standardschriftgröße festlegen; Betriebssysteme bieten Textskalierung; WCAG 1.4.4 (Resize Text) verlangt, dass Text auf bis zu 200 Prozent vergrößert werden kann, ohne Inhalt oder Funktion zu verlieren. Fluide Formeln können diesen Vertrag auf zwei Arten stillschweigend brechen.
Erstens reagiert eine Formel, die rein auf Viewport-Einheiten aufbaut — etwa eine nur aus vw abgeleitete Größe —, überhaupt nicht auf die Schriftgrößenpräferenz der Nutzerin. Die Seite wirkt fluide und modern, und eine Leserin, die ihren Browser auf einen größeren Standard gestellt hat, sieht keinerlei Wirkung. Die Abhilfe ist, Formeln auf rem zu bauen: Halten Sie Minimum und Maximum in rem und geben Sie dem bevorzugten Wert neben seinem Viewport-Term eine rem-basierte Komponente. Dann reitet die gesamte Skala auf der Einstellung der Nutzerin, wie es sein soll.
Zweitens kann die Klammer selbst gegen den Zoom kämpfen. Wenn eine Leserin zoomt, schrumpfen Viewport-Einheiten in CSS-Begriffen, sodass eine vw-lastige Formel den Zoom teilweise aufhebt: Die Leserin vergrößert die Seite, und der Text wächst um weniger als den Zoomfaktor — und kann in Extremfällen die 200 Prozent nicht erreichen, die WCAG 1.4.4 verlangt. Jede fluide Skala muss bei hohem Zoom getestet werden — nicht angenommen.
Reflow und 400 Prozent Zoom
WCAG 1.4.10 (Reflow) verlangt, dass Inhalte bei einer Breite von 320 CSS-Pixeln funktionieren — was einem auf 400 Prozent gezoomten 1280-Pixel-Fenster entspricht — ohne horizontales Scrollen beim Lesen. Viele sehbehinderte Lesende leben in diesen Vergrößerungen. Fluide Schrift hilft hier, wenn sie ehrlich ist: Bei dieser effektiven Breite sollte die Skala auf ihrem Minimum sitzen, Zeilenlängen sollten sich verkürzen, und nichts sollte dem Viewport entkommen. Container mit fester Breite, absolut positionierter Text und mehrspaltige Layouts, die sich weigern zusammenzufallen, sind die üblichen Übeltäter. Testen Sie jede Leseseite bei 400 Prozent; es dauert eine Minute, und dort verstecken sich diese Fehler.
Container Queries
Media Queries fragen, wie groß das Fenster ist; Container Queries fragen, wie groß die eigene Box der Komponente ist — was gewöhnlich die Frage ist, deren Antwort die Typografie tatsächlich braucht. Eine Karte ist eine Karte, ob sie in einer Seitenleiste sitzt oder die Seite überspannt, und ihre Schrift kann jetzt auf ihre eigene Breite reagieren, mit Container-Query-Einheiten für fluide Größen innerhalb der Komponente. Derselbe Vorbehalt überträgt sich unverändert: Container-relative Einheiten wissen nichts von der Schriftgrößenpräferenz der Lesenden, also müssen auch sie mit rem-basierten Termen kombiniert und unter Zoom getestet werden.
Kleinere Werkzeuge, echte Gewinne
Mehrere neuere CSS-Eigenschaften packen alte typografische Probleme direkt an:
- text-wrap: balance gleicht die Zeilenlängen kurzer Blöcke aus — Überschriften vor allem — und beseitigt die Zwei-Wörter-Waise unter einer langen ersten Zeile. Es ist für wenige Zeilen gedacht, nicht für Fließtext.
- text-wrap: pretty lässt den Browser mehr Aufwand in den Zeilenumbruch von Absätzen stecken, vermeidet einsame letzte Wörter und verbessert den Flatterrand. Die Unterstützung ist über die Engines hinweg noch uneinheitlich; behandeln Sie es als Progressive Enhancement.
- font-size-adjust gleicht die x-Höhe einer Fallback-Schrift an den Webfont an, den sie vertritt. Während der Webfont lädt — oder falls er nie ankommt — rendert die Fallback-Schrift in einer äquivalenten scheinbaren Größe, was Layoutverschiebungen reduziert und den Fallback-Text so leserlich hält wie die vorgesehene Schrift. Angesichts dessen, wie viel Lesen in den Sekunden vor dem Laden der Fonts geschieht, verdient diese bescheidene Eigenschaft ihren Platz.
Warum dieses Kapitel neu ist
2005 gab es keine fluide Typografie, weil es nichts gab, worüber sie hätte fluide sein können: Das mobile Web existierte kaum, Responsive Design sollte erst 2010 formuliert werden, und clamp(), Container Queries, text-wrap-Steuerung und breit unterstütztes font-size-adjust sind allesamt Entwicklungen der letzten Jahre. Die Reflow-Anforderung selbst kam erst mit Version 2.1 im Jahr 2018 in die WCAG. Die Vielfalt der Bildschirme schuf das Problem; CSS hat erst kürzlich die Instrumente geliefert; und die Barrierefreiheitsdisziplin um diese Instrumente ist noch jünger.
In CSS
h1 {
/* fluid between bounds; the rem term preserves zoom and settings */
font-size: clamp(2.25rem, 1.4rem + 3.5vw, 4.5rem);
text-wrap: balance;
}
p { font-size: 1rem; text-wrap: pretty; }
/* Test at 200% and 400% zoom — WCAG 1.4.4 and 1.4.10 */Empfehlungen
- Bauen Sie fluide Skalen auf rem: Minima, Maxima und eine rem-Komponente im bevorzugten Wert, damit sich die Schriftgrößenpräferenzen der Nutzer fortpflanzen.
- Bemessen Sie Text nie allein in Viewport-Einheiten.
- Testen Sie jedes Template bei 200 Prozent Zoom, 400 Prozent Zoom und mit erhöhter Standardschriftgröße des Browsers — drei verschiedene Tests, alle erforderlich.
- Verifizieren Sie WCAG 1.4.10: Bei 320 CSS-Pixeln Breite erfordert das Lesen kein horizontales Scrollen.
- Nutzen Sie Container Queries für Schriftentscheidungen auf Komponentenebene, mit derselben rem-Disziplin.
- Wenden Sie text-wrap: balance auf Überschriften an; aktivieren Sie text-wrap: pretty für Fließtext als Progressive Enhancement.
- Definieren Sie font-size-adjust (und größenangepasste Fallbacks), damit Text vor und ohne den Webfont leserlich ist.