Detector registry

Viewport Zoom Disabled: An Accessibility Signal to Catch Before Launch

A viewport meta tag that blocks pinch-zoom is a common accessibility gap. See how LaunchTrust detects disabled zoom and how to let users zoom to 200%.

Updated 2026-06-19viewport zoom disabled accessibilitySignals, not a verdict

A single line in your page <head> — the viewport meta tag — controls whether visitors can pinch to zoom or use browser zoom to enlarge your content. Many launch-day sites ship with zoom turned off, usually copied from a starter template or an old mobile tutorial that wanted to "stop the page jumping around." The side effect is that users who need larger text can't get it.

For a launching indie developer or store owner this is an easy, invisible gap: it throws no error, the page looks fine on your own screen, and you may not notice until a low-vision user — or an EU accessibility expectation — does. LaunchTrust looks for this so you can spot a blocked-zoom viewport before it ships.

What LaunchTrust checks

The zoom detector (a11y_viewport_zoom) inspects the raw HTML of the URL you scan, looking for a <meta name="viewport"> tag and reading two specific properties inside it:

  • user-scalable — if it is set to no, 0, or false, the page is asking browsers to block user zoom.
  • maximum-scale — if it caps zoom below 2 (that is, below 200%), the page is limiting how far a user can enlarge content.

How the result maps:

  • Detected — no zoom-blocking signal was found: there is no viewport tag, or the one present does not set user-scalable=no/0/false and does not cap maximum-scale below 2. This is the signal you want, reported as informational.
  • Not detected — a viewport tag is present and it disables or limits zoom. This is flagged at medium severity, referencing WCAG 1.4.4, which expects content to scale up to 200%.
  • Unable to determine — LaunchTrust could not retrieve or read the page HTML (for example, the URL was unreachable or returned no markup), so there is no viewport tag to inspect.

This is a positive signal, so the good outcome is "detected" — zoom left available — and the concern is a restrictive viewport, which surfaces as "not detected." The check is a focused text inspection of the viewport tag only. It reads user-scalable and maximum-scale; it does not render the page, measure whether your layout reflows at 200%, or catch zoom blocked by CSS, JavaScript touch handlers, or a touch-action rule instead of the meta tag. Treat "detected" as "the viewport tag does not block zoom," not as proof that every user can comfortably enlarge your UI.

Why it matters

Letting users zoom maps directly to recognized accessibility expectations:

  • WCAG 1.4.4 (Resize Text) is a Level AA success criterion that expects text to resize up to 200% without loss of content or functionality. A viewport that sets user-scalable=no or maximum-scale=1 works against it by preventing the zoom in the first place.
  • The European Accessibility Act pushes many private-sector digital products — including e-commerce sites and consumer apps — toward WCAG-aligned accessibility. Where the EAA applies, letting users scale content is commonly expected as part of conforming to the referenced standard. Whether the EAA covers your specific product, and on what timeline, depends on your situation and member-state implementation, so treat this as a commonly expected practice rather than a settled legal conclusion.

The practical impact is real: people enlarge a page to read small text, fill a form, or check a price, and on mobile user-scalable=no removes the pinch gesture they rely on. Some browsers ignore the directive, but you cannot count on that across every browser and assistive setup — the safe move is simply not to disable zoom.

A concrete example

A viewport that blocks zoom looks like this:

<meta name="viewport"
      content="width=device-width, initial-scale=1, maximum-scale=1, user-scalable=no">

Both maximum-scale=1 and user-scalable=no are the parts the detector flags. The accessible version simply drops them:

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

That is enough to honor pinch-zoom and browser zoom up to (and beyond) 200%. You almost never need maximum-scale or user-scalable on a normal content site or web app.

How to address it

  1. Find your viewport meta tag. It lives in the <head>index.html in a static site, or app/layout.tsx (Next.js), src/app.html (SvelteKit), or a shared base layout in a framework.
  2. Remove the zoom blockers. Delete user-scalable=no (or =0 / =false) and any maximum-scale below 2. The standard safe value is content="width=device-width, initial-scale=1".
  3. Check framework defaults. Some meta-frameworks and UI kits inject their own viewport tag, so confirm the rendered HTML, not just your source.
  4. Re-test the layout at 200%. Zoom your browser to 200% and confirm text stays readable and nothing is clipped; allowing zoom only helps if the page reflows.
  5. Avoid blocking zoom in code, too. If you stopped pinch gestures with JavaScript or a global touch-action: none, relax it for normal content.
  6. Re-scan to confirm the signal now reports as detected.

Check this in 30 seconds

Paste your URL into LaunchTrust's free scanner and it will report whether your viewport meta tag disables or limits zoom — alongside other accessibility signals like page language, page title, image alt text, and form labels. You get a plain list of detected / not-detected signals you can act on before you ship, with no account required to run a first scan.

FAQ

Does enabling zoom make my app accessible? No. It surfaces one accessibility signal. LaunchTrust reports whether your viewport tag blocks zoom; it does not certify your app, prove conformance, or provide legal advice. Allowing zoom is one expected basic among many — treat the result as a gap-finder, not a verdict.

Why is a "not detected" result the bad one here? This is a positive signal, so "detected" means the good thing — zoom left available — is present. "Not detected" means the scanner found a viewport tag that disables or limits zoom, which is the concern. The wording follows the signal's polarity, not a pass/fail grade.

Will the scanner catch zoom blocked by JavaScript or CSS? No. The detector reads only the user-scalable and maximum-scale properties of the viewport tag. It does not catch zoom prevented by touch-event handlers or touch-action CSS, so verify those yourself if your app intercepts gestures.

Is it ever okay to set maximum-scale or user-scalable? Rarely. A few canvas-style or map interfaces manage their own gestures, but most sites and web apps should leave zoom alone. If you must constrain it, confirm users can still reach a 200% view of your text.

Compliance aid, not legal advice. LaunchTrust reports signals, not a verdict or certification.