WCAG Text Spacing: Test 4 Overrides, Then Fix the CSS

WCAG Success Criterion 1.4.12 requires that line height, paragraph spacing, letter spacing, and word spacing can be overridden by the user, at 1.5 times, 2 times, 0.12 times, and 0.16 times the font size respectively, without any loss of content or functionality. These four values are multipliers of font size, not fixed pixel amounts. The authoring obligation set by the W3C is not to design with these exact values by default, but to make sure a site survives them when a visitor or assistive tool applies them. We built AccessWiser around exactly this kind of code-level verification, so let’s walk through what the rule actually demands.

TL;DR:

• You do not need to use these values by default; your layout must withstand them when users or assistive tools apply them.

• For scripts that do not use a given spacing property, that specific override does not apply; all relevant spacing rules still apply.

• Test at 100% browser zoom, apply each override separately, then combine all four at every responsive breakpoint and confirm controls remain visible and usable.

• Fixed height text containers often fail; let them grow with content, avoid hidden overflow, and size type and spacing in relative units.

Table of Contents

• What WCAG 1.4.12 requires from your code

• Why text spacing resilience matters for real readers

• Testing text spacing step by step

• Common coding mistakes that break text spacing and how to fix them

• A quick testing checklist for your QA tickets

• Our take: automation finds the pattern, code fixes make it stick

• How AccessWiser helps you close text-spacing gaps

• FAQ

• Sources

What WCAG 1.4.12 requires from your code

The four metrics in Success Criterion 1.4.12 are calculated as multipliers of the font size rather than as fixed values. Line height must reach at least 1.5 times the font size, paragraph spacing at least 2 times, letter spacing at least 0.12 times, and word spacing at least 0.16 times. A 16px paragraph, for example, needs to tolerate a line height of 24px, space after it of 32px, letter spacing of roughly 1.92px, and word spacing of roughly 2.56px, all applied at once, without text disappearing or controls becoming unreachable.

Nothing in the criterion asks you to ship these values as your default styling. The pass or fail condition is what happens when someone else, through a browser extension or a custom stylesheet, pushes those values onto your layout.

The W3C also carves out a practical exception for languages and scripts that do not use a given spacing property. Japanese does not rely on standard paragraph spacing the way Latin scripts do, so testers are unlikely to apply that particular override, and authors are not held to that specific requirement for that language. Where a script does use a property, though, the resilience requirement still applies in full.

Why text spacing resilience matters for real readers

People with low vision often increase letter and word spacing to separate characters that otherwise blur together. Readers with dyslexia frequently widen line height and paragraph spacing to reduce visual crowding and make scanning easier. Neither group is asking your site to look different by default. They are asking it to survive the adjustments they already rely on elsewhere.

When a layout cannot flex, the failures are predictable: text gets clipped or hidden behind fixed-height boxes, content boxes overlap each other, buttons and form labels truncate until they are unreadable, and in the worst cases entire sections collapse into unusable fragments. None of this is about enforcing a particular aesthetic. It is about making sure your interface keeps working once someone else changes the spacing math.

Testing text spacing step by step

Start every test at 100% browser zoom so spacing changes are not conflated with zoom-related reflow. From there, apply the overrides methodically rather than all at once, so you can trace any failure back to its exact cause.

Useful tools for applying the overrides include a text spacing bookmarklet, a user-style extension such as Stylus, or manual CSS injection through your browser’s developer console.

1. Capture a baseline screenshot of the page at default spacing.

2. Apply line height alone at 1.5 times font size and check the page.

3. Reset, then apply paragraph spacing alone at 2 times font size.

4. Reset, then apply letter spacing alone at 0.12 times font size.

5. Reset, then apply word spacing alone at 0.16 times font size.

6. Apply all four overrides together, which is the real-world scenario a user-style extension creates.

7. Repeat the combined test at each of your responsive breakpoints, since a layout that survives on desktop can still fail on a narrow viewport.

At each step, check for the same things:

• Clipped or hidden text inside fixed-height boxes.

• Overlapping text or content blocks.

• Truncated or unreachable buttons, links, and form labels.

• Horizontal scrollbars appearing where none existed before.

Pro Tip: Log every failure with a screenshot, the exact override values applied, the element’s CSS selector, and the breakpoint, so a developer can reproduce the issue in seconds rather than hunting for it.

A page passes when every one of these checks comes back clean with all four overrides applied together, at every breakpoint you support, and every interactive element stays visible and operable.

Common coding mistakes that break text spacing and how to fix them

Most 1.4.12 failures trace back to a small set of CSS habits. Practitioner testing guidance points to fixed heights on text containers as the single most common cause, since a box set to a fixed height has nowhere to put the extra line height or paragraph spacing a user applies, so the overflow gets clipped or hidden entirely.

The fixes are straightforward once you know what to look for:

• Replace fixed height with min-height or let the container size to its content.

• Avoid overflow: hidden on any element that wraps text, since it is what turns a spacing overflow into invisible content.

• Size type and spacing in em, rem, or percentages instead of pixels, so they scale together with font size.

• Keep text containers out of absolute positioning, which tends to lock them into dimensions that cannot grow.

• When a container’s width genuinely must stay fixed, build in extra vertical space so expanded line height and paragraph spacing have somewhere to go.

Pro Tip: Test each fix immediately after you make it, with the combined override still applied, rather than batching several CSS changes before your next check.

A quick testing checklist for your QA tickets

A short checklist keeps text-spacing testing consistent across pages and across the people running it.

• Apply each of the four metrics individually, then apply all four together.

• Check every navigation menu, button, and form label for truncation.

• Confirm no text is replaced by an ellipsis or cut off mid-word.

• Test the combined override at each responsive breakpoint your site supports.

• Record the page URL, the tool used, and the viewport sizes tested.

• Note a clear pass or fail for each page, with reproduction steps attached to any failure.

A sign-off line as simple as “Page: [URL], Tool: Stylus, Viewports: narrow, medium, and wide, Result: Pass” gives a team an audit trail without extra overhead, and it is the kind of record worth keeping alongside any broader accessibility statement your organization maintains.

Our take: automation finds the pattern, code fixes make it stick

Automated scanning can help identify text-spacing failures, including fixed-height containers and clipped text. But a scan result is only the start. Lasting compliance comes from fixing the underlying CSS, not patching it at runtime, which is why we pair every finding with plain-language guidance aimed at your actual code. Dated records of scans and fixes, checked again on a schedule, give you evidence that the fix held rather than a one-time snapshot.

— The AccessWiser Team

How AccessWiser helps you close text-spacing gaps

Catching 1.4.12 failures by hand across every page and breakpoint takes real time, and that is exactly the gap our scanning closes. We check your site against applicable accessibility standards and tie each text-spacing finding to the specific element it affects, so your developers can address the cause rather than guessing page by page.

• Scheduled re-checks catch regressions after a redesign or a new content push.

• Dated scan and fix records give you documentation to support your broader compliance program.

• An optional visitor-facing widget lets people adjust contrast, text settings, and reading aids directly on your site.

Plans start with Starter at $24 per month, scaling up through Basic, Pro, and Business for larger page counts. If you want a clearer picture of where your own spacing resilience stands, our pricing page lays out every tier, or you can start with a scan and see the findings for yourself.

FAQ

How do I adjust the spacing between text?

In CSS, you adjust spacing with properties like line-height, letter-spacing, word-spacing, and margin-bottom on paragraphs. For WCAG testing specifically, you apply these as overrides through a browser extension, a bookmarklet, or manual dev-tools injection rather than changing your default styles, since the goal is to confirm your layout survives a user-applied change.

What is considered large text in WCAG?

Large text in WCAG generally refers to text large enough to matter most for contrast-related success criteria, while the text-spacing criterion applies to all text sizes, not only large text.

Is 1.0 single spacing?

Yes, a line height equal to the font size is single spacing, meaning the line box matches the font size with no extra room between lines. WCAG 1.4.12 requires that layouts tolerate a line height increase to at least 1.5 times the font size, which is noticeably looser than single spacing.

What are some HTML codes for text spacing?

Text spacing in HTML is controlled through CSS rather than HTML tags directly, using properties such as line-height, letter-spacing, word-spacing, and margin-bottom on elements like paragraphs and headings. For accessibility testing, pair these properties with a text spacing bookmarklet or a browser extension to confirm your markup holds up under the required multipliers.

Sources

Primary W3C guidance and practitioner testing resources are linked throughout this article.

• Help

• Understanding Success Criterion 1.4.12: Text Spacing | WAI | W3C

Recommended

• Nontext Contrast: Test WCAG 1.4.11 at 3:1 and Fix It in Code

• Increase Spacing First: Make a Dyslexia Friendly Font Work

• No OS Toggle Needed, High Contrast CSS Patterns Developers Can Drop In

Articles on this blog are general information about web accessibility, not legal advice. Laws change and their application depends on your specific situation — for decisions with legal consequences, consult a qualified legal professional.