Die Web Content Accessibility Guidelines (WCAG), eine Organisation, die Standards für die Barrierefreiheit von Webinhalten definiert, legt keine Mindestschriftgröße für das Web fest.
Wir wissen jedoch, dass es Text gibt, der zu klein ist, um lesbar zu sein, genauso wie Text, der zu groß zum Konsumieren sein kann. Wie können wir also sicherstellen, dass unsere Schriftgrößen barrierefrei sind? Welche bewährten Praktiken können wir für ein barrierefreies Leseerlebnis heranziehen?
Die Antwort: Das liegt nicht an uns. Es kommt darauf an™. Wir werden später auf einige spezifische Punkte eingehen, aber lassen Sie uns zunächst die WCAG-Anforderungen für Schriftarten untersuchen.
Größe, Kontrast und 300 Alphabete
Erstens, Textgröße ändern. Wir möchten Benutzern mit eingeschränktem Sehvermögen die Möglichkeit geben, die Darstellung von Schriftarten zu wählen. Nicht auf verrückte Weise. Eher wie die Möglichkeit, die Größe um 200% zu erhöhen, während die Lesbarkeit erhalten bleibt und Kollisionen und Überlappungen von Inhalten vermieden werden.
Zweitens gibt es den Kontrast. Deshalb sagte ich "es kommt darauf an", was eine zugängliche Schriftgröße ausmacht. Text muss ein Kontrastverhältnis von mindestens 4,5:1 aufweisen, mit Ausnahme von Texten in großer Schrift, die ein Kontrastverhältnis von mindestens 3:1 haben sollten. Sie können Tools wie WebAIM's Contrast Checker verwenden, um sicherzustellen, dass Ihr Text den Richtlinien entspricht. Stacy Arrelanos ausführliche Abhandlung über Farbkontrast bietet eine ausgezeichnete Erklärung, wie Kontrastverhältnisse berechnet werden.
Es gibt etwa 300 Alphabete auf der Welt. Einige Zeichen sind einfach und in kleineren Größen lesbar, andere sind unglaublich komplex und würden bei gleicher Größe wichtige Details verlieren. Deshalb können Spezifikationen keine Schriftgröße definieren, die die Spezifikationen für Kontrastverhältnisse erfüllt.
Und wenn wir von "Text" und "großen Text"-Größen sprechen, beziehen wir uns auf das, was die Spezifikation als "die minimale Größe für Großdrucke, die für diese Sprachen verwendet wird, und die nächstgrößere Standardgröße für Großdrucke" bezeichnet. Um AAA-Kriterien mit römischem Text zu erfüllen, ist "groß" zum Beispiel 18 Punkte. Da wir in einer Welt mit unterschiedlichen Bildschirmdichten leben, messen Spezifikationen Größen in Punkten, nicht in Pixeln, und auf einigen Displays entspricht 18pt 24px. Bei anderen Schriftarten, wie CJK (Chinesisch, Japanisch, Koreanisch) oder arabischen Sprachen, wäre die tatsächliche Größe in Pixeln unterschiedlich. Hier ist das Wort "Hallo" im Vergleich zu drei anderen Sprachen
Hallo สวัสดี مرحبا 你好
Kurz gesagt, WCAG spezifiziert Kontrast anstelle von Größe.

Hier sind die guten Nachrichten: Standardstile eines Browsers sind barrierefrei und wir können sie nutzen, um eine Strategie für barrierefreie Schriftgrößen zu entwickeln. Sehen wir, wie.
Denken Sie an Proportionen, nicht an Größe
Der Browser lädt zuerst seine Standardstile (auch bekannt als "User Agent Stylesheet"), dann werden diese auf die Stile des Autors (die wir definieren) übertragen, und beide werden durch die Stile des Benutzers überschrieben.
Wie Adrian Sandu in seinem Artikel über rem CSS-Einheiten erwähnt
[...] gibt es eine empirische Studie, die von den Machern des Internet Archive durchgeführt wurde, die zeigt, dass ein erheblicher Teil der Benutzer die Standard-Schriftgröße in den Browsereinstellungen ändert.
Auch die Eigenschaft font-family kontrollieren wir nicht vollständig. Der Inhalt kann übersetzt werden, die benutzerdefinierte Schriftart kann fehlschlagen zu laden oder sie kann sogar geändert werden. Zum Beispiel OpenDyslexic ist eine Schriftart, die entwickelt wurde, um die Lesbarkeit für Leser mit Legasthenie zu verbessern. In manchen Situationen können wir sogar explizit das Umschalten zwischen einer begrenzten Auswahl an Schriftarten ermöglichen.
Daher müssen wir bei der Definition von Schriftarten vermeiden, die Fähigkeit eines Benutzers oder Geräts zu beeinträchtigen, unsere Stile zu ändern, und Annahmen loslassen: wir wissen einfach nicht, wo unsere Inhalte landen werden und wir können uns nicht über die genaue Größe, Sprache oder Schriftart sicher sein, die zur Anzeige der Inhalte verwendet wird.
Aber es gibt eine Sache, die wir kontrollieren können: Proportionen.
Durch die Verwendung von relativen CSS-Einheiten können wir unsere Inhalte so einstellen, dass sie proportional zu dem sind, was die Umgebung vorgibt. WCAG empfiehlt die Verwendung von em-Einheiten zur Definition der Schriftgröße. Es gibt mehrere Veröffentlichungen, die die Vorteile der Verwendung von em und rem diskutieren, und das sprengt den Rahmen dieses Artikels. Ich würde sagen, verwenden Sie rem und em für alles, auch für andere Eigenschaften als font-size (mit Ausnahme von Rändern, bei denen ich Pixel verwende).
Vermeiden Sie die Festlegung einer Basisschriftgröße
Meine Empfehlung ist, font-size auf den Elementen :root, <html> oder <body> zu vermeiden und stattdessen die Standardgröße des Browsers als Basis zu verwenden, von der aus wir unsere eigenen Stile kaskadieren können. Da dieser Standard barrierefrei ist, sind auch die Inhalte barrierefrei. Der WACAG 2.2 Arbeitsentwurf besagt, dass
Wenn Text ohne Angabe der Schriftgröße verwendet wird, ist die kleinste Schriftgröße, die in gängigen Browsern für nicht spezifizierten Text verwendet wird, eine angemessene Größe für die Schrift.
Natürlich gibt es eine Ausnahme von der Regel. Bei Verwendung einer komplexen, dünnen oder sehr kurzen x-Höhe-Schriftart sollten Sie erwägen, die Basisschriftgröße zu erhöhen, um den richtigen Kontrast zu erzielen. Denken Sie daran, dass die Spezifikation Kontrast, nicht Größe definiert.
Schriftarten mit außergewöhnlich dünnen Strichen oder ungewöhnlichen Merkmalen und Eigenschaften, die die Vertrautheit ihrer Buchstabenformen verringern, sind schwerer zu lesen, insbesondere bei geringeren Kontraststufen.
Ebenso kann ein Benutzer die Basisschriftgröße an seine Bedürfnisse anpassen. Eine Person mit eingeschränktem Sehvermögen möchte eine größere Größe wählen, während jemand mit ausgezeichnetem Sehvermögen eine kleinere wählen kann, um mehr Platz auf seinem Bildschirm zu gewinnen.
Es geht um Proportionen: Wir definieren, wie viel größer oder kleiner Teile des Inhalts sein sollen, indem wir die Standardbasis nutzen, um die Haupttextgröße festzulegen.
:root {
/* Do not set a font-size on a :root, body nor html level */
/* Let your main text size be decided by the browser or the user settings */
}
.small {
font-size: .8rem;
}
.large {
font-size: 2rem;
}
Was ist mit Überschriften?
Da Überschriften eine Dokumentengliederung erstellen, die Screenreadern hilft, ein Dokument zu navigieren, definieren wir keine Typselektoren für Überschriften. Die Reihenfolge der Überschriften ist ein WCAG-Kriterium: Die Überschriftenelemente sollten in absteigender Reihenfolge organisiert sein, ohne eine Ebene zu überspringen, was bedeutet, dass ein h4 direkt nach einem h3 kommen sollte.
Manchmal ist es eine gute Strategie, die Schriftgröße aller Überschriften auf 1rem zurückzusetzen, um die Trennung der visuellen Behandlung von der Bedeutung zu erzwingen.
Wie können wir mit Pixeln arbeiten?
Sowohl rem- als auch em-Größen sind relativ zu etwas anderem. Zum Beispiel berechnet rem die Größe relativ zum <html>-Element, während em durch die Größe seines eigenen Elements berechnet wird. Das kann verwirrend sein, besonders da viele von uns ausschließlich mit Pixeln gearbeitet haben.
Wie können wir also immer noch in Pixeln denken, aber relative Einheiten implementieren?
Meistens wird eine typografische Hierarchie in Pixeln entworfen. Da wir die User-Agent-Stylesheets kennen und alle gängigen Browser eine Standard-Schriftgröße von 16px haben, können wir diese Größe für den Haupttext festlegen und den Rest proportional mit rem-Einheiten berechnen.
| Browsername | Basisschriftgröße |
|---|---|
| Chrome v80.0 | 16px |
| FireFox v74.0 | 16px |
| Safari v13.0.4 | 16px |
| Edge v80.0 (Chromium basiert) | 16px |
| Android (Samsung, Chrome, Firefox) | 16px |
| Safari iOS | 16px |
| Kindle Touch | 26px (wird als 16px gerendert, da es ein hochauflösender Bildschirm ist) |
Lassen Sie uns nun drei Methoden zur Verwendung relativer Größen in CSS untersuchen, indem wir diese Pixel in rem-Einheiten umwandeln.
Methode 1: Die 62,5%-Regel
Um Pixel nahtlos in rem umzuwandeln, können wir die Root-Größe auf 62,5% einstellen. Das bedeutet, 1rem entspricht 10px
:root {
font-size: 62.5%; /* (62.5/100) * 16px = 10px */
--font-size--small: 1.4rem; /* 14px */
--font-size--default: 1.6rem; /* 16px */
--font-size--large: 2.4rem; /* 24px */
}
.font-size--small {
font-size: var(--font-size--small);
}
.font-size--default {
font-size: var(--font-size--default);
}
.font-size--large {
font-size: var(--font-size--large);
}
Methode 2: Verwendung der calc()-Funktion
Wir können Größen auch mit CSS calc() berechnen, indem wir den Pixelwert durch die Basisschriftgröße teilen, die wir bei den meisten Browsern annehmen.
:root {
--font-size--small: calc((14/16) * 1rem); /* 14px */
--font-size--default: calc((16/16) * 1rem); /* 16px */
--font-size--large: calc((24/16) * 1rem); /* 24px */
}
.font-size--small {
font-size: var(--font-size--small);
}
.font-size--default {
font-size: var(--font-size--default);
}
.font-size--large {
font-size: var(--font-size--large);
}
Methode 3: Verwendung einer "Pixel-zu-rem"-Funktion
Ähnlich wie bei calc() können wir einen Präprozessor nutzen, um eine "Pixel-zu-rem"-Funktion zu erstellen. Es gibt Implementierungen davon in vielen Varianten, einschließlich dieses Sass-Mixins und Styled-Components Polish.
:root {
--font-size--small: prem(14); /* 14px */
--font-size--default: prem(16); /* 16px */
--font-size--large: prem(24); /* 24px */
}
.font-size--small {
font-size: var(--font-size--small);
}
.font-size--default {
font-size: var(--font-size--default);
}
.font-size--large {
font-size: var(--font-size--large);
}
Es ist sogar möglich, eine "Pixel-zu-rem"-Funktion mit Vanilla CSS zu erstellen.
Umarme ein vielfältiges Web!
Die Quintessenz ist folgende: Wir haben keine Kontrolle darüber, wie Inhalte konsumiert werden. Benutzer haben persönliche Browsereinstellungen, die Möglichkeit zum Zoomen und verschiedene andere Möglichkeiten, ihr Leseerlebnis anzupassen. Aber wir haben bewährte CSS-Praktiken, mit denen wir eine gute Benutzererfahrung neben diesen Präferenzen aufrechterhalten können.
- Arbeiten Sie mit Proportionen statt mit expliziten Größen.
- Verlassen Sie sich auf Standard-Browser-Schriftgrößen, anstatt sie auf
:root,<html>oder<body>festzulegen. - Verwenden Sie
rem-Einheiten, um Inhalte mit den persönlichen Präferenzen eines Benutzers zu skalieren. - Vermeiden Sie Annahmen und lassen Sie die Umgebung entscheiden, wie Ihre Inhalte konsumiert werden.
Besonderer Dank geht an Franco Correa für all die Hilfe beim Schreiben dieses Beitrags.
Die Mischung von rem-Schriftformatierung mit px-basierten Layouts und Media Queries ist schwierig, sie skalieren nicht zusammen. Der Text, der bei 1rem-Größe in einer 500px breiten Box gut aussah, wird viel zu groß aussehen, der Container hat sich überhaupt nicht geändert.
Nach unserer Erfahrung neigen Benutzer eher dazu, eine Standard-Zoomstufe für ihre Browser festzulegen (oder einfach auf der Seite zu zoomen), anstatt eine Standard-Schriftgröße festzulegen (was bei etwa 2% der Benutzer der Fall war).
Rems waren eine großartige Lösung, als das Verhalten des Browser-Zooms nicht einheitlich war. Sie lohnen sich nicht mehr.
Die größten visuellen Zugewinne bei der Textzugänglichkeit finden sich in den Leitfäden von WCAG.
Bedeutungsvoller Text mit ARIA-Labels und -Zuständen sollte in dieser Diskussion ebenfalls nicht ignoriert werden, es sei denn, wir sprechen nur über visuelle Barrierefreiheit.
Würden Sie dann ein rem-basiertes Layout empfehlen?
Ich würde Alles-oder-Nichts empfehlen, keine Mischung aus absoluten und relativen Werten.
Vielen Dank für das Sammeln dieser Informationen. Ich bin auch ein Verfechter dafür, niemals eine Basisschriftgröße festzulegen, sondern die Benutzereinstellungen zu berücksichtigen.
Um einige der hier gegebenen Ratschläge zu erweitern, seien Sie bei der Festlegung von Schriftgrößen vorsichtig
Seien Sie vorsichtig bei jeder Größenbestimmung basierend auf Viewport-Einheiten (
vwodervh);Vermeiden Sie die Änderung der Schriftgröße über Viewport-Größen-Media-Queries;
Zeilenlänge ist wichtig, seien Sie also vorsichtig, wenn Zeilen zu lang werden;
Bis Sie einen guten Testprozess haben, vermeiden Sie
min(),max()undclamp();Seien Sie sich bewusst, dass Text in
pxunbeeinflusst bleibt, wenn Benutzer die Schriftgröße in den Browsereinstellungen ändern, also vermeiden Sie vielleichtpxkomplett.Ich habe Beispiele dafür, wie dies problematisch sein kann, in meinem Beitrag Responsive Type and Zoom.
Ein kurzer Hinweis zu OpenDyslexic aus einer Studie von 2013 mit 48 Teilnehmern (es gibt andere Studien, die dies unterstützen)
Das heißt, variable Schriftarten könnten für Menschen mit Legasthenie hilfreich sein (also experimentieren Sie bitte!).
Können Sie "Vermeiden Sie die Änderung der Schriftgröße über Viewport-Größen-Media-Queries" näher erläutern?
D, wenn sich Ihr Text mit der Viewport-Größe ändert, skaliert der Text nicht konsistent, wenn dieser Zoom eine Media Query auslöst. Siehe den ersten Link in meinem Kommentar für Beispiele.
Ich erhöhe die Root-Schriftgröße auf dem Desktop über eine Media Query.
Ist das ein Problem?
Ich habe gerade das Gleiche geschrieben und Ihren Kommentar übersehen. Es funktioniert für mich und wird auch hier empfohlen: https://betterwebtype.com/articles/2019/06/16/5-keys-to-accessible-web-typography/
Ich habe das gerade geschrieben und Ihren Kommentar übersehen. Es funktioniert für mich und wird auch hier empfohlen: https://betterwebtype.com/articles/2019/06/16/5-keys-to-accessible-web-typography/
Ich habe vergessen zu erwähnen, dass Sie em für Media Query Breakpoints verwenden sollten. Dort beziehen sie sich immer auf die Basisschriftgröße des Browsers, nicht auf die Schriftgröße, die Sie möglicherweise auf das Root-Element setzen, sonst könnten Sie Endlosschleifen bekommen.
Was ich in letzter Zeit mache, ist, Schriftgrößen sowohl in
pxals auch inremanzugeben (bei einer Basisschriftgröße von16px).Diese Duplizierung erhöht zwar die CSS-Dateigröße ein wenig, ermöglicht Ihnen aber das Designen/Codieren in Pixeln (einschließlich einer einfachen Referenz darauf, wie groß diese px-Größe war), die schnelle Konvertierung in
rem(vielleicht mit einem Präprozessor, wenn Sie möchten) und bietet einen Fallback, falls ein Browserremnicht unterstützt (zugegebenermaßen unterstützen dies alle gängigen Browser, aber ich mache mir immer Sorgen, dass ein weniger verbreitetes Gerät - insbesondere ein AT-Gerät - dies möglicherweise nicht tut).Ich skaliere gerne die gesamte Website auf großen Bildschirmen hoch, indem ich die Root-Schriftgröße ändere, was gut funktioniert, wenn Sie überall rems und ems verwenden, einschließlich Ihrer Media Queries. Stellen Sie nur sicher, dass Sie keine Pixel, sondern Prozente verwenden.
html {
font-size: 110%;
}
Dies berücksichtigt die Schriftgröße des Benutzers, sodass es sich um 110 % von 16px oder von dem handeln kann, was der Benutzer gewählt hat.
Hallo Andrés, danke fürs Teilen :)
Eine kleine Anmerkung
Standardmäßig passt iOS relative Längen nicht an Benutzereinstellungen an, es sei denn, Sie verwenden Systemschriftarten, die das dynamische Schriftverhalten unterstützen.
Um dies zu aktivieren, können Sie -apple-system-body als Root-Schriftart definieren (ich verwende HTML, da es eine geringere Spezifität als :root hat).