May 9, 2022 · reala11y team
Text Spacing (WCAG 1.4.12): don't clip text on WordPress
WCAG 1.4.12 says users can override line, letter, word, and paragraph spacing without losing content. Here's how to test it on WordPress and the CSS gotchas that fail it.
Some readers can’t parse a dense block of text. People with dyslexia, low vision, or certain cognitive differences open up the line height, push the letters apart, and add space between paragraphs — often through a browser extension or a user stylesheet — so the words stop crowding each other. WCAG Success Criterion 1.4.12, Text Spacing, protects that adjustment. It says: when a reader bumps up these spacing values, your content must not break. It’s Level AA, and it’s one of the more testable criteria once you know the trick.
The catch is what counts as “break.” It doesn’t mean your design has to look identical with looser spacing. It means no text can be clipped, overlapped, or cut off when the reader applies the spacing — all the content stays present and readable.
What 1.4.12 actually requires
The reader must be able to set all four of these with no loss of content or functionality:
- Line height of at least 1.5 times the font size.
- Spacing following paragraphs of at least 2 times the font size.
- Letter spacing (tracking) of at least 0.12 times the font size.
- Word spacing of at least 0.16 times the font size.
You are not required to ship these values. The site’s own design can use whatever spacing you like. The requirement is that if a reader overrides them to those amounts, nothing disappears. Think of it as a stress test: your text containers have to flex when someone loosens the type.
A couple of important scoping notes. The criterion applies to content where a person can set the spacing via the platform — so it’s chiefly about text in HTML/CSS, not text baked into an image. And languages that don’t use spacing between words or letters are out of scope for those particular properties.
How to test it: the bookmarklet
The standard way to test 1.4.12 is to apply the four values and see what breaks. The accessibility community maintains a small Text Spacing bookmarklet (search for “WCAG text spacing bookmarklet” — Steve Faulkner’s is the well-known one) that injects exactly the required CSS:
* {
line-height: 1.5 !important;
letter-spacing: 0.12em !important;
word-spacing: 0.16em !important;
}
p {
margin-bottom: 2em !important;
}
Drag the bookmarklet to your toolbar, open a page, and click it. Then look for:
- Text cut off at the bottom or side of a fixed-height box.
- Lines overlapping each other or neighbouring elements.
- A button or badge where the label is clipped because the box can’t grow.
- Content that vanishes behind another element.
If everything simply gets taller and stays readable, you pass. If a card truncates its heading or a nav item swallows its own text, you’ve found a failure. You can also paste the CSS above into DevTools if you’d rather not install a bookmarklet.
The CSS gotchas that fail it
The failures almost always trace back to a container that can’t grow with its content. The usual suspects:
-
Fixed heights on text boxes.
height: 48pxon a button orheight: 200pxon a card means looser line height has nowhere to go — so it clips. Usemin-heightinstead, and let the box expand./* Fails 1.4.12: text is trapped. */ .badge { height: 32px; overflow: hidden; } /* Passes: the box grows with the text. */ .badge { min-height: 32px; } -
overflow: hiddenon text containers. Hiding overflow is how clipped text becomes invisible text. If a container clips, the content is lost — which is the exact failure mode 1.4.12 names. -
Spacing set with
!importantin your own CSS. If your stylesheet declaresline-height: 1.2 !important, a user stylesheet (which is also!important) still wins by the cascade — but author!importantis a sign you’re fighting the reader. Avoid forcing tight spacing. -
Truncation utilities. Single-line ellipsis (
white-space: nowrap; text-overflow: ellipsis) and line-clamp components hide text by design. They can be defensible for genuine previews, but on real content they collide with this criterion — make sure the full text is reachable somewhere. -
Tall, fixed hero text. Big display headings in a fixed-height band are a classic clip point once line height opens up.
Where WordPress sites trip up
On WordPress, the spacing problems usually aren’t in your post content — the editor outputs flexible paragraphs that handle this fine. They’re in the chrome around it:
- Theme buttons and badges with hard-coded pixel heights.
- Page-builder cards set to a fixed height so a grid stays tidy — looser spacing then clips the longest card.
- Mega-menus and nav items with fixed-height rows.
- Plugin widgets (sliders, pricing tables, “feature” boxes) that lock dimensions for visual symmetry.
The fix is nearly always the same move: swap height for min-height, drop overflow: hidden from anything holding real text, and let the box breathe. Because the fix lives in the stylesheet and the markup, it’s the kind of thing a code-level approach can surface — and the kind of thing an overlay widget can’t help with, since an overlay sits on top of the page rather than changing the CSS your readers’ own spacing overrides interact with. reala11y works at the source so the rendered HTML and CSS — what assistive tech and real visitors receive — is the thing that changed.
Where automated tooling fits — and where it doesn’t
A tool can flag fixed heights and overflow: hidden on text-bearing elements as candidates worth checking. But confirming an actual clip is a visual judgment: you apply the spacing and look. That last step is human, which is why the bookmarklet exists. The honest framing we hold to: automated tools, ours included, detect roughly 30–40% of WCAG issues by criteria, and Text Spacing in particular wants a person to eyeball the result.
The honest takeaway
Text Spacing is a small idea with a big payoff: let readers set their own line height and tracking, and don’t trap text in boxes that can’t grow. Run the bookmarklet across your templates, replace fixed heights with min-height, and stop hiding overflow on real content. Do that, and you’re moving toward WCAG 2.2 AA conformance on this front the right way — by making your text bend to the reader instead of the other way around.