WCAG 1.4.4 Resize Text requires that, except for captions and images of text, all visible text can be enlarged to 200% without losing content or functionality. When a low-vision user doubles the text size with their browser, nothing should clip, overlap, or vanish. The text — including button and form labels — must stay fully readable and usable.

What 1.4.4 actually requires

The official success criterion is short: “Except for captions and images of text, text can be resized without assistive technology up to 200 percent without loss of content or functionality.” See the W3C Understanding document for the normative wording.

Two phrases carry the weight. “Without assistive technology” means the user relies only on tools built into the browser — its zoom control or its text-size setting — not a separate screen magnifier. “Without loss of content or functionality” means that after enlarging, every word is still on screen, every control still works, and nothing is cut off, covered, or pushed out of reach.

There are two exemptions: captions and images of text. An image pixelates when scaled and can’t be reflowed, so WCAG handles those separately (and 1.4.5 Images of Text discourages images of text in the first place). Everything else — body copy, headings, menu items, labels, error messages — is in scope.

Who it affects

1.4.4 exists for people with low vision who don’t use a screen reader and don’t need full magnification software, but who do need bigger type to read comfortably. That is a large group: the CDC estimates that roughly 7 million Americans have a vision impairment, including about 1 million who are blind, per its Fast Facts: Vision Loss. Broader measures put the blind-and-low-vision population at over 8 million people in 2023, according to the CDC’s modeled prevalence estimates.

These users routinely bump their browser to 150% or 200%. They include older adults whose near vision has declined, people with conditions like macular degeneration or diabetic retinopathy, and anyone reading on a small or distant screen. Unlike screen reader users, they consume your visual layout — so a design that shatters at 200% locks them out even though the content is technically “there.”

Concrete failures and how to fix them

The W3C lists specific documented failures for 1.4.4. Here are the ones we see most during remediation.

Failure F94 — sizing text in viewport units

Setting font-size in viewport units (vw, vh) ties text size to the window, not to the user’s text setting. The browser’s text-resize control then does nothing.

/* Fails F94: text scales with the window, ignores user text settings */
h1 { font-size: 5vw; }

/* Fix: relative units respond to the user's preference */
h1 { font-size: 2.5rem; }

Use rem and em so type scales from the root font size the user controls. (Modern fluid type with clamp() is acceptable only if a rem-based middle value still grows when the user resizes.)

Failure F69 — clipped or obscured content

Fixed-height containers and overflow: hidden crop text the moment it grows. A 40px-tall button with a one-line label looks fine at 100% and chops the descenders at 200%.

/* Fails F69: fixed height clips enlarged text */
.btn { height: 40px; overflow: hidden; }

/* Fix: let the box grow with its content */
.btn { min-height: 2.5rem; height: auto; padding: 0.5em 1em; }

Replace fixed pixel heights with min-height and padding in em, so boxes expand as their text grows.

Failure F80 — form controls that don’t resize

Text-based form fields and buttons that keep a fixed size while surrounding text doubles. The label enlarges, the input doesn’t, and the form becomes unusable. Size inputs, selects, and buttons in relative units too, and never lock them to a pixel width that can’t hold larger characters.

Absolute positioning and overlap

Layouts built with absolute pixel coordinates collapse at 200% because enlarged text in one element crashes into a neighbor pinned in place. Prefer flow layout, Flexbox, or Grid so elements push each other apart instead of overlapping. This is the single most common structural cause of 200% breakage we find on older custom sites.

How to test for 1.4.4

You can check this in a couple of minutes per template, no special software needed.

  1. Set a known baseline. Confirm the browser is at 100% zoom.
  2. Zoom to 200%. In Chrome, Edge, or Firefox press Ctrl/Cmd and + until the indicator reads 200%. Full-page zoom is a legitimate path to meeting 1.4.4 per the W3C.
  3. Read every region. Scan headers, nav, body, sidebars, footers, buttons, and form fields. Look for clipped words, text spilling out of boxes, elements overlapping, and content pushed off-screen or behind other content.
  4. Operate the page. Open menus, submit a form, trigger an error message, and dismiss a modal — all at 200%. Functionality must survive, not just appearance.
  5. Try browser text-only resizing too. Firefox’s “Zoom Text Only” option enlarges type without scaling the layout, which exposes vw-based text and fixed-height boxes that full-page zoom can hide.
  6. Check small-screen breakpoints. Resize the window narrow first, then zoom — responsive sites can pass at desktop width but clip inside a mobile breakpoint.

Automated scanners catch some signals (like vw font sizing) but cannot judge whether a real word is clipped or two elements visually collide. That always needs a human eye, which is why we pair tooling with manual review in every accessibility audit.

Why it matters legally

Web accessibility litigation remains heavy. According to UsableNet’s tracker, plaintiffs filed 4,187 digital accessibility lawsuits in 2024 (see the UsableNet ADA lawsuit tracker). Most complaints are pleaded against WCAG 2.1 Level AA — the level that contains 1.4.4 — and under the Department of Justice’s 2024 Title II rule, WCAG 2.1 AA is the explicit technical standard for state and local government sites (ADA.gov fact sheet).

Resize failures are easy for a tester to document: zoom to 200%, screenshot the clipped checkout button, attach it to the demand letter. Low-vision plaintiffs frequently describe exactly this — text and controls they cannot enlarge enough to use. If you have already received correspondence, see Got a Demand Letter?.

This is general information, not legal advice. For your specific situation, consult a qualified accessibility attorney.

How Curbcut fixes resize failures

We are deliberately anti-overlay. An overlay widget’s “increase font size” button doesn’t make your underlying design conformant — it bolts a second, often-broken control onto a layout that still clips at the browser’s own 200% zoom, and judges and testers see through it (why overlays don’t work).

Real conformance with 1.4.4 is a CSS and markup job: converting px type and viewport units to rem/em, replacing fixed heights with flexible boxes, and rebuilding absolutely positioned layouts into flow, Flexbox, or Grid so nothing overlaps when text grows. Our remediation team does this by hand, template by template, and verifies the result at 200% across breakpoints.

Want to know where your text breaks? Run a free scan and we’ll show you the exact elements that clip, overlap, or refuse to resize — then fix them for you.