1.4.12 Text Spacing

Level AA
Perceivable
Since WCAG 2.1

Summary

Many people with dyslexia, low vision, or other reading difficulties change text spacing to make content readable: wider line spacing, extra letter and word spacing, more room after paragraphs. They do it with custom stylesheets, browser extensions, or reader tools, not with anything the site provides. This criterion protects them by requiring that the page tolerates those changes: when line height goes to 1.5 times the font size, paragraph spacing to 2 times, letter spacing to 0.12 times, and word spacing to 0.16 times, nothing may be clipped, overlapped, or lost.

The auditor's mental model: the author does not have to provide a spacing mechanism, and does not have to design for spacing beyond the four specified values. The author only has to not break when the user applies them. Grading is therefore a stress test: apply exactly those overrides, then sweep the page for loss of content or functionality. The classic culprits are fixed-height containers combined with hidden overflow, and controls sized to the exact width of their default label. Text that wraps, reflows, or simply looks less polished is fine; text you can no longer read or a control you can no longer use is a fail.

Official wording

In content implemented using markup languages that support the following text style properties, no loss of content or functionality occurs by setting all of the following and by changing no other style property:
Line height (line spacing) to at least 1.5 times the font size;
Spacing following paragraphs to at least 2 times the font size;
Letter spacing (tracking) to at least 0.12 times the font size;
Word spacing to at least 0.16 times the font size.
Exception: Human languages and scripts that do not make use of one or more of these text style properties in written text can conform using only the properties that exist for that combination of language and script.

Success Criterion 1.4.12 Text Spacing, Web Content Accessibility Guidelines (WCAG) 2.2, W3C Recommendation, 5 October 2023 (updated 12 December 2024). Copyright © 2023-2024 World Wide Web Consortium. https://www.w3.org/copyright/document-license-2023/. Reproduced unmodified under the W3C Document License.

EN 301 549 mapping

Web pages: Clause 9.1.4.12
Software and native apps: Clause 11.1.4.12
Condition: The software clause applies only where the app does not have a fixed-size content layout area that is essential to the information conveyed.

Clause 9.1.4.12 applies this criterion to web pages unchanged. Clause 11.1.4.12 applies it to software only where the app does not have a fixed-size content layout area that is essential to the information conveyed.

Clause references are to EN 301 549 V3.2.1 (2021-03), the harmonised European standard. Descriptions are our own summary, not the text of the standard.

In practice

Web

Apply the four override values to the whole page. The standard method is a small stylesheet injected via a bookmarklet or the browser developer tools, setting on all elements: line-height: 1.5 !important; letter-spacing: 0.12em !important; word-spacing: 0.16em !important; plus margin-bottom: 2em !important on paragraphs. The !important flags matter, because the criterion is about user overrides winning; a site whose inline styles or JavaScript re-apply the original spacing after your override is a fail on its own terms.

With the overrides active, sweep every page state: navigation menus (open them), buttons and tabs, cards, footers, form labels, accordions, tooltips, and anything with a fixed height. Look for text clipped at a container edge, lines overlapping one another, button or tab labels truncated or spilling out of their control, and text sliding under adjacent elements. Check both viewport widths you audit at, since a layout that survives on desktop can clip on mobile.

Scope notes worth knowing. The criterion covers content implemented in markup languages, so HTML is squarely in scope, while text painted into canvas or baked into images is not graded here (images of text have their own criteria). Truncation that already exists by design (an ellipsis on a card teaser with a full version available) is not a loss caused by spacing. And the exception is about writing systems: scripts that do not use one of the four properties (for example, scripts written without spaces between words, or scripts where letter spacing does not apply) are graded only on the properties that exist for that language and script.

iOS

The criterion is written for markup languages, so a fully native iOS interface built from UIKit or SwiftUI components is largely outside its direct reach: there is no user stylesheet mechanism to override tracking and line height in native views. The European standard reflects this with a condition: the software clause applies only where the app does not have a fixed-size content layout area that is essential to the information being conveyed. Where a native screen genuinely depends on a fixed-size layout, the requirement does not bite; where it does not, treat spacing tolerance as in scope.

Anything rendered in a web view (WKWebView, an embedded help centre, a hybrid app shell) is ordinary markup and fully in scope: load the page in the web view, apply the same overrides (via a debug build hook or by auditing the same URL in Safari), and sweep for clipping exactly as on the web.

As guidance for native screens: auditors still exercise text tolerance through Dynamic Type. Turn on larger text sizes in Settings (Accessibility, Display and Text Size) and check that labels wrap rather than truncate and containers grow with their content. That behaviour is graded under the resize and reflow criteria rather than here, but a native layout that survives Dynamic Type will almost always tolerate spacing changes too, and one that clips at larger sizes signals the same fixed-height design flaw this criterion targets.

Android

The same honest scoping applies. Native Android views and Compose layouts are not markup in this criterion's sense, and there is no system mechanism for users to override letter spacing or line height across an app, so fully native screens are largely outside the criterion's direct reach. The European standard's condition is the same as on iOS: the software clause applies only where the app has no fixed-size content layout area essential to the information conveyed.

Web view content is fully in scope. Audit the embedded pages with the standard override stylesheet, either by opening the same URLs in Chrome (with the bookmarklet) or by attaching Chrome DevTools to the app's web view via remote debugging, then sweep for clipped and overlapping text.

As guidance for native screens: use the font size and display size settings (and check sp units are used for text) to confirm layouts grow with their text. Watch for TextViews with fixed heights, maxLines with ellipsis on essential content, and buttons sized to the default label. As on iOS, those findings are graded under resize and reflow, but they are the same fixed-dimension failures this criterion punishes on the web, and flagging them keeps the app robust for users who scale text.

Pass and fail examples

Passes:

A content page where applying all four overrides makes every container grow taller: text wraps, cards stretch, the layout gets longer but nothing disappears.
A navigation bar whose items have padding and can wrap to a second line when letter and word spacing push the labels wider.
A button sized by its content, so a longer, wider-tracked label makes the button grow rather than clipping the text.
A page in a script that is written without spaces between words, graded only on line height, paragraph spacing, and letter spacing, which it tolerates.
A card teaser that is ellipsised by design before and after the overrides, with the full text available on the detail page: nothing the spacing change caused was lost.

Fails:

A hero banner with a fixed height and overflow: hidden whose last line of text vanishes when line height increases to 1.5.
Tab labels that truncate to unreadable fragments when letter spacing is applied, with no way to tell the tabs apart.
Absolutely positioned headings that overlap the paragraph below them when line height grows, leaving both illegible.
A script on the page that measures and re-applies the original letter-spacing after the user's override, defeating the user's stylesheet.
A form where the increased spacing pushes the submit button's label out of the visible button area, so the control's purpose is lost.

Not a fail under this criterion:

Text that merely wraps differently, leaves ragged edges, or looks cramped after the overrides: awkward is not loss of content or functionality.
A page that breaks only when spacing is pushed beyond the specified values (say, double letter spacing): the criterion tests exactly the four values, nothing more.
A site that offers no spacing controls of its own: the author is not required to provide the mechanism, only to tolerate it.
Text inside an image that cannot respond to spacing at all: grade it under the images of text criteria, not here.
Text clipped at 400 percent zoom with default spacing: that is a 1.4.10 Reflow finding, triggered by zoom rather than spacing overrides.

Commonly confused with

Resize Text, SC 1.4.4. 1.4.4 is about making text bigger (200 percent) without loss; 1.4.12 is about spreading text out at its existing size. A layout can handle enlargement yet clip when line height and tracking grow, and vice versa. File size findings under 1.4.4 and spacing findings here.
Reflow, SC 1.4.10. Both criteria punish fixed-height containers and hidden overflow, so the same broken component often earns both findings, but the triggers differ: 1.4.10 is tested by zooming to a 320 CSS pixel width, 1.4.12 by applying the spacing overrides. Record which stress test produced the loss.
SC 1.4.8 Visual Presentation. The Level AAA criterion requires the site itself to offer presentation choices (line spacing, colours, column width). 1.4.12 requires no mechanism at all, only tolerance of the user's own. Citing a missing spacing control against a Level AA audit is a AAA expectation misfiled.
SC 1.4.5 Images of Text. Spacing overrides cannot touch text rendered as an image. If essential text is trapped in an image, the finding belongs to the images of text criteria; grading the image's failure to respace under 1.4.12 double-counts a different defect.

How AUDITSU tests this

AUDITSU's audit walkthrough covers text spacing as part of the visual robustness checks on every web screen you review. The walkthrough prompts you to apply the four override values (a bookmarklet or devtools snippet with the exact figures), then inspect the screen for clipped, overlapping, or truncated text and for controls whose labels are no longer usable. Each question records a pass, fail, or not applicable result per screen with evidence attached, so a clipped banner is tied to the exact screen and component in your report. On native mobile screens the walkthrough records the criterion as not applicable where no markup content is present, and routes fixed-height text findings to the resize and reflow checks instead, keeping every finding under the criterion that actually triggered it.

For the full guided workflow, see the audit platform.