F32: When Spacing Breaks Words for Screen Reader Users

You've seen it in hero banners and headings: letters spaced out for visual drama. W e l c o m e. H E L L O. The design looks intentional. The accessibility failure is invisible — until a screen reader reads it aloud, one letter at a time, to someone who came to your site to find information.

This is WCAG Failure F32 (opens in new window), and it's one of those patterns that reveals how deeply visual assumptions are baked into web design. It's also a window into something larger: how the gap between what something looks like and what it communicates programmatically is the central challenge of digital accessibility.

The Failure

F32 documents a specific way that Success Criterion 1.3.2 Meaningful Sequence (opens in new window) gets violated: inserting white space characters — spaces, non-breaking spaces, tabs, line breaks — inside a word to create visual letter-spacing effects.

The official W3C document gives three concrete examples. The first two involve English:

<!-- Failure: spaces between letters -->
<h1>W e l c o m e</h1>
<!-- Failure: non-breaking spaces between letters -->
<h1>H&nbsp;E&nbsp;L&nbsp;L&nbsp;O</h1>

The third example is more consequential. In Japanese, the same technique applied to Han characters (kanji) doesn't just fragment a word — it changes its meaning entirely. The characters for "Tokyo" (東京), when separated by a space, get read as "Higashi Kyo" — two separate words with different meanings. The same failure pattern, applied to vertical text in a table header using line breaks, turns "東京都" (Tokyo-to) into "Higashi Kyo Miyako."

That's not a cosmetic problem. That's a comprehension failure.

The W3C document is careful to draw the line clearly: inserting white space between words for layout purposes is not a failure. Inserting white space within initialisms (like "A D A" or "W C A G") is also not a failure, because the spacing doesn't change the interpretation — it may actually help. The violation is specifically about fragmenting words that should be read as unified units.

Why This Matters

Screen readers parse text programmatically. When a word like "Welcome" becomes W e l c o m e in the DOM, most screen readers will read each letter individually: "W. E. L. C. O. M. E." The visual effect — elegant, spaced-out typography — becomes an auditory obstacle.

For a sighted user, context fills the gap. The letters are close together, the font is consistent, and the brain assembles the word automatically. For a screen reader user, the white space characters are real separators. The word doesn't exist in the document — only its constituent letters do.

Keyboard-only users aren't directly affected by this failure in the same way, but users with cognitive disabilities who rely on text-to-speech software outside of traditional screen readers face the same fragmentation. And as the Japanese kanji examples show, the stakes scale with linguistic complexity. This isn't just an English-language problem.

That intersection — language and disability — is worth pausing on. Most accessibility discussions treat these as separate domains. They aren't. A screen reader user who reads in Vietnamese, Japanese, or Arabic encounters compounded barriers when content is authored with only English-language assumptions in mind. Tools like idioma.chat (opens in new window) address this directly: they translate not just visible page text but the full accessibility layer — ARIA labels, alt text, form validation messages, and dynamically loaded content — so that the accessibility layer itself isn't English-only. The F32 failure pattern, applied to non-Latin scripts, illustrates exactly why that kind of infrastructure matters.

The Fix

The fix is straightforward. Use CSS for letter-spacing, not HTML white space.

<!-- Broken: white space inside the word -->
<h1>W e l c o m e</h1>
<!-- Fixed: CSS handles the visual spacing -->
<h1 style="letter-spacing: 0.25em;">Welcome</h1>

For the Japanese vertical text case, CSS writing modes handle vertical layout without fragmenting words:

th {
  writing-mode: vertical-rl;
  text-orientation: mixed;
}

The word stays intact in the DOM. The visual presentation is controlled by the stylesheet, not by characters inserted into the content. Screen readers read "Welcome" as a word. The meaningful sequence is preserved.

SC 1.3.2 requires that "if the sequence in which content is presented affects its meaning, a correct reading sequence can be programmatically determined." When white space fragments a word, the correct reading sequence cannot be programmatically determined — because the word, as a unit, no longer exists in the markup.

Applying This

This failure is detectable by automated tools in some cases, but not reliably. A pattern like W e l c o m e in a heading might be flagged, but   sequences inside words are harder to catch programmatically. Our research on automated vs. manual testing is relevant here: automated tools catch a fraction of real-world failures, and this is one that requires human review to catch consistently.

Practical steps for development teams:

• Code review checklist: Flag any heading or display text that contains spaces between individual characters. Search your codebase for   in heading elements.
• Design handoff: When a designer specifies "spaced out" typography, the implementation note should always be letter-spacing in CSS, never character-level spacing in HTML.
• CMS and rich text editors: These are high-risk environments. Content authors without technical backgrounds may manually space letters for visual effect. Training and content guidelines should explicitly address this.
• Multilingual content: Apply extra scrutiny to any content involving logographic scripts (Japanese, Chinese, Korean). The meaning-change risk is higher, and the failure may not be obvious to reviewers who don't read those languages.
• Templates and components: Audit hero sections, banners, and display headings — the places where visual letter-spacing effects are most common in design systems.

The compliance framework research we've published shows that organizations often struggle to connect specific technical failures to the people they affect. F32 is a useful teaching case: it's technically simple, the fix is straightforward, and the human impact — a word becoming a string of disconnected letters — is immediately understandable.

CORS Perspective

From a community lens, F32 sits at the intersection of two underexamined access gaps: screen reader users who encounter fragmented words in high-visibility content (headlines, banners, calls to action), and multilingual users whose languages carry higher semantic risk from this exact pattern. The operational fix is low-cost — CSS letter-spacing is a one-line change — which makes this a strong candidate for the "chop list" of quick wins that deliver real access improvements without significant resource investment. The risk is real: SC 1.3.2 is a Level A requirement, meaning this is a baseline obligation under Title II and Title III compliance frameworks, not an enhancement. Strategically, this failure is an effective internal training case because the before-and-after is easy to demonstrate: play the screen reader output of W e l c o m e versus Welcome in a team meeting, and the case for CSS-based typography makes itself.