Why user-scalable=no Breaks WCAG 1.4.4 Resize Text — and How to Fix It

Open a product page on a phone, try to pinch-zoom in on a photo or a line of fine-print shipping text, and nothing happens. The page just sits there, locked at whatever size it loaded at. On a lot of e-commerce sites, that’s not a browser limitation — it’s one line in the theme’s <head>, written on purpose, years ago, to stop a tap on a small button from accidentally triggering a zoom gesture. It also happens to fail a Level AA WCAG success criterion outright, and — unlike most of the failures covered on this site — it’s one an automated scanner catches every time.

Quick answer: WCAG SC 1.4.4 Resize Text (Level AA) requires that text can be resized up to 200% without losing content or functionality. A <meta name="viewport"> tag with user-scalable=no, or a maximum-scale value below 2, disables the browser’s pinch-zoom and double-tap-zoom gestures on mobile — the only resize mechanism most phone shoppers have — and fails the criterion directly. The fix is almost never a redesign: it’s deleting or editing one attribute in one <meta> tag.

This article covers technical accessibility practice, not legal advice — it explains what WCAG 2.1 AA requires here and how to meet it, not whether a specific site carries legal risk.

What SC 1.4.4 actually requires

The Understanding document’s normative text: “Except for captions and images of text, text can be resized without assistive technology up to 200 percent without loss of content or functionality.” The Intent section explains who this protects — people with mild-to-moderate low vision who get by with ordinary browser zoom rather than dedicated screen-magnification software, plus anyone who simply prefers larger text on a small phone screen in bright light or at arm’s length.

200% isn’t an arbitrary number. The W3C’s own reasoning is that it’s “a reasonable accommodation that can support a wide range of designs and layouts” and lines up with the minimum magnification level built into older hardware magnifiers — low enough to be achievable on virtually any layout, high enough to meaningfully help.

On desktop, this maps to browser zoom (Ctrl/Cmd and +), which virtually no site blocks. On mobile, the equivalent mechanism is the pinch-zoom and double-tap-zoom gestures built into every mobile browser — and that’s exactly the mechanism a restrictive viewport meta tag switches off.

The one line that causes it

A standard, accessible viewport tag looks like this:

<meta name="viewport" content="width=device-width, initial-scale=1">

The failure shows up when user-scalable=no or a low maximum-scale value gets added to that same tag:

<!-- Fails SC 1.4.4 — blocks zoom entirely -->
<meta name="viewport" content="width=device-width, initial-scale=1, user-scalable=no">

<!-- Also fails — technically "scalable," but capped below the 200% floor -->
<meta name="viewport" content="width=device-width, initial-scale=1, maximum-scale=1.0">

This isn’t a hypothetical. It’s a long-running pattern in mobile web development, usually added for one of two reasons: to stop an accidental double-tap zoom when a shopper taps a small “Add to Cart” button or color swatch, or as a leftover from treating the site more like a native app than a web page. Some older or heavily customized Shopify and WooCommerce themes still ship a restrictive viewport tag in their base template for exactly this reason — it solves a minor annoyance for most shoppers by removing a capability some shoppers depend on entirely.

How to actually test and fix it

Testing it takes ten seconds. Open the site on an actual phone (or a browser’s device-emulation mode) and try to pinch-zoom on a product photo or a block of body text. If nothing happens, check the page source for <meta name="viewport"> and look at its content attribute.

The fix, per the exact pass/fail criteria below, is almost always a one-line edit:

• Remove user-scalable=no entirely, or set it to user-scalable=yes (the default if the attribute is omitted at all).
• If a maximum-scale is set, raise it to at least 2 (200%) — or remove it, which allows the browser’s own default maximum.

<!-- Fixed -->
<meta name="viewport" content="width=device-width, initial-scale=1">

No layout work, no component changes, no design review — this is markup-only, and it’s usually the fastest fix on this entire site’s list of covered issues.

The exact pass/fail rule, from the source that defines it

The W3C ACT Rule b4f0c3, “Meta viewport allows for zoom,” maps directly to SC 1.4.4 and spells out the applicability and the pass/fail line precisely — this is the load-bearing citation for the fix instructions above, not a paraphrase:

Applies to: the content attribute of any <meta name="viewport"> element that includes a user-scalable or maximum-scale property.

Fails if:

• user-scalable is set to no — example: <meta name="viewport" content="user-scalable=no">
• maximum-scale is set below 2 — example: <meta name="viewport" content="maximum-scale=1.5">

Passes if:

• user-scalable is set to yes (or omitted)
• maximum-scale is 2 or higher
• An invalid maximum-scale value (e.g., a negative number) is present, since browsers drop invalid values and fall back to allowing zoom

That last case is worth knowing: a typo in the value doesn’t make the page more broken — browsers are forgiving of malformed viewport directives and default to allowing zoom when they can’t parse a restriction, so a garbled maximum-scale is accidentally harmless.

Where this is different from every other article on this site

Most of what Quietramp covers is a gap between what an automated scanner reports and what a real screen-reader or keyboard user actually hits — the entire reason manual review is the product, not just a scan. This one inverts that. Checked axe-core’s own rule-descriptions.md directly: the meta-viewport rule — tagged wcag2aa and wcag144, impact moderate — flags exactly this pattern, every time, out of the box, no manual pass required. There’s also a related best-practice rule, meta-viewport-large, which checks that the allowed maximum isn’t just technically over the 200% floor but generously above it.

So the real story here isn’t “a scanner can’t see this.” It’s that a scanner has been flagging it the entire time, on every automated run, and it still ships — because a moderate-impact finding in a 40-item scan report is easy to deprioritize behind anything that looks more urgent, and because whoever added the line in the first place framed it as an intentional design choice rather than a bug. That’s a real risk of relying on raw scanner output without someone triaging what actually matters: a finding that’s correct, clearly flagged, and still gets ignored because nothing forced a second look.

FAQ

Does this affect desktop, or just mobile? Mainly mobile. Desktop browsers don’t honor viewport-meta zoom restrictions the same way — Ctrl/Cmd-+ zoom keeps working regardless of what the tag says. The failure is specific to mobile browsers’ pinch and double-tap gestures, which is exactly where a disproportionate share of e-commerce traffic now happens.

We added user-scalable=no so taps on small buttons don’t accidentally trigger zoom. Isn’t that a legitimate reason? It’s a real problem (double-tap-to-zoom occasionally misfiring on a small tap target), but the fix for that problem is making tap targets bigger — see WCAG SC 2.5.8 Target Size — not removing a shopper’s ability to zoom the whole page. One accessibility fix shouldn’t come at the cost of failing a different one.

Will raising maximum-scale or removing user-scalable=no break my layout? No — this tag only controls what the browser’s native zoom is allowed to do. It doesn’t change your CSS, your breakpoints, or how your page renders by default. The only behavior change is that shoppers who want to zoom in now can.

If axe-core already catches this, why does it still show up on real sites? That’s the point of this article — being flagged isn’t the same as being fixed. A scan report with dozens of findings makes it easy for a moderate-impact, one-line issue to sit untriaged indefinitely, especially when someone added the restriction on purpose and nobody has gone back to question it since.

Get the flagged findings someone actually triaged

An automated scan will catch this one — the harder part is making sure it’s the kind of finding that actually gets fixed instead of sitting in a report nobody prioritizes. Quietramp’s $890 audits include a manual walkthrough that separates what’s genuinely urgent from what’s easy to defer, with concrete fix instructions for each. See a real sample report or check pricing — $890 one-time, $99/month for ongoing re-checks after fixes ship.

---

This is educational content about technical accessibility practice, not legal advice. Meeting WCAG 2.1 AA does not constitute a legal compliance determination under the ADA or any other standard — consult qualified counsel for legal risk questions.

This article was drafted with AI assistance and reviewed by a person for accuracy before publication.