Justified Text Is Still Breaking Readability in 2025

A paragraph renders on screen. The words stretch edge to edge, perfectly flush on both sides. The designer calls it clean. The developer didn't touch the default. And somewhere, a user with dyslexia is watching rivers of white space cascade down the text block, losing their place for the third time in the same sentence.

This is WCAG Failure F88 (opens in new window). It's one of the simplest failures in the W3C catalog to describe, one of the easiest to fix, and — frustratingly — one that keeps reappearing in production code because it lives in the gap between "looks professional" and "actually readable."

The Failure

F88 (opens in new window) documents a specific violation of WCAG 2.2 Success Criterion 1.4.8: Visual Presentation (opens in new window). The criterion covers a range of visual text requirements for blocks of body text — and full justification (aligning text flush to both left and right margins) is a direct failure mode.

The W3C identifies two code patterns that trigger this failure:

Pattern 1 — HTML attribute (legacy but still found in older codebases):

<p align="justify">
  Peter Piper picked a peck of pickled peppers
  A peck of pickled peppers Peter Piper picked
  If Peter Piper picked a peck of pickled peppers
  Wheres the peck of pickled peppers Peter Piper picked?
</p>

Pattern 2 — CSS property (the modern version of the same problem):

p { text-align: justify; }

<p>
  How much wood would a woodchuck chuck if a woodchuck could chuck wood?
  He would chuck, he would, as much as he could, and chuck as much wood
  As a woodchuck would if a woodchuck could chuck wood.
</p>

Both produce the same result: variable word spacing that the browser calculates line by line to force both margins flush. The visual effect is tidy. The readability effect is not.

Why This Matters

The W3C's description is precise: justified text creates "rivers of white" running vertically down a text block. These aren't metaphorical. They're literal visual artifacts — columns of whitespace that form when the browser expands inter-word gaps unevenly across adjacent lines.

For users with dyslexia, these rivers are genuinely disorienting. The eye tracks whitespace as a visual cue, and when that whitespace forms irregular vertical channels, it competes with the horizontal reading path. Users lose their place. They re-read lines. They abandon the content.

Users with cognitive disabilities face compounding difficulty: variable spacing disrupts the rhythm that supports reading fluency. Each line presents a slightly different spatial pattern, requiring the reader to re-calibrate rather than flow.

For low-vision users who rely on screen magnification, the problem scales up. Magnified justified text amplifies the spacing gaps, sometimes producing word spacing so extreme that individual words appear visually isolated from their sentence context.

This isn't a minor usability inconvenience. For a meaningful segment of users, justified text in long-form content is a barrier to comprehension — which is precisely why SC 1.4.8 exists.

The Fix

The corrected pattern is straightforward:

p { text-align: left; }

Or, in contexts where right-to-left languages are in play:

p { text-align: start; }

Using text-align: start is the more robust choice — it respects the document's writing direction rather than hardcoding left-alignment, which matters for internationalized content.

For teams inheriting legacy HTML with align="justify" attributes, the fix is removal:

<!-- Before -->
<p align="justify">...</p>
<!-- After -->
<p>...</p>

Then verify no CSS rule is re-applying justification downstream. Global stylesheet rules like * { text-align: justify; } or typography resets that set justification as a default are the most common source of widespread failures across a codebase.

Note that SC 1.4.8 is a Level AAA criterion. Organizations targeting WCAG 2.1 or 2.2 Level AA conformance aren't strictly required to meet it — but that framing obscures the practical reality. The "rivers of white" problem is real regardless of conformance level, and left-aligned text costs nothing to implement.

Applying This

From an operational capacity standpoint, this failure has an unusually favorable effort-to-impact ratio. Detection is automatable, remediation is trivial, and the fix introduces zero design regression for the vast majority of layouts.

In automated testing: Most accessibility linters and CI/CD tools won't flag text-align: justify by default — it's not in the standard WCAG AA ruleset that tools like axe-core prioritize. Teams need to add a custom rule or include it in manual review checklists. Our research on automated testing limitations documents exactly this gap: automated tools catch a fraction of real failures, and typography-related issues are systematically underrepresented.

In code review: Add text-align: justify to your team's PR review checklist. It takes thirty seconds to grep a stylesheet. If your design system has a typography scale, audit it once and lock the body text alignment to left or start at the token level — then the problem can't recur without overriding a deliberate system decision.

In design handoff: The pattern often originates in design tools. Figma, for instance, supports justified text alignment. If a designer sets body copy to justified in a mockup, developers implement what they see. Adding a typography guideline to your design system documentation — "body text: left-aligned, never justified" — catches this before it reaches code.

Quick audit step: Run a CSS search across your codebase for text-align:\s*justify. In most projects, this takes under a minute and surfaces every instance. Cross-reference with your HTML for align="justify" attributes. The full remediation for most codebases is a single afternoon.

Teams navigating multiple compliance frameworks simultaneously — WCAG, Section 508, EN 301 549 — will find that typography requirements like this one are handled differently across standards. Our research on multi-standard compliance addresses how organizations can prioritize without getting paralyzed by framework differences. For justified text specifically: fix it regardless of which standard you're targeting. The user impact doesn't change based on your conformance target.

CORS Perspective

Through an operational lens, F88 is a textbook "chop list" item — low skill required, high community impact, zero ongoing cost. The users most affected (people with dyslexia, cognitive disabilities, low vision) are precisely the populations most likely to be excluded from digital services when readability barriers compound. The risk profile is modest at Level AAA, but the strategic argument is straightforward: left-aligned text is a one-line CSS change that removes a documented barrier for a real segment of your audience. There's no reasonable case for justified body text in digital interfaces. The print-era aesthetic rationale doesn't survive contact with how browsers actually render variable-width word spacing — and it never did.