( Perceivable / WCAG 1.4.12 )
Text spacing overrides break the layout
What is this issue?
A stylesheet or inline style attribute sets line-height, letter-spacing, word-spacing, or paragraph-level margin/padding using !important, or with CSS specificity high enough that a user’s own override stylesheet can’t beat it in the cascade. WCAG 1.4.12 requires that content remain readable and functional when a user applies more generous spacing than the page’s own defaults on top of the existing text, and a page whose spacing is effectively locked fails that requirement regardless of how reasonable its default values are.
This is distinct from whether the page’s default spacing is good: a page with comfortable default line-height can still fail this check if that value is declared with !important, since the failure is about overridability, not about the default value itself.
Why does this matter?
Some people with dyslexia, certain low-vision conditions, and some cognitive processing differences read measurably better with increased line-height, letter-spacing, or word-spacing than a typical default provides, not as a preference, but as a legibility accommodation comparable to font size. They apply this through an OS accessibility feature, a browser extension built for exactly this purpose, or a personal stylesheet, expecting it to work the same way font-size or color-scheme overrides do across the web.
When a site’s CSS blocks that override with !important, the user’s accommodation simply fails silently: text doesn’t get more legible, it can instead overlap, clip, or overflow its container in unpredictable ways, since some layouts assume the exact spacing values the CSS locks in. The user did everything right on their end; the failure is entirely the page’s.
Who is affected?
- Low vision users: some low-vision conditions benefit from increased letter- and word-spacing to distinguish individual characters, an accommodation a locked stylesheet prevents from taking effect.
- Cognitive disabilities: dyslexia and certain reading-processing differences are frequently improved by increased line-height and letter-spacing, a well-documented, widely-used accommodation that a spacing lock defeats regardless of the reader’s intent.
What users experience
Ingrid has dyslexia and uses a browser extension that applies increased line-height, letter-spacing, and word-spacing across every site she visits, a setup she configured years ago and now relies on without thinking about it. She visits a news site to read a long-form article, and the site’s CSS sets line-height: 1.2 !important on all paragraph text. Her extension’s override never takes effect because !important in the page’s own stylesheet wins the cascade regardless of what her extension tries to apply, so the article renders at the same cramped default spacing every other visitor sees, and she has to work noticeably harder to track each line without her usual accommodation.
How do I fix it?
Remove !important from line-height, letter-spacing, word-spacing, and paragraph-spacing declarations, and avoid setting them as inline style attributes, which carry higher cascade priority than most stylesheet rules. This works because CSS’s cascade lets a user’s own stylesheet (loaded through an extension or accessibility tool) override a page’s default styles by design: !important and inline styles are exactly the two mechanisms that break that override path.
Once the properties are overridable, test the page’s actual layout under WCAG’s specific spacing values (line-height at 1.5×, paragraph spacing at 2×, letter-spacing at 0.12em, word-spacing at 0.16em), applied simultaneously, using the browser bookmarklet built for this purpose. Fix any layout that clips, overlaps, or truncates unexpectedly under those values, typically by replacing fixed-height containers with min-height and removing single-line text truncation on elements where expanded spacing needs room to reflow.
Code Examples
<p style="line-height: 1.2; letter-spacing: 0;">
Increased spacing from a user's accessibility extension gets overridden here.
</p>p {
line-height: 1.2 !important;
letter-spacing: 0 !important;
word-spacing: 0 !important;
}<p>
A user's spacing override now applies correctly on top of this default.
</p>p {
line-height: 1.5;
letter-spacing: normal;
word-spacing: normal;
}Removing the inline style attribute and the !important flags doesn’t change how the page looks for anyone who hasn’t applied a spacing override; the default line-height: 1.5 still renders exactly as designed. What changes is that a user’s own stylesheet can now win the cascade and apply its more generous spacing values on top, instead of losing to a rule the page had artificially locked in place.
Common Mistakes
Mistake: “We use generous default spacing already, so this doesn’t apply to us.” This rule is about whether spacing can be overridden, not whether the default value is already generous. A page with comfortable line-height: 1.6 as its default still fails if that value is set with !important, since a user who needs even more spacing than the default provides has no way to apply it.
Mistake: “!important is necessary here to override a third-party widget’s inline styles.” Fighting specificity wars with !important on the four text-spacing properties specifically breaks the exact override path WCAG 1.4.12 protects. Resolve the specificity conflict with better-scoped selectors or CSS custom properties instead of reaching for !important on line-height, letter-spacing, word-spacing, or paragraph spacing.
Mistake: “Testing at 200% browser zoom already covers this requirement.” Zoom and text spacing are separate, independently-testable failure modes: 1.4.4 Resize Text and 1.4.12 Text Spacing respectively. A page can reflow perfectly at 200% zoom and still fail 1.4.12 if its spacing values are locked with !important, since zoom scales everything proportionally while a spacing override changes only specific properties.
How RedFlag Detects This
Automated: axe-core rule, runs on every scan. RedFlag calls axe-core’s avoid-inline-spacing rule as part of every scan, restricted to the WCAG 2.0/2.1/2.2 A and AA rule set. The rule inspects every element’s inline style attribute for line-height, letter-spacing, word-spacing, or margin properties, and flags any of the four text-spacing-related properties set inline, since inline styles carry high cascade specificity that resists most user override stylesheets.
False negative: the check only inspects inline style attributes, not !important declarations inside external or <style>-block stylesheets; a page that locks the same four properties with !important in its main CSS file rather than inline can produce the identical override failure without triggering this specific check. False positive: none typical, since detecting the presence of these four properties in an inline style attribute is a straightforward, binary parse of markup already on the page. Manual step: apply WCAG’s specific text-spacing values using the community text-spacing bookmarklet and visually confirm no content clips, overlaps, or becomes unreadable; this also catches the !important-in-stylesheet case the automated check can’t see.
Manual Testing
- Load the text-spacing bookmarklet (or a similar tool) and apply it to the page; it sets line-height to 1.5×, paragraph spacing to 2×, letter-spacing to 0.12em, and word-spacing to 0.16em simultaneously.
- Scan the page for any text that clips, overlaps adjacent content, or gets cut off inside a fixed-height or
overflow: hiddencontainer. - Check any single-line truncated text (an ellipsis-style overflow) specifically, since increased line-height often breaks these containers even when the rest of the page reflows cleanly.
- Confirm no content or functionality is lost. Every button, label, and piece of text should still be present and readable, just spaced out more, not hidden or truncated away.
Related WCAG Success Criteria
1.4.12 Text Spacing: No loss of content or functionality when a user applies specific increased line-height, paragraph-spacing, letter-spacing, and word-spacing values. This rule is a direct check of whether the page’s own CSS blocks that override from applying in the first place, via inline styles.
Related Issues
Text does not have enough colour contrast and Text does not meet enhanced AAA contrast requirements share this rule’s focus on text legibility, though they address color rather than spacing.
UI component has insufficient contrast is part of the same “presentation adapts to what the user actually needs” principle as this rule, applied to component boundaries instead of text spacing.
CSS locks content to a single orientation and Interactive element is too small to tap accurately share this rule’s underlying theme: a fixed presentation choice that works for a typical user can become an access barrier for someone whose physical needs differ from that default.
Page animations have no reduced motion alternative is a similarly presentation-layer, easy-to-fix CSS check worth auditing in the same pass as this one.
References
- W3C Understanding 1.4.12: Text Spacing
- W3C Technique C36: Allowing for text spacing override
- Text spacing bookmarklet
Frequently asked questions
What exact spacing values does WCAG 1.4.12 require support for?
The criterion requires that content stay readable and functional when a user sets line height to at least 1.5 times the font size, spacing after paragraphs to at least 2 times the font size, letter spacing to at least 0.12 times the font size, and word spacing to at least 0.16 times the font size, all simultaneously, applied on top of whatever the page already had.
Does this rule mean I can never use !important on text properties?
No. The requirement is narrower: the four specific properties (line-height, letter-spacing, word-spacing, paragraph spacing) must remain overridable, typically by avoiding !important and overly specific selectors on those particular properties. Using !important on unrelated CSS, such as color or layout properties, is unaffected by this criterion.
Do text-spacing overrides only come from browser extensions?
No. A user can apply increased spacing through an operating system accessibility feature, a browser extension built for exactly this purpose, or their own custom stylesheet loaded via browser DevTools or a user-styles extension; the requirement is that any of these methods work, not one specific tool.
Does fixed-height text truncation, like a single-line overflow ellipsis, fail this check too?
It can, if increasing line-height or letter-spacing on truncated text causes it to clip, overlap, or become unreadable rather than simply reflowing. Test truncated and fixed-height text containers specifically, since they are a common place this failure hides even when the rest of a page passes.
Is this the same requirement as supporting 200% browser zoom?
No, they are separate reflow-related criteria. Zoom (1.4.4 Resize Text) tests whether content stays usable when the whole page is scaled up. Text spacing (1.4.12) specifically tests whether content stays usable when spacing values change independently of zoom level; a page can pass one and fail the other.