WCAG Font Guidelines for Accessible Typography

Font contrast ratios: the 4.5:1 and 3:1 requirements

Roughly 253 million people worldwide have some form of vision impairment, and contrast is the single measurement that decides whether they can read your text. A contrast ratio expresses the difference in relative luminance between a foreground colour and its background, on a scale from 1:1 (identical colours) to 21:1 (black on white).

WCAG thresholds are not arbitrary. They are derived from research into people with moderately low vision, around 20/40, who do not use assistive technology. Meeting them does not restrict creative expression, and plenty of brand-aligned palettes clear 4.5:1 comfortably.

How the ratio is calculated

Thresholds by text size and weight

How font weight changes the threshold

Verified colour pairs

Every ratio below is calculated with the WCAG relative luminance formula against a pure white background unless stated otherwise.

Tools that measure it for you

Practices that keep you passing

• Check during design, not after build. Figma and Adobe XD plugins such as Stark catch failures before they become code.
• Aim above the minimum. Target 5:1 rather than exactly 4.5:1 so rendering differences and screen glare do not push you under.
• Contrast is not colour blindness. A pair can pass 4.5:1 and still be indistinguishable to a colour blind user, so never carry meaning in colour alone.
• Test on real devices. Phones in daylight show far less effective contrast than a desktop monitor indoors.
• Document the pairs that pass. A colour token table stops designers and developers reinventing failing combinations. Our CSS implementation guide covers structuring those tokens.

Dyslexia-friendly fonts and the spacing that matters more

Dyslexia affects 5 to 10% of the population. The typographic challenges are specific: mirrored letterforms (b, d, p, q), crowding that makes words hard to separate, rivers of white space running down justified text, and losing your place between lines.

The research on specialised dyslexia typefaces is genuinely mixed. Controlled studies have repeatedly found no significant reading speed gain over well-set Arial, while user surveys report reduced fatigue and greater comfort. Reduced fatigue is a real benefit even when speed is unchanged, which is why the right answer is to offer the choice rather than to impose one font on everybody.

Specialised dyslexia typefaces

Standard fonts many readers prefer

Work from the British Dyslexia Association and others points at ordinary fonts that perform well, and plenty of dyslexic readers prefer them precisely because they look unremarkable.

The spacing values that matter more than the typeface

Increasing letter spacing by around 35% over the default measurably improves reading speed for dyslexic readers, which is a larger effect than most font swaps produce. These values also line up with WCAG 1.4.12 Text Spacing, so meeting them serves both goals at once.

.dyslexia-friendly {
  letter-spacing: 0.12em;   /* WCAG 1.4.12 threshold */
  word-spacing: 0.16em;     /* WCAG 1.4.12 threshold */
  line-height: 1.8;         /* 1.5 is the WCAG floor */
  text-align: left;         /* never justify */
  max-width: 70ch;          /* 60 to 70 characters */
}

.dyslexia-friendly p {
  margin-bottom: 1.5em;
}

Give users the switch

Ship OpenDyslexic as an option alongside your default face and persist the choice. Serving it as WOFF2 keeps the extra download small, and font-display: swap keeps text visible while it loads.

@font-face {
  font-family: 'OpenDyslexic';
  src: url('/fonts/OpenDyslexic-Regular.woff2') format('woff2'),
       url('/fonts/OpenDyslexic-Regular.woff') format('woff');
  font-weight: 400;
  font-style: normal;
  font-display: swap;
}

:root {
  --letter-spacing: normal;
  --word-spacing: normal;
  --line-height: 1.5;
}

.dyslexia-mode {
  font-family: 'OpenDyslexic', Verdana, sans-serif;
  --letter-spacing: 0.12em;
  --word-spacing: 0.16em;
  --line-height: 1.8;
}

body {
  letter-spacing: var(--letter-spacing);
  word-spacing: var(--word-spacing);
  line-height: var(--line-height);
}

Screen readers and fonts: why the typeface is irrelevant

Screen readers convert digital text into synthesised speech or refreshable braille. JAWS, NVDA, VoiceOver, TalkBack, and Narrator all work the same way: they parse the DOM and the accessibility tree, and they never touch your font files. Whether you set Comic Sans or Helvetica makes no difference at all to a screen reader user.

What does matter is document structure: semantic HTML, heading hierarchy, landmarks, alternative text, form labels, and ARIA where native HTML cannot express the pattern. A beautifully typeset page with no semantic structure is unusable; a visually plain page with correct structure is excellent.

What the accessibility tree carries

Semantic emphasis beats visual styling

Screen readers can announce semantic emphasis but ignore CSS that only looks emphatic. The two versions below render identically and read very differently.

<!-- Carries meaning to assistive technology -->
<p>This is <strong>important</strong> text.</p>
<p>This is <em>emphasised</em> text.</p>

<!-- Looks the same, carries nothing -->
<p>This is <span style="font-weight: 700">bold</span> text.</p>
<p>This is <span style="font-style: italic">italic</span> text.</p>

Icon fonts are the real font accessibility problem

Display fonts are harmless to screen readers. Icon fonts are not. Font Awesome, Material Icons, and IcoMoon map glyphs onto Unicode characters, frequently in the private use area, and a screen reader will try to announce them as text. The result is an unknown character, a random phonetic fragment, or a completely unlabelled button. Understanding how Unicode ranges work explains why private use area mappings behave so unpredictably.

<button>
  <i class="fa fa-heart" aria-hidden="true"></i>
  Favorite
</button>
<!-- Announced as: "Favorite, button" -->

<button aria-label="Close dialog">
  <i class="fa fa-times" aria-hidden="true"></i>
</button>
<!-- Announced as: "Close dialog, button" -->

<button>
  <i class="fa fa-search" aria-hidden="true"></i>
  <span class="sr-only">Search</span>
</button>

.sr-only {
  position: absolute;
  width: 1px; height: 1px;
  padding: 0; margin: -1px;
  overflow: hidden;
  clip: rect(0, 0, 0, 0);
  white-space: nowrap;
  border: 0;
}

<!-- Decorative: hidden from assistive technology -->
<svg aria-hidden="true" focusable="false"><use href="#icon-heart" /></svg>
<span>Favorite</span>

<!-- Informative: announced -->
<svg role="img" aria-labelledby="search-icon-title">
  <title id="search-icon-title">Search</title>
  <use href="#icon-search" />
</svg>

The title attribute is a last resort. Not every screen reader announces it, so prefer aria-label or visually hidden text.

What actually decides the experience

Screen reader users navigate by headings more than by any other method, then by landmarks, lists, and the links list. Get those right and the font question disappears.

<header>
  <nav aria-label="Primary navigation">
    <ul>
      <li><a href="/">Home</a></li>
      <li><a href="/accessibility">Accessibility guides</a></li>
    </ul>
  </nav>
</header>

<main>
  <h1>Page title</h1>
  <h2>Section</h2>
  <h3>Subsection</h3>

  <label for="email">Email address</label>
  <input type="email" id="email" required>
</main>

<footer>...</footer>

<!-- Announced as: "Primary navigation, navigation landmark",
     "List, 2 items", "Item 1 of 2, Home, link" -->

• Real headings, in order. Never fake a heading with a styled div, and never skip a level.
• Descriptive link text.The links list strips surrounding context, so "Read the WCAG contrast guide" works and "Click here" does not.
• Programmatic form labels. A placeholder is not a label.
• Test with a real screen reader. NVDA is free on Windows and VoiceOver ships with macOS. Navigate your own site with the screen off.
• Reach for ARIA last. The first rule of ARIA is not to use ARIA. Prefer native HTML, and add ARIA only for custom widgets HTML cannot express.