F69: When Text Resize Breaks Your Layout

Two interfaces, same content. One scales gracefully when a user bumps their browser font size to 200%. The other clips the text mid-sentence, buries a button under a fixed-height container, or spills paragraph text over the next section. Both were probably reviewed in QA. Only one actually works.

That gap is exactly what WCAG 2.2 Failure F69 (opens in new window) documents: a specific, testable pattern where resizing visually rendered text up to 200 percent causes content to be clipped, truncated, or obscured. This isn't a vague accessibility principle — it's a named failure condition tied directly to Success Criterion 1.4.4 Resize Text (opens in new window), and it shows up constantly in production code.

The Failure

F69 describes what happens when a layout can't accommodate larger text because the developer locked down container dimensions or overflow behavior. The W3C identifies three primary causes:

• Setting overflow: hidden on a fixed-height container
• Using absolutely positioned content that doesn't reflow
• Creating popups or tooltips too small to hold their content at larger font sizes

The W3C's own examples are instructive. Here's the first pattern — a container with fixed pixel dimensions and no overflow handling:

<div style="font-size:100%; width:120px; height:100px; border: thin solid gray;">
  Now is the time for all good men to come to the aid of their country.
</div>
<p>The quick brown fox jumps over the lazy dog.</p>

At default size, this looks fine. Resize to 200%, and the text spills out of the box, bleeding directly over the paragraph below it. The second example adds overflow: hidden to "fix" the bleed — but now the text is truncated. The user loses content entirely. Both patterns fail SC 1.4.4.

The W3C working group has noted significant confusion about how to test F69 correctly. Their guidance is explicit: if content passes SC 1.4.4 using any listed sufficient technique, the failure does not apply — even if the markup pattern looks similar. Testing requires actually resizing text and observing behavior, not just scanning for overflow: hidden in a stylesheet.

Why This Matters

For a compliance officer reviewing a VPAT or accessibility conformance report, F69 is a concrete signal — not a theoretical concern. The population affected by SC 1.4.4 is substantial: people with low vision who use browser zoom or OS-level font scaling, older adults managing age-related vision changes, and users on high-DPI displays where default sizes render small.

A screen reader user navigating with a refreshable braille display may not encounter this failure directly, but a low-vision user who relies on both magnification and screen reader output will. They're zoomed in and listening. If the text is clipped, the visual and audio experiences diverge — the screen reader may read content the user cannot see, or vice versa, creating genuine cognitive disorientation.

For keyboard-only users, the stakes get higher when the obscured content is a control. A button pushed outside its container boundary by reflowed text, or a form field hidden under a fixed-height overflow region, isn't just an inconvenience — it's a complete blocker. The user cannot activate what they cannot reach.

This is also a pattern that automated testing tools frequently miss. As our research on automated vs. manual testing documents, automated tools catch at most 37% of real accessibility failures. F69 is a prime example of why: detecting it requires rendering the page, resizing text, and observing layout behavior — a dynamic, visual check that static analysis can't replicate.

The Fix

The corrected pattern removes fixed height constraints and lets the container expand with its content:

<!-- Failing pattern: fixed height clips or overflows text at 200% -->
<div style="font-size:100%; width:120px; height:100px; overflow: hidden; border: thin solid gray;">
  Now is the time for all good men to come to the aid of their country.
</div>
<!-- Passing pattern: container height is flexible -->
<div style="font-size:100%; width:120px; border: thin solid gray;">
  Now is the time for all good men to come to the aid of their country.
</div>

Removing height: 100px and overflow: hidden allows the container to grow as text scales. The layout shifts — adjacent content moves down — but nothing is lost. That's the correct behavior.

For more complex layouts, the approach depends on the structure:

• Fixed-height cards or tiles: Use min-height instead of height, so the container can expand beyond the baseline but won't collapse below it
• Absolutely positioned overlays or tooltips: Switch to relative positioning where possible, or use JavaScript to recalculate dimensions after font size changes
• Truncated text with ellipsis: Acceptable for decorative or supplementary text, but never for essential content — always provide a mechanism to access the full text

/* Instead of this */
.card {
  height: ;
  overflow: hidden;
}
/* Use this */
.card {
  min-height: ;
}

Applying This

For development teams, the practical catch-point is code review. Any PR that introduces height (not min-height) on a text-containing element, combined with overflow: hidden, should trigger a resize test before merge. That's a specific, low-cost review rule.

For QA, the manual test is straightforward: use browser zoom (not page zoom — text-only zoom in Firefox, or OS-level font scaling) to reach 200%, then scroll through the page looking for clipped, truncated, or overlapping text. Document any instance where content becomes inaccessible.

Design systems are the leverage point here. If your component library's card, modal, tooltip, and dropdown components are all built with flexible height by default, F69 failures become structurally harder to introduce. Fix it once in the system; prevent it everywhere downstream.

One dimension that rarely enters these conversations: language. A fixed-height English container may pass at 200% because English text is relatively compact. Translate that same container into German, Finnish, or Vietnamese — languages with longer words or different character metrics — and the same layout that passed in English may clip in translation. Idioma.chat (opens in new window) addresses this directly: it translates not just visible text but the full accessibility layer, including ARIA labels, alt text, and form validation messages, which means translated content inherits the same semantic structure. But the underlying layout still has to be flexible enough to hold it. A translated ARIA label on a clipped button is still a clipped button.

The intersection of language access and disability access is underexplored. Title II and Title III obligations apply regardless of the language a user reads in, and SC 1.4.4 doesn't have a carve-out for non-English content.

CORS Perspective

F69 sits at the intersection of operational capacity and strategic alignment. From a Strategic Alignment lens, this is exactly the failure pattern that creates downstream legal exposure without ever appearing in an automated scan — which means organizations relying solely on automated tools are accumulating risk they can't see. The fix is inexpensive at the component level but expensive if it requires auditing every fixed-height container across a large codebase. The strategic play is design system investment: build flexible containers once, enforce them through component governance, and eliminate the failure class rather than chasing individual instances. As our research on compliance framework paralysis shows, organizations that address accessibility at the system level consistently outperform those managing it case by case.