Accessible typography: font size, line height and spacing (WCAG 1.4.12)

Typography is how text is set on a page: the typeface, size, line height (the space between lines), paragraph spacing, letter spacing, word spacing and line length. WCAG names no required typeface and, as WebAIM's article on fonts points out, no minimum font size. What it asks for is resilience: a page has to keep all of its content and functionality when users enlarge the text or change its spacing.

The reason is practical. W3C's Understanding document for 1.4.12 Text Spacing says people with low vision may need more space between lines, words and letters, and that people with dyslexia may increase spacing to read faster. If a card, button or menu clips its text when they do, the content is gone for exactly the people who changed the settings.

This guide is general information based on W3C's published guidance, not legal advice. Where it goes beyond a source, we say it is our reading.

Which WCAG criteria cover text?

Five success criteria matter most for how text is set. The two at the center are 1.4.12 and 1.4.4, both Level AA.

Of these five, only 1.4.8 reaches into line length and justification, and it is Level AAA, above the Level AA that the ADA Title II web rule and Section 508 name (see US accessibility law). We treat its advice as good practice, not a requirement. Every criterion is listed in our WCAG 2.2 reference.

What does WCAG 1.4.12 Text Spacing require?

Success criterion 1.4.12 applies to content in markup languages that support these text properties, which includes HTML and CSS. It is met when no content or functionality is lost if a user sets all four values below and changes no other style property.

W3C's Understanding document adds points that change how the criterion is read:

• You do not have to use these values. The requirement is that a user's override does not break the page, and authors must not block the override. W3C calls the values a baseline, not a ceiling, and says the ability to read the overridden spacing rests with the user.
• A writing system that does not use a property is excused from it. A language that does not use one of the four can meet the criterion with the properties that apply to it.
• Images of text and captions burned into video are not expected to adapt. W3C counts text drawn on a canvas as an image of text.
• Truncation with an ellipsis can pass if the cut-off text is still reachable, for example revealed on focus or activation.

W3C shows three failure shapes: text cut off at the bottom, text cut off at the end of its line, and text that runs into the next block. It lists failure F104 for clipped or overlapped content when text spacing is adjusted.

Why pages break when spacing changes

Most failures come from a layout that assumes text will stay at the size it was designed at. The usual causes, from W3C's techniques C36 and C35, its failure F104 and our own reading:

• Fixed heights on text boxes. A card, banner or button with a set height and hidden overflow clips its text once lines grow taller. C36 notes that leaving the CSS height property unset helps paragraphs expand.
• Fixed widths on text that does not wrap. Navigation items, tabs and buttons are the usual cases. C35 gives a safe value of 20 percent wider than the default maximum width: a container that fits 20 characters should fit 24.
• Line height set in pixels. A user's spacing override replaces it, so it does not fail 1.4.12 by itself. But a fixed length does not follow the font size, so lines can collide when people enlarge the text.
• Text pinned over other content. Absolutely positioned labels, captions over photos and floating form labels overlap their neighbors when text grows.
• Clipped overflow and line clamps. They hide the end of the text, which fails unless the rest can be revealed.

The fix is usually to let the box follow the text:

/* Breaks when a user adds spacing or enlarges text */
.card { height: 120px; overflow: hidden; }
.nav a { width: 96px; }
body { line-height: 20px; }

/* Survives it */
.card { min-height: 7.5rem; }
.nav a { min-width: 6rem; padding-inline: 0.75em; }
body { line-height: 1.5; }

Font size: use relative units and test at 200 percent

WebAIM says small text hurts readability even though WCAG sets no minimum size, and that relative units such as percentages or ems give more flexibility than pixels or points. MDN goes further: many users raise their browser's default font size, absolute lengths do not scale with those settings, and for that reason MDN says to prefer relative lengths such as em or rem when setting font-size. A rem is the font size of the root element, commonly 16px by default, which user preferences may change. So leave the root size alone and size everything else from it:

body { font-size: 1rem; line-height: 1.5; }
h1 { font-size: 2rem; }

Success criterion 1.4.4 Resize Text asks that text can be resized up to 200 percent without assistive technology. W3C says browsers are primarily responsible for scaling and authors must not prevent it. A page passes if it scales using at least one mechanism that browsers support, such as zooming the entire page. The criterion applies to each automatically presented variation, such as a media-query breakpoint, so test the narrow layout as well as the wide one.

Three things get in the way:

• A zoom lock. MDN warns that user-scalable=no in the viewport meta tag stops people with low vision from reading the page, and that the best practice is to allow 5 times zoom. Browser settings can ignore the tag, and iOS 10 and later does by default, but do not depend on that. Our free scan flags it.
• Viewport units for text. W3C lists F94 as a failure: incorrect use of viewport units to resize text. Text sized mainly in units such as vw is likely to fail, W3C says, because zooming does not change it. Test that your text still grows up to 200 percent when you zoom.
• Images of text. 1.4.4 excepts them, but W3C says to use real text where possible because images pixelate when scaled and are harder to recolor. See images of text.

Size also matters for contrast. For 1.4.3, large-scale text is at least 18 point, or 14 point bold, which W3C says is approximately 24 and 18.5 pixels, and it needs 3:1 rather than 4.5:1. Our large text contrast guide covers the exception.

Line height, line length and alignment

• Line height. MDN recommends at least 1.5 for main paragraph content, to help people with low vision and people with cognitive conditions such as dyslexia. Use a unitless number, which MDN calls the preferred way: it scales with the text when a page is zoomed, and it is multiplied by each element's own font size, while MDN warns that em and percentage values may produce unexpected results through inheritance, such as a large heading getting lines that are too tight. Level AAA 1.4.8 asks for line spacing of at least space-and-a-half and paragraph spacing at least 1.5 times the line spacing.
• Paragraph spacing. WebAIM says that because online content scrolls, space between paragraphs helps readers tell them apart. A style reset that zeroes margins should put it back.
• Line length. 1.4.8 sets 80 characters, or 40 for Chinese, Japanese and Korean text. WebAIM's layout article says fewer than around 50 or more than around 120 characters per line will likely introduce difficulty, and that no number is optimal everywhere. A max-width in ch units, for example 70ch, gives an approximate count inside both ranges.
• Alignment. WebAIM says left alignment is almost always the easiest to read, except in some Asian and Middle Eastern languages, and that fully justified text adjusts word and letter spacing in ways that impair readability and can create distracting rivers of white. W3C's failure F88 for 1.4.8 is fully justified text.
• Letter and word spacing. WebAIM's fonts article says confusion can be introduced when letters or words appear very close to each other, so we would not tighten the tracking on body text.

How text reads, such as sentence length and word choice, is a separate subject: see plain language and readability.

Typefaces and text styles

WebAIM says there is no single best typeface. Its advice is to choose simple, familiar fonts, avoid characters that are easy to confuse (C and O, or I, l and 1), limit the number of typefaces and variations, and be careful with long passages that are entirely bold, italic or capitalized. Its layout article adds that underlining text that is not a link will likely confuse some users; our guide to links and color covers how to mark links.

Thin fonts need extra care. W3C's Understanding document for 1.4.3 says very thin or unusual fonts may be rendered with a much fainter color than the CSS specifies, and advises a font with stronger lines or a color pair beyond the minimum ratio.

Test text spacing in five minutes

W3C's technique C36 gives the procedure: set zoom to 100 percent, apply the four spacing values with a tool such as the Text Spacing Bookmarklet or a user-style browser plugin, then check that all content and functionality remains available. This snippet is our own version of the second step. Apply it with a user-style extension or add it as a rule in your browser's developer tools:

* {
  line-height: 1.5 !important;
  letter-spacing: 0.12em !important;
  word-spacing: 0.16em !important;
}
p { margin-bottom: 2em !important; }

Then work through these steps:

1. Look at every kind of text container: navigation, buttons, tabs, cards, form labels and error messages, tooltips, banners and table headers. Look for the three failure shapes above, and for text that vanishes behind hidden overflow.
2. Repeat at each layout. C36 says to test every layout a page has, so check a narrow window as well as a wide one.
3. Remove the snippet and zoom the browser to 200 percent. Nothing should be clipped, truncated or obscured (failure F69), and text inside form controls should grow with everything else (F80).
4. Raise the browser's default font size and reload. This is our addition: it shows whether text sizes follow the user's setting or were pinned in pixels. Then read the viewport meta tag to confirm it allows zoom; W3C lists an ACT test rule, Meta viewport allows for zoom, for that check under 1.4.4.

Log what you find against 1.4.4 and 1.4.12 in the WCAG audit checklist. For zoom beyond 200 percent, including the 320 CSS pixel case, continue with zoom and reflow.

What an automated scan can and cannot tell you

W3C lists three optional ACT test rules for 1.4.12, and they cover one narrow case: whether spacing set with !important in a style attribute is wide enough. None of them looks for clipped or overlapped text, which in our reading is a visual check for a person.

GotAlt's free scan reads the HTML your server sends, and one of its 16 rule-based checks bears on this topic: it flags zoom disabled in the viewport meta tag (1.4.4). On monitored pages, a browser check also measures text contrast (1.4.3). Neither applies the spacing values, zooms the page to 200 percent or looks for clipped text. What we check lists every rule.

Check it yourself

• Contrast. The contrast checker takes a text color and a background color and returns the ratio, a pass or fail at AA and AAA, and the nearest color that passes. Test body text against 4.5:1, large headings against 3:1 and thin fonts with margin to spare. The color contrast guide has the details.
• The page as painted. The accessibility bookmarklet checks a live page in your own browser, including the colors it actually paints.
• Zoom lock. Scan my site for free flags a viewport meta tag that disables zoom, among its other rule checks.