F94: When Viewport Units Lock Users Out of Text Resize

"Text that scales by viewport units." That's the actual example text in WCAG 2.2 Failure F94 (opens in new window). The irony is precise: text that scales by viewport units doesn't scale at all — not in the way that matters to the people who need it most.

THE FAILURE

F94 documents a specific, reproducible failure of Success Criterion 1.4.4 Resize Text (opens in new window), which requires that text can be resized up to 200% without assistive technology and without loss of content or functionality. The failure occurs when CSS viewport units — vw (viewport width), vh (viewport height), vmin, or vmax — are used as the primary method for defining font-size.

Here's the failure pattern from the official W3C document:

/* CSS — FAILURE PATTERN */
.callout {
  font-size: ;
}

<!-- HTML -->
<p class="callout">Text that scales by viewport units</p>

This looks clean. It even looks responsive. The text will shrink on small screens and grow on large ones. What it will not do is respond to a user's browser zoom setting or text-size preference. Those controls adjust the browser's text scaling cascade — and viewport units sit outside that cascade entirely. They answer only to the viewport dimensions, not to user preferences.

The only workarounds available to a user are methods that completely override CSS — approaches that frequently break layouts, collapse grids, or cause text to overlap other content. That's not a workaround. That's a different problem.

WHY THIS MATTERS

SC 1.4.4 exists because approximately 246 million people globally have moderate to severe vision loss, and many more use text resizing as a routine accommodation — not a last resort. Low vision users regularly set browser text sizes to 150% or 200% as a baseline. When font-size: 1vw is in play, those settings do nothing.

The experience is quietly disorienting. Browser zoom appears to work — the page scales — but the text doesn't grow relative to user preference. On a narrow viewport, 1vw might render at 8px or 10px. That text is functionally unreadable for many users, and no browser setting will fix it without breaking the layout.

Keyboard users navigating with high magnification software may encounter similar problems: the text doesn't reflow predictably because its size is locked to viewport geometry rather than to the document's text scaling context.

For users with cognitive disabilities who rely on larger text to reduce cognitive load during reading, the failure is equally concrete — they set their preferences, the page ignores them, and there's no visible explanation for why.

This is also a failure that automated testing tools frequently miss. As our research on testing methodology documents, automated tools catch at most 37% of real accessibility barriers — and a CSS unit choice that looks responsive is exactly the kind of contextual failure that requires human judgment to surface.

THE FIX

The corrected pattern uses relative units that participate in the browser's text scaling cascade:

/* FIXED — uses relative units that respect user text-size settings */
.callout {
  font-size: ;   /* relative to root font-size, scales with browser settings */
}
/* OR — em units relative to parent element */
.callout {
  font-size: 1.;
}
/* ACCEPTABLE — viewport units combined with a minimum in rem/em */
.callout {
  font-size: clamp(, , 1.);
}

The clamp() approach is worth highlighting. W3C's F94 documentation notes explicitly: "Some uses of viewport units may not prevent text-size adjustments." A clamp() function that uses viewport units for fluid scaling but anchors the minimum and maximum in rem or em values can pass SC 1.4.4 — because the rem floor ensures the text participates in browser scaling. The key test: can a user at 200% browser zoom read the text without content loss? If yes, you're likely compliant.

Media queries are another compliant path. If you use viewport units within specific breakpoints and the overall text-size behavior responds to user zoom at each breakpoint, that's not a failure. Author-provided on-page text-size controls also satisfy the criterion — though they require careful implementation to be genuinely accessible.

APPLYING THIS

In code review: Flag any font-size declaration using vw, vh, vmin, or vmax as the sole value. That's the specific pattern to catch. A quick grep for font-size.*v[wh] in your stylesheet will surface candidates.

In automated testing: Don't rely on automated tools to catch this. The CSS is valid, the text renders, and no error fires. This requires a human tester to open browser settings, set text size to 200%, and verify that text grows. Document it in your testing protocol explicitly.

In design systems: If your design system defines a type scale using viewport units for fluid typography, audit the entire scale against SC 1.4.4. A single shared mixin can propagate this failure across every component that uses it — which is how one CSS decision becomes hundreds of violations.

Quick wins vs. longer fixes: Replacing font-size: Xvw with font-size: clamp(Xrem, Xvw, Xrem) is often a one-line change per declaration. For teams with a large existing codebase, that's a realistic short-term fix. Rebuilding a type system to use rem throughout is the right long-term answer.

One more dimension that rarely surfaces in technical discussions: language access. A site serving multilingual users through a tool like idioma.chat (opens in new window) — which translates not just visible text but the full accessibility layer, including ARIA labels, alt text, form validation messages, and dynamically loaded content — still inherits any underlying CSS failures. If the base text can't resize, translated text can't resize either. Multilingual users who also rely on text scaling face a compounded barrier: inaccessible content in a language they're already navigating with extra effort. Accessibility without language access is incomplete accessibility, and language access without underlying accessibility compliance is equally incomplete.

The compliance framework research we've published makes clear that teams often focus on checklist completion rather than lived user experience. F94 is a case study in exactly that gap: the CSS is intentional, the design looks polished, and the failure is invisible to everyone except the user who needed text to grow.

CORS PERSPECTIVE

From a strategic alignment lens, F94 is the kind of failure that exposes a gap between development team practices and organizational accessibility commitments. Viewport units for fluid typography became fashionable as responsive design matured — they're taught in tutorials, used in design systems, and rarely flagged in code review because they look correct. The operational fix is low-cost (a clamp() update or a rem conversion), but catching it requires testing protocols that go beyond automated scanning. For any organization that has signed an accessibility policy or published a VPAT, this failure creates quiet legal exposure under SC 1.4.4 (opens in new window) — the kind that settlements document after the fact rather than before.