Warum 16px die Standard-Grundschriftgröße ist

16px ist in den großen Browsern die Standard-Schriftgröße, weil es Fließtext in einer angenehmen Größe für typische Betrachtungsabstände am Bildschirm darstellt – und diese Rolle hat es seit den frühen Tagen von CSS behalten. Der Standardwert ist mehr als nur Geschichte: Wer größeren Text braucht, ändert ihn in den Browser-Einstellungen, und eine rem-basierte Größenberechnung erbt diese Wahl – ein Schriftsystem, das am Standardwert verankert ist, bleibt also barrierefrei, während es skaliert.

Dieser Artikel zeigt, woher die Zahl kommt, was die Basisgröße tatsächlich steuert und wann eine andere Basisgröße die bessere Wahl ist. Er ist Teil unseres Leitfadens zur Schriftgrößenskala.

Woher stammt der 16px-Standard?

Frühe grafische Browser wurden mit einer Standard-Textgröße von „medium” ausgeliefert, die mit 16px dargestellt wurde, und CSS behielt diese Konvention bei. Die Zahl ist weniger willkürlich, als sie aussieht. CSS geht von nominal 96 Pixeln pro Zoll aus, wodurch 16px genau 12 Punkt entsprechen – eine Fließtext-Größe, auf die sich die Drucktypografie lange vor den Bildschirmen geeinigt hatte. Die Absicht wurde übernommen: Bei einem typischen Desktop-Betrachtungsabstand nimmt 16px-Text ungefähr denselben Sehwinkel ein wie gedruckter Fließtext im Leseabstand. Der Standard hält sich, weil er die Größe trifft, auf die lesende Augen bereits trainiert sind – nicht, weil die Zahl selbst besonders wäre.

Die MDN-Dokumentation zu font-size erklärt die Mechanik: Schlüsselwort-Größen wie medium, die relativen Einheiten em und rem und wie sie sich gegen vererbte und Wurzel-Größen auflösen.

Warum ist es für Barrierefreiheit wichtig, den Standardwert zu respektieren?

Weil der Standardwert eine Nutzereinstellung ist, keine Konstante. Menschen mit eingeschränktem Sehvermögen – oder einfach mit langen Tagen vor dem Bildschirm – erhöhen die Standard-Schriftgröße ihres Browsers, und jede in rem angegebene Größe skaliert mit dieser Wahl, denn rem löst sich gegen die Schriftgröße des Wurzelelements auf. Ein Stylesheet, das die Wurzel in festen Pixeln setzt, verwirft die Präferenz der Nutzerin stillschweigend; eines, das die Wurzel in Ruhe lässt und in rem dimensioniert, gibt sie durch die gesamte Hierarchie weiter.

Das ist das stärkste Argument dafür, 16px als Anker statt als Dekoration zu behandeln: Bau die Skala um den Standardwert herum, drück sie in relativen Einheiten aus, und die 20px-Präferenz einer Nutzerin reproduziert deine gesamte Hierarchie 25 % größer – die Proportionen bleiben erhalten.

Was steuert die Basisgröße in einer Schriftgrößenskala tatsächlich?

In einer modularen Skala ist die Basisgröße nicht eine Größe unter vielen – sie ist der Ursprung, aus dem jeder andere Wert berechnet wird. Scale Composer erzeugt Größen mit size = base × ratio^(i/notes), leitet Abstands-Stufen aus derselben Basis, Ratio und denselben Notes ab und setzt eine Grundlinien-Einheit von base/2. Ändere die Basisgröße, und das gesamte System verschiebt sich proportional:

(Werte vor dem Runden.) Jede Größe verschiebt sich um dieselben 12,5 %, und die Beziehungen zwischen den Ebenen bleiben unangetastet – genau das ist der Sinn davon, alles aus einem einzigen Anker abzuleiten.

Öffne die Anatomie einer 16px-Basis im Scale Composer – die Ansicht zentriert sich auf Stufe 0 und zeigt die Größen darüber und darunter, zusammen mit der 8px-Grundlinie, die die Basisgröße erzeugt.

Solltest du html auf 62,5 % setzen, um die rem-Rechnung zu vereinfachen?

Der Trick – html { font-size: 62.5% }, sodass 1rem gleich 10px ist – tauscht eine kleine Rechen-Bequemlichkeit gegen strukturelle Reibung ein, und viele Praktiker sind übereingekommen, ihn zu vermeiden. Drei Gründe tauchen immer wieder auf:

1. Media Queries folgen nicht. em und rem in Media Queries lösen sich gegen die anfängliche Schriftgröße des Browsers auf, nicht gegen deine Wurzel-Überschreibung – deine Breakpoints und deine Komponenten laufen also am Ende auf zwei verschiedenen rem-Werten.
2. Fremdcode geht von 16 aus. Komponenten-Bibliotheken und eingebettete Widgets dimensionieren sich häufig in rem, in der Annahme, dass 1rem ≈ 16px ist; unter 62,5 % werden sie alle kleiner dargestellt als vorgesehen.
3. Die Bequemlichkeit ist überholt. Wenn eine Skala die Werte erzeugt und sie als Tokens oder CSS exportiert, verschwindet die gedankliche rem-zu-px-Umrechnung, für die der Trick existierte, weitgehend aus dem Arbeitsablauf – das Problem, das er löste, liegt nicht mehr dort, wo die Arbeit passiert.

Wann ist 18px die bessere Basisgröße?

Wenn das Produkt hauptsächlich aus Fließtext besteht. Langes Lesen – Artikel, Dokumentation, alles, was jemand über Minuten liest statt in Sekunden überfliegt – profitiert von einer größeren Fließtext-Größe, und redaktionelle Websites setzen Fließtext üblicherweise zwischen 18px und 21px. Die Leserin lehnt sich zurück, die Zeilen laufen länger, und 16px beginnt sich für diesen Abstand klein anzufühlen.

Die Entscheidung bleibt einfach, weil die Basisgröße ein einzelner Eingabewert ist: Ein Lese-Produkt startet die Skala bei 18, ein gemischtes oder dichtes Produkt bleibt bei 16 und reserviert eine Stufe über der Basis für Vorspann-Absätze. So oder so folgt der Rest des Systems automatisch.

Verschiebe die Basisgröße und sieh dem System beim Folgen zu

Die Rolle des Ankers lässt sich leichter erfühlen als nachlesen: Verschiebe dieselbe Skala auf eine 18px-Basis – eine Einstellung, die auf langes Lesen abgestimmt ist – und sieh zu, wie jede Größe, jede Abstands-Stufe und die Grundlinie (jetzt 9px) sich gemeinsam bewegen, während die Proportionen erhalten bleiben. Setz sie dann zurück auf 16 und entscheide, aus welchem Abstand dein Produkt tatsächlich gelesen wird.