Accessible Typography: The Complete Guide

Typography is one of the most powerful tools in a designer's toolkit — and one of the most overlooked areas when it comes to accessibility. A site that looks stunning on a calibrated monitor viewed by a sighted user in a well-lit room may be completely unusable to someone with low vision, dyslexia, a cognitive disability, or even someone reading on their phone in bright sunlight. Accessible typography is not a checklist item or an afterthought. It is the foundation of inclusive communication.

This guide covers everything web developers and designers need to know to make typography work for everyone: the standards you need to meet, the design decisions that matter most, and the CSS techniques that put it all together.

Why Typography Accessibility Matters

More people are affected by typographic inaccessibility than most designers assume. Approximately 8% of men and 0.5% of women have some form of color vision deficiency. Around 15–20% of the global population has dyslexia. Hundreds of millions of people use screen readers or other assistive technologies. And nearly everyone, at some point, reads in a suboptimal environment — harsh glare, a small screen, fatigue, or age-related vision changes.

The stakes go beyond empathy. In many jurisdictions, web accessibility is a legal requirement. The Americans with Disabilities Act (ADA) has been applied to websites in US courts. The European Accessibility Act came into force in 2025. Public sector sites across the UK, EU, Canada, and Australia must meet WCAG standards. Failing to meet these standards exposes organizations to legal liability and reputational risk.

But the most compelling argument for accessible typography is simply that it makes every experience better. High-contrast text, generous line height, and a legible font size improve reading for everyone — not just users with disabilities. This is the curb-cut effect: accommodations designed for people with disabilities end up benefiting the general population.

Consider the data: Google's own research on font size showed that increasing body text from 10px to 13px dramatically reduced the "pinch-to-zoom" rate on mobile — not among disabled users specifically, but among all users. Accessible defaults are often just good defaults.

WCAG Typography Requirements Summary

The Web Content Accessibility Guidelines (WCAG), published by the W3C, are the global standard for web accessibility. The current version is WCAG 2.2, with WCAG 3.0 in development. WCAG is organized around four principles — content must be Perceivable, Operable, Understandable, and Robust — and each success criterion is assigned a conformance level: A (minimum), AA (standard), or AAA (enhanced).

For typography specifically, the most relevant success criteria are:

1.4.3 — Contrast (Minimum), Level AA: The visual presentation of text and images of text must have a contrast ratio of at least 4.5:1 for normal text and 3:1 for large text (18pt/24px regular or 14pt/18.67px bold).

1.4.4 — Resize Text, Level AA: Text must be resizable up to 200% without assistive technology without loss of content or functionality. This effectively prohibits using fixed pixel units for font sizes.

1.4.6 — Contrast (Enhanced), Level AAA: A stricter standard requiring 7:1 for normal text and 4.5:1 for large text.

1.4.8 — Visual Presentation, Level AAA: Users must be able to adjust foreground and background colors, text must not be justified (both margins aligned), line spacing must be at least 1.5× the font size, and no horizontal scrolling at 80 characters width or less.

1.4.10 — Reflow, Level AA: Content must not require horizontal scrolling when the viewport is 320px wide (equivalent to 400% zoom on a 1280px screen).

1.4.12 — Text Spacing, Level AA: No loss of content or functionality when the following are set: line height to at least 1.5× the font size, letter spacing to at least 0.12em, word spacing to at least 0.16em, and spacing after paragraphs to at least 2× the font size. Your layout cannot break under these conditions.

These criteria interact with each other. A font that meets contrast requirements at one size may fail them at a smaller size. A layout that handles 200% text zoom may break under 1.4.12 text spacing adjustments. Testing each criterion in isolation is not enough — you need to test them together.

Font Choice: Legibility and Familiarity

The most accessible font is not always the most distinctive one. When users need to read large amounts of text, legibility — the ease with which individual characters are distinguished — matters more than originality. Several principles guide accessible font selection.

Avoid overly decorative or display fonts for body text. Script fonts, novelty display faces, and heavily stylized typefaces can make reading significantly harder for users with dyslexia or low vision. They should be reserved for short headings, logos, or ornamental text.

Choose fonts with clear character differentiation. The most common legibility trap is the "1, l, I" problem: in some fonts, the numeral 1, lowercase L, and uppercase I are nearly or completely identical. The same issue exists with "O" (capital O) and "0" (zero). Fonts with humanist or serif features tend to handle this better. Among Google Fonts, Inter is specifically designed with these distinctions in mind — it has a hooked lowercase L and a serifed uppercase I in its default character set. Roboto and Open Sans also have reasonable character differentiation, though less pronounced.

Prefer fonts users already recognize. Familiarity matters. A user with dyslexia who has developed coping strategies around a particular font family may struggle more with an unfamiliar face, even one theoretically designed to be easier to read. System fonts like -apple-system and Segoe UI have the highest familiarity of all for users on their respective platforms. When using web fonts, widely deployed families like Roboto, Open Sans, and Inter are safer choices than obscure alternatives.

Serif vs. sans-serif: the research is mixed. The traditional rule — serifs for print, sans-serifs for screens — has been increasingly challenged. High-resolution screens have eliminated most of the technical advantage of sans-serifs at small sizes. Some research suggests that transitional serif fonts like Source Serif 4 improve reading speed for long-form content. The most defensible position is to test your specific font at your specific sizes with your specific audience rather than applying a categorical rule.

Variable fonts offer accessible advantages. A variable font with a wght axis lets you dial in weights precisely rather than choosing from discrete 100-weight increments. This is valuable for accessibility because you can set body text slightly heavier than "Regular" (say, 420 instead of 400) for improved contrast on dark backgrounds, without stepping all the way up to 500 (Medium), which can affect spacing and reading rhythm.

/* Using a variable font with fine-grained weight control */
body {
  font-family: 'Inter', sans-serif;
  font-weight: 420; /* Variable font weight axis */
  font-size: 1rem;
}

Sizing: rem, Zoom, and User Preferences

Font size accessibility is dominated by one principle: never use px for font sizes. This requires some explanation, because the "why" is not obvious from the CSS alone.

When a user changes their default font size in browser preferences — a common accommodation for low vision users — they are setting the root font size. If your CSS uses px everywhere, this preference is overridden. A user who has set their browser default to 20px gets your 16px body text instead, defeating their own accommodation.

The rem unit (root em) respects the browser's root font size. 1rem equals whatever the user has set as their default — typically 16px in an unconfigured browser, but larger for users who have changed it.

/* Inaccessible — ignores user font size preference */
body {
  font-size: 16px;
}

h1 {
  font-size: 32px;
}

/* Accessible — respects user preference */
body {
  font-size: 1rem;
}

h1 {
  font-size: 2rem;
}

There is a related but distinct concept: browser zoom. When a user presses Ctrl/Cmd+Plus to zoom in, the browser scales everything — it is not changing the root font size. WCAG 1.4.4 requires that your layout does not break or lose content at 200% zoom. Using px for font sizes does not specifically break zoom behavior, but using px for layout widths and container sizes can, because those elements will not scale proportionally with the text.

A robust accessible approach uses rem for font sizes, em for padding and margin within components (so spacing scales with the component's text), and % or viewport units for layout containers:

/* Component with accessible sizing units */
.card {
  padding: 1.5em; /* scales with card's font size */
  max-width: 65ch; /* scales with font size — always readable line width */
}

.card__title {
  font-size: 1.25rem; /* scales with user preference */
  margin-bottom: 0.5em;
}

.card__body {
  font-size: 1rem;
  line-height: 1.6;
}

The ch unit — equal to the width of the "0" character in the current font — is particularly useful for maximum line widths, because it stays proportional to the font regardless of zoom level or user preference.

Beyond minimum sizing, consider the hierarchy of your type scale. WCAG does not mandate a specific minimum body font size (16px is a recommendation, not a requirement), but practical accessibility requires at least 16px equivalent at normal browser defaults. Smaller text — captions, footnotes, legal disclaimers — should be used sparingly and should not contain content essential to understanding the page.

Spacing: Line Height, Letter Spacing, Paragraph Width

After font size, spacing is the most impactful typographic variable for accessibility. WCAG 1.4.12 sets minimum thresholds, but meeting those thresholds is a floor, not a ceiling.

Line height (leading) is the vertical space between lines of text. WCAG requires that your layout not break when line height is set to 1.5× the font size. In practice, this is also close to the optimal value for body text. For body text at 1rem/16px, a line height of 1.5 to 1.7 works well. Headings at larger sizes can use tighter line heights (1.1 to 1.3) because the optical distance between lines is larger.

body {
  font-size: 1rem;
  line-height: 1.6; /* comfortable for extended reading */
}

h1, h2, h3 {
  line-height: 1.2; /* tighter for large display text */
}

/* Avoid unitless values only when necessary to prevent inheritance issues */
.caption {
  font-size: 0.875rem;
  line-height: 1.5; /* unitless — scales with this element's font-size */
}

Letter spacing (tracking) at body text sizes should generally be left at the font designer's default (0 or very close to it). The designer has already optimized the spacing for the font's specific letterforms. However, users with dyslexia sometimes benefit from slightly increased letter spacing, and WCAG 1.4.12 requires your layout not break at 0.12em additional letter spacing. Do not apply negative letter spacing to body text — it reduces legibility by cramming letterforms together.

Paragraph width (measure) is one of the most neglected accessibility considerations. Lines that are too long force readers to track across a wide visual field, making it easy to lose their place — a particular challenge for users with dyslexia or attention difficulties. The traditional typographic guidance is 45–75 characters per line for body text, or 50–75 characters. In CSS, the ch unit makes this easy to implement:

.article-body {
  max-width: 70ch;
  margin-left: auto;
  margin-right: auto;
}

Conversely, lines that are too short (fewer than 45 characters) create excessive eye movement from line to line, disrupting reading flow and making text feel choppy.

Paragraph spacing should be at least 2× the font size to create clear visual separation between paragraphs. This is also the WCAG 1.4.12 threshold. Using margin-bottom in em units keeps this proportional:

p {
  margin-bottom: 1.5em; /* 1.5 × font size between paragraphs */
}

Text alignment deserves attention too. Justified text — where both left and right margins are aligned — creates "rivers" of whitespace that are particularly disruptive to dyslexic readers. WCAG 1.4.8 (AAA) explicitly prohibits fully justified text. Left-aligned (ragged-right) text is the accessible default for Latin scripts.

Color Contrast: Beyond the Ratio

Color contrast for text is governed by WCAG 1.4.3 (AA, 4.5:1 for normal text, 3:1 for large text) and 1.4.6 (AAA, 7:1 and 4.5:1). These ratios are calculated using the W3C's relative luminance formula, which accounts for the nonlinear way human vision perceives brightness.

A contrast ratio of 4.5:1 is the minimum — just enough for most users to read text, but not comfortable for extended reading. Wherever possible, aim for 7:1 or higher for body text. This is especially important for smaller font sizes, where reduced luminance contrast has an amplified effect on readability.

/* These color combinations and their approximate contrast ratios */

/* ✓ Body text: high contrast (15.3:1) */
.text-primary {
  color: #1a1a1a;
  background-color: #ffffff;
}

/* ✓ Acceptable for large text only (3.9:1) — use with caution */
.text-muted {
  color: #767676;
  background-color: #ffffff;
}

/* ✗ Failing — do not use for body text (2.8:1) */
.text-danger {
  color: #999999;
  background-color: #ffffff;
}

Testing contrast ratios requires tooling. The browser DevTools in Chrome and Firefox both display contrast ratios when you inspect a text element and look at the color value in the Styles panel. The Colour Contrast Analyser by TPGi is a standalone tool that lets you pick colors from anywhere on your screen. Programmatic testing with axe-core or Lighthouse can catch contrast failures at scale.

But contrast ratios, as currently defined by WCAG, have known limitations. The formula was developed in the 1990s and does not fully account for:

• Polarity: Dark text on a light background (positive polarity) is generally easier to read than light text on a dark background (negative polarity), even at the same mathematical contrast ratio. This matters significantly for dark mode implementation.

• Font weight and rendering: Thin fonts fail at contrast ratios that bold fonts pass, because the thinner strokes have less physical ink coverage. A ratio that is readable in a 700-weight font may not be readable in a 300-weight font with the same color values.

• Hue: Some hue combinations with adequate luminance contrast still look hard to read — particularly red-green combinations for users with color vision deficiency.

• Background complexity: Contrast ratio is calculated against a solid background. If your text sits over a gradient, image, or pattern, the ratio varies across the text and the worst-case ratio must meet requirements.

The Accessible Perceptual Contrast Algorithm (APCA), developed by Andrew Somers, addresses many of these limitations. It is proposed for inclusion in WCAG 3.0. While not yet a legal requirement, it is worth understanding: APCA produces contrast values that better predict perceived readability, especially for large display text and thin weights.

For practical accessible typography today, the safest approach is: use dark text on a light background for body content, target 7:1 or higher for body text, test with actual tools rather than visual estimation, and be especially cautious with low-weight fonts and non-standard background treatments.

The combination of thoughtful font choice, proportional sizing with rem, generous spacing, and high contrast creates typography that works for everyone — including the users you never imagined reading your content. Accessible typography is, ultimately, just good typography.