Readability & Legibility

The full lesson

Typography exists to be read, not admired. Yet two of the most foundational concepts — legibility and readability — are routinely mixed up or treated as afterthoughts. Getting them right is a craft decision, an engineering constraint, and a legal requirement all at once. This lesson draws a clear line between the two, examines every variable that affects them, and maps each to concrete, testable decisions you can make in code.

Legibility vs. Readability: the precise distinction

These terms overlap in everyday conversation, but design has specific meanings for each — and they are worth keeping separate.

Legibility is the ability to tell one character from another. It lives at the glyph level: can a reader distinguish a lowercase l from a capital I from the number 1? Legibility is mostly a property of the typeface itself — its letterforms, stroke contrast, x-height, and apertures.

Readability is the ability to absorb meaning from running text without extra effort. It operates at the word, sentence, and paragraph level: does the text invite sustained reading, or does it resist? Readability depends on a whole system of variables — line length, line height, spacing, contrast, and typographic hierarchy — most of which live outside the font file.

A typeface can be perfectly legible character-by-character and still produce terrible readability when set at 11 px, full black on white, with 1.0 line-height across a 1200 px-wide column. Conversely, a beautiful display face may be completely illegible at body sizes. Designers need to reason about both properties on their own terms.

Legibility: what makes individual characters distinguishable

Typeface anatomy choices

Certain decisions at the typeface design level make characters easier or harder to tell apart:

• x-height — A tall x-height (the ratio of lowercase letter height to capital height) improves legibility at small sizes because lowercase letters take up more of the visual field. Fonts like Inter, Source Sans, and Roboto were engineered with this in mind.
• Apertures — Apertures are the partially-enclosed white spaces inside letters like c, e, a, and s. Open apertures make characters less likely to be misread, especially in peripheral vision or at awkward viewing distances. Tight apertures are a common legibility trap in fonts designed for large print display.
• Stroke contrast — High-contrast serifs like Didot and Bodoni have dramatic thick-thin transitions that look striking at display sizes but collapse at small sizes, especially on low-DPI screens. Low-contrast humanist or geometric sans-serifs hold up much better in UI contexts.
• Disambiguation — Some fonts tackle the classic 1Il confusion head-on. Many grotesque sans-serifs make these characters look nearly identical. Fonts designed for code (JetBrains Mono, Fira Code) and UI (iA Writer Quattro, Atkinson Hyperlegible) explicitly add visual distinctions between confusable characters.

Serif vs. sans-serif: the evidence

The claim that serifs aid readability is a persistent myth. Decades of controlled studies show no consistent advantage for either style on screen. Historically, monitors lacked the resolution to render fine serif details clearly. On modern high-DPI screens the gap closes even further. Choose your typeface style based on brand voice, tone, and how well it pairs with your type scale — not on a blanket legibility rule.

Readability: the variables you control

Contrast

Contrast is the ratio between the luminance of text and its background. WCAG 2.2 AA requires:

• 4.5:1 for normal text (under 18 pt, or 14 pt bold)
• 3:1 for large text (18 pt and above, or 14 pt bold and above)
• 3:1 for UI components and graphical elements (criterion 1.4.11)

These thresholds are legal baselines in most jurisdictions that have adopted WCAG, including the EU, UK, and US federal government. Failing them is not a stylistic opinion — it is a compliance failure.

APCA (Advanced Perceptual Contrast Algorithm) is a more nuanced contrast model under development for WCAG 3. It accounts for light-on-dark vs. dark-on-light polarity, font weight, and spatial frequency. It is a useful lens for perceptual quality review, but as of 2026 it is not a published WCAG requirement. Do not replace WCAG 2.2 AA measurements with APCA scores — use both.

Common contrast failures to audit:

Line length (measure)

Optimal line length for body copy is widely cited as 45–75 characters per line (the classic Bringhurst range). The ch CSS unit approximates the width of the “0” glyph, making it a practical way to enforce this:

.prose {
  max-width: 70ch;
}

Lines shorter than 45 characters fragment sentences and force constant line-switching. Lines longer than 85 characters make it hard for the eye to find the start of the next line — a strong predictor of re-reading errors and increased fatigue.

On wide viewports without a max-width constraint, long-form body text stretches across the full column and silently degrades comprehension. Container queries now let you scope this constraint to the component itself, regardless of the parent layout.

Line height (leading)

Line height controls the vertical breathing room between lines. For body text, a unitless value of 1.4–1.6 is the established sweet spot for most Latin-script fonts. WCAG 2.2 Success Criterion 1.4.12 (Text Spacing) requires that text remains usable when line height is set to at least 1.5 times the font size.

Always set line height with a unitless multiplier — not a fixed pixel value. A fixed line-height: 24px on 16 px body text looks fine until the user increases their browser font size. Then the lines collapse on each other. A unitless value scales proportionally and prevents this.

body {
  font-size: 1rem;       /* respects browser/user zoom */
  line-height: 1.6;      /* scales proportionally */
}

Headings need tighter leading — around 1.1–1.3. The white space above and below the heading element already provides visual separation. Loose leading on short multi-word headings makes them feel disconnected.

Letter spacing (tracking)

Tracking is rarely the primary readability lever, but two evidence-backed patterns are worth knowing:

• All-caps labels and UI elements — tracking of 0.05–0.12 em prevents characters from colliding and improves scannability. All-caps text at normal tracking is measurably harder to read.
• Small text at caption or label sizes — a slight positive tracking (0.01–0.03 em) helps separate characters when they are visually compressed.

Do not open up tracking on body text. Increased letter spacing in running paragraphs disrupts the visual word shapes that readers recognize holistically, which slows reading.

Font size and scale

The minimum body text size for digital interfaces is 16 px (1 rem at default browser settings). Many style guides cite 14 px as acceptable for secondary copy, but 16 px is the threshold below which reading effort measurably increases for average users — and substantially increases for users over 40.

Use relative units (rem or em) rather than px for all text. This ensures a user’s browser-level font size preference is respected. Pure viewport-unit font sizes using vw alone are an anti-pattern because they break at 200% browser zoom.

The modern approach is fluid type via clamp():

:root {
  --font-size-body: clamp(1rem, 0.875rem + 0.5vw, 1.25rem);
}

This keeps body text in a comfortable range across all viewport widths without abrupt jumps at breakpoints, while preserving the rem floor so zoom still works.

Text spacing and WCAG 1.4.12

WCAG 2.2 Success Criterion 1.4.12 (Text Spacing, AA) states that no content or functionality can be lost when the following overrides are applied all at once:

• Line height set to 1.5 times the font size
• Letter spacing set to 0.12 times the font size
• Word spacing set to 0.16 times the font size
• Paragraph spacing set to 2 times the font size

Testing this is straightforward with a bookmarklet or browser extension that injects these overrides. Content that breaks under these conditions has hard-coded, fragile spacing assumptions. Design tokens and fluid spacing systems absorb these overrides gracefully. Component heights locked to fixed pixel values do not.

Rendering environments and font rendering

Text legibility also depends on how the browser renders it. A few things to keep in mind:

• Subpixel antialiasing vs. grayscale — macOS Safari uses subpixel antialiasing by default on non-Retina screens. Most browsers on high-DPI screens use grayscale. Light text on dark backgrounds with -webkit-font-smoothing: antialiased can look lighter than designed. Test on both dark and light themes, and don’t use font-smoothing overrides to compensate for a typeface that is simply too light for its context.
• Variable fonts and optical sizing — Variable fonts with an opsz (optical size) axis adjust letterform details based on font size. At small sizes, strokes thicken and spacing opens up. This is the digital equivalent of optical size fonts in traditional typesetting. It is a meaningful legibility improvement — for free — when you choose a font that supports it.
• Dark mode contrast — Dark themes are not simply inverted light themes. Pure black (#000000) backgrounds create extreme contrast with white text, which can cause halation — where text appears to bleed into the background — for some users. Use near-black values in the #0A0A0A–#1A1A1A range. Define separate contrast-compliant token values for dark mode rather than inverting light-mode hex values programmatically.

Readability in context: density, hierarchy, and white space

Readability is not only about individual typographic settings. It is also about the overall density and hierarchy of a page. Several patterns erode readability at the composition level:

• Insufficient breathing room — Padding around text blocks that is too tight compresses the visual field and raises the perceived density. Use generous padding. The white space is not wasted — it is a readability investment.
• Competing type styles — Using five or more distinct weights, sizes, and colors in close proximity without a clear hierarchy makes it hard for readers to know where to start. Two or three levels of hierarchy (body, label, heading) cover most UI contexts.
• Justified alignment in narrow columns — Fully justified text creates uneven word spacing, producing “rivers” of white space, especially in narrow containers. Left-aligned (ragged right) body text is consistently more readable in web contexts.
• Centered long-form text — Centering works for headlines, labels, and captions. Centering paragraph-length copy forces the reader to find a new line-start position on every line, which is measurably slower.

Practical audit checklist

Use this list as a quick pre-ship review for any text-heavy component:

• Contrast passes WCAG 2.2 AA (4.5:1 body, 3:1 large text) — measured, not estimated
• Body font size is 16 px / 1 rem or larger
• Line height is unitless and 1.4 or greater for body copy
• Reading column is capped at 75ch or narrower
• Font sizes use rem or clamp(), not px alone
• No placeholder text is used as a permanent label (and placeholder contrast passes 4.5:1)
• Text spacing overrides (WCAG 1.4.12) do not break layout or clip content
• Dark mode tokens are defined independently — not derived by inversion
• All-caps labels have positive tracking (0.05 em minimum)
• Heading line-height is tighter than body (1.1–1.3)