Diese Seite wurde mit AI-Unterstützung übersetzt. Das englische Original ist maßgeblich.
Die Ausgabe von 2005 beantwortete die Größenfrage mit einer Zahl: mindestens 14 Punkt, ungefähr 19 Pixel in Verdana, für barrierefreien Fließtext. Für ihren Moment war das eine vertretbare Zahl — traditionelle 9- und 10-Punkt-Druckgrößen waren für grobe Bildschirme offenkundig ungeeignet, und Verdanas enorme x-Höhe machte 19 Pixel zu einer bequemen Lektüre. Doch die tiefere Lehre der vergangenen zwei Jahrzehnte lautet, dass keine einzelne Zahl die Antwort sein kann, weil heute die Lesenden, nicht die Gestaltenden, die letzte Instanz für die Größe sind. Die Aufgabe der Gestaltung hat sich verschoben: nicht mehr die richtige Größe wählen, sondern ein System bauen, das die Entscheidungen der Lesenden übersteht.
Was sich seit 2005 geändert hat
Drei Entwicklungen haben die Frage neu strukturiert.
Erstens hat der Browser-Standard die Untergrenze festgelegt. Jeder große Browser liefert eine Standard-Textgröße von 16 CSS-Pixeln aus, und Nutzende können sie in den Einstellungen anheben. Sechzehn Pixel wurden zum faktischen Vertrag zwischen Plattform und Lesenden: Fließtext in der Standardgröße oder größer respektiert diesen Vertrag; Fließtext darunter setzt sich über eine Präferenz hinweg, die die Nutzenden womöglich bewusst gesetzt haben. Die alte 19-Pixel-Verdana-Zahl kompensierte Verdanas Ausreißer-x-Höhe und das Rendering ihrer Ära; in einer typischen modernen Textschrift liest sich 16px vergleichbar. Für Schriften mit kleiner x-Höhe sind 17 oder 18px das ehrliche Äquivalent — die Einsicht von 2005, dass die x-Höhe mehr zählt als die nominelle Größe, überlebt vollständig, und CSS kodiert sie inzwischen sogar in der Eigenschaft font-size-adjust, die Fallback-Fonts auf ein konsistentes x-Höhen-Verhältnis skaliert, sodass ein Fontwechsel den Text nicht stillschweigend schrumpfen lassen kann.
Zweitens haben Barrierefreiheits-Standards die Skalierbarkeit, nicht die Größe, zur prüfbaren Anforderung gemacht. Das WCAG-Erfolgskriterium 1.4.4 (Resize Text) verlangt, dass Text auf 200 Prozent skaliert werden kann, ohne dass Inhalt oder Funktion verloren gehen; 1.4.10 (Reflow) verlangt, dass Inhalte bei starkem Zoom ohne zweidimensionales Scrollen umbrechen. Eine Seite mit großzügiger fester Größe kann trotzdem an beidem scheitern; eine Seite mit 16px und widerstandsfähigem Layout besteht. Der Schwerpunkt des Standards liegt auf dem Zoompfad, nicht auf dem Ausgangspunkt.
Drittens haben hochauflösende Displays den alten Druck von oben beseitigt. Text verschlechtert sich beim Skalieren nicht mehr, sodass die Sorgen von 2005 um Layoutstabilität unter Skalierung heute ingenieurtechnische statt typografische Antworten haben.
Die Nutzenden respektieren: rem statt px
Die folgenreichste einzelne Praxis ist, Schriftgrößen in rem-Einheiten anzugeben. Ein rem ist relativ zur Wurzel-Schriftgröße, die vom Browser-Standard erbt — eine Person, die ihren Standard von 16 auf 20px anhebt, sieht also jedes rem-dimensionierte Element proportional skalieren. In px fixierte Schrift ignoriert diese Präferenz vollständig.
Die übliche Verteidigung — „px-Nutzende können ja zoomen“ — ist nur teilweise wahr, und der Unterschied zählt. Der Seitenzoom skaliert px-Text, ja. Aber die Textgrößen-Einstellungen des Browsers, auf die sich viele sehbehinderte Nutzende gerade deshalb verlassen, weil sie über jede Website hinweg ohne seitenweises Nachjustieren bestehen bleiben, wirken auf px-dimensionierten Text überhaupt nicht. Schrift in Pixeln zu fixieren schaltet still den beständigsten Barrierefreiheits-Mechanismus der Plattform ab. Dieselbe Logik spricht dagegen, die Schriftgröße des Wurzelelements auf einen px-Wert zu setzen (der alte Trick "html { font-size: 62.5% }" ist akzeptabel, weil er proportional ist; "html { font-size: 10px }" ist es nicht).
Der Zeilenabstand gehört in dieselbe Disziplin: Geben Sie ihn einheitenlos an (1,5 für Fließtext ist ein solider Standard), damit er mit der Größe skaliert, bei der der Text am Ende landet, statt bei einem px-Wert einzufrieren, der für den Viewport der Gestaltung berechnet wurde.
Fluide Größen, ohne die Untergrenze zu verlieren
Responsives Design brachte ein neues Werkzeug und einen neuen Fehlermodus. Die Funktion clamp() lässt eine Größe mit dem Viewport atmen — clamp(1rem, 0.9rem + 0.5vw, 1.25rem) setzt eine Untergrenze, eine fluide Mitte und eine Obergrenze —, was für Überschriften und für Fließtext, der auf großen Bildschirmen wachsen soll, wirklich nützlich ist.
Der Fehlermodus ist reine Viewport-Dimensionierung. Text, der nur in vw-Einheiten dimensioniert ist, reagiert nicht auf Zoom: Beim Zoomen schrumpft die CSS-Breite des Viewports proportional, und der Text berechnet sich auf ungefähr dieselbe wahrgenommene Größe zurück — WCAG 1.4.4 ist ausgehebelt. Die Abwehr steckt im empfohlenen Muster: Nehmen Sie immer einen rem-Term in den fluiden Ausdruck und ein rem-basiertes Minimum in clamp() auf, damit sowohl Nutzerpräferenz als auch Zoom ihren Griff behalten. Verifizieren Sie dann, indem Sie tatsächlich auf 200 Prozent zoomen und bestätigen, dass der Text doppelt so groß geworden ist.
Eine moderne Größenarchitektur
Setzt man die Teile zusammen, sieht eine vertretbare Schriftgrößenskala für barrierefreies Lesen so aus: Fließtext bei mindestens 1rem (16px bei Standardeinstellungen, mehr für Schriften mit kleiner x-Höhe), Sekundärtext nicht unter etwa 0.875rem und niemals für längeres Lesen, Überschriften auf einer moderaten Verhältnisskala in rem mit optionaler clamp()-Fluidität — und jede feste px-Schriftgröße gilt als Defekt. Die Empfehlung von 2005 zu kleinem Text gilt in aktualisierter Form: Wirklich kleine Schrift ist nur für kurze Nebentexte tolerierbar, nie für fortlaufende Passagen, und die Kontrastregeln der WCAG verschärfen sich für sie — Text unter 18pt regular (oder 14pt bold) erfordert ein Kontrastverhältnis von 4,5:1 statt der 3:1, die für großen Text erlaubt sind: ein ausdrückliches Eingeständnis, dass Größe und Kontrast gegeneinander abgewogen werden.
Für Lesende mit Sehbehinderung ersetzt all dies keine Vergrößerung; es sorgt dafür, dass Vergrößerung funktioniert. Der Maßstab des Erfolgs ist nicht, wie die Seite bei 100 Prozent aussieht, sondern ob sie bei 200 und 400 Prozent Zoom eine einzelne lesbare Spalte bleibt.
In CSS
html { font-size: 100%; } /* the reader's choice is the unit */
body { font-size: 1rem; } /* 16px floor for continuous text */
h1 {
/* the rem term keeps user settings and zoom in charge */
font-size: clamp(2rem, 1.2rem + 3vw, 4rem);
}
small { font-size: 0.875rem; } /* captions only, never body text */Empfehlungen
- Behandeln Sie 16px (1rem) als Untergrenze für Fließtext; heben Sie sie für Schriften mit kleiner x-Höhe an.
- Dimensionieren Sie alle Schrift in rem; geben Sie den Zeilenabstand einheitenlos an (etwa 1,5 für Fließtext).
- Fixieren Sie Fließtext niemals in px und setzen Sie die Wurzel-Schriftgröße niemals auf einen px-Wert.
- Verwenden Sie clamp() für fluide Schriftgrößen, immer mit einer rem-Komponente, damit Zoom und Nutzerpräferenzen weiterhin greifen.
- Verwenden Sie font-size-adjust, damit Fallback-Fonts die beabsichtigte x-Höhe halten.
- Testen Sie bei 200 Prozent Zoom (WCAG 1.4.4) und 400 Prozent Reflow (WCAG 1.4.10) als routinemäßige Qualitätssicherung.
- Reservieren Sie Größen unterhalb des Fließtexts für kurze Nebentexte und geben Sie kleinem Text den strengeren Kontrast von 4,5:1, den er erfordert.