Viewport zoom is disabled

What is this issue?

The page’s <meta name="viewport"> tag content attribute includes user-scalable=no, or sets maximum-scale to a value too low to allow meaningful zoom (commonly 1, meaning no zoom headroom above the page’s default scale at all). Either setting instructs the mobile browser to disable or severely restrict the user’s ability to pinch-zoom the page.

This is a page-level, device-wide restriction: it doesn’t affect one element or one piece of content, it removes an entire input mechanism (pinch-to-zoom) for the whole page, for every visitor on a touch device, regardless of whether they need it.

Why does this matter?

Low vision: reduced but not absent vision, which may involve using screen magnification or high contrast, distinct from blindness. It is one of the most common reasons someone needs to enlarge on-screen content, and pinch-to-zoom is the primary mechanism mobile browsers provide for that. It doesn’t require any special software or setting to be configured in advance; it’s built into the browser and available the instant a user needs it, which is exactly what makes disabling it so damaging.

Site owners typically add user-scalable=no to prevent an accidental double-tap zoom from disrupting a carefully designed layout, treating it as a cosmetic safeguard. But that “safeguard” removes the single most important accessibility control a mobile browser provides by default, with no equivalent replacement; there’s no other standard way for a user to say “make this bigger” once pinch-zoom is gone.

Who is affected?

• Low vision users: lose the ability to enlarge text and interface elements to a size they can read, with no fallback mechanism once browser-level pinch-to-zoom is disabled.
• Motor impairments: also rely on zoom to enlarge small tap targets to a size they can hit reliably with imprecise pointer control, so disabling zoom compounds difficulty targeting buttons and links on top of any readability issue.

What users experience

Grace has low vision and relies on pinch-to-zoom to read text on her phone, since her prescribed reading size is well above what most sites render by default. She opens a restaurant’s mobile site to check the menu, and the page has user-scalable=no set in its viewport tag. When she tries her usual two-finger pinch gesture to enlarge the text, nothing happens: the page stays locked at its default size, small enough that she can’t read the menu items at all. She closes the site and calls the restaurant instead, since there’s no way to make the page usable on her phone.

How do I fix it?

Remove user-scalable=no and any restrictive maximum-scale value from the viewport meta tag’s content attribute. This works because it hands zoom control back to the browser’s native pinch-to-zoom behavior, which every mobile browser already implements correctly without any page-level code needed; the fix is entirely subtractive, removing a restriction rather than adding new functionality.

If a specific interactive element genuinely misbehaves when the page is zoomed (an unusual case, since most responsive layouts handle zoom correctly without special handling), fix that element’s own CSS or JavaScript directly, rather than disabling zoom for the entire page to work around one component’s bug.

Code Examples

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

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

Removing user-scalable=no is the entire fix; width=device-width and initial-scale=1 are both left in place, since they control the page’s default responsive layout and aren’t themselves accessibility problems. Only the explicit zoom restriction needs to go.

Common Mistakes

Mistake: “Disabling zoom prevents an ugly accidental double-tap zoom, so it’s a UX improvement.” An occasional accidental zoom is a minor, self-correcting annoyance a sighted user taps to undo in a second. Permanently disabling zoom for every visitor to prevent that rare annoyance removes a critical accessibility tool for every low-vision user on the page, every time, for a much smaller benefit to a much larger cost.

Mistake: “Our design is fully responsive, so users don’t need to zoom at all.” Responsive design adjusts layout for different screen sizes; it doesn’t guarantee every user’s individually needed text size matches what the responsive breakpoints render by default. A low-vision user’s required reading size is often well above what any “normal” responsive design targets, which is exactly why zoom needs to remain available as a user-controlled option on top of a responsive layout.

Mistake: “This only affects mobile users, so it’s a lower priority than desktop issues.” Mobile-only doesn’t mean low-impact: mobile is frequently the primary or only device many users have, and mobile browsers are where a significant share of low-vision users specifically rely on pinch-to-zoom, since desktop zoom shortcuts work differently and aren’t blocked by this same meta tag setting.

How RedFlag Detects This

Automated: axe-core rule, runs on every scan. RedFlag calls axe-core’s meta-viewport rule as part of every scan, restricted to the WCAG 2.0/2.1/2.2 A and AA rule set. The rule parses the <meta name="viewport"> tag’s content attribute and flags a violation when it finds user-scalable=no, or a maximum-scale value that doesn’t leave meaningful zoom headroom above the page’s default scale.

False negative: this rule only inspects the viewport meta tag itself; a page that restricts zoom through some other mechanism, such as JavaScript intercepting touch or gesture events, is outside this check’s scope entirely and won’t be flagged even though the user experience is identical. False positive: none typical for this check, since parsing the tag’s content attribute for these specific directives is a binary condition axe-core evaluates reliably. Manual step: on a touch device or browser touch emulation, physically attempt to pinch-zoom the page and confirm it responds, since that’s the only way to catch a non-meta-tag zoom restriction this rule can’t see.

Manual Testing

1. Open the page on an actual mobile device, or use a browser’s device emulation mode with touch enabled.
2. Attempt to pinch-zoom the page using a two-finger gesture (or the emulator’s zoom control).
3. Confirm the page scales up in response and the enlarged content remains readable and usable.
4. Check the viewport meta tag’s content attribute directly in developer tools for user-scalable=no or a restrictive maximum-scale.
5. If pinch-zoom does nothing, or the tag contains either restriction, the check fails.

Related WCAG Success Criteria

1.4.4 Resize Text: Text must be resizable up to 200% without loss of content or functionality, without requiring assistive technology. Blocking browser zoom directly prevents a user from reaching that 200% resize at all through the browser’s own native mechanism, which is why disabling zoom is one of the most direct possible failures of this criterion.

Related Issues

CSS locks content to a single orientation shares this rule’s territory of a page-level, viewport-wide restriction that removes a mobile user’s control over how they view the page: one locks rotation, the other locks zoom.

Interactive element is too small to tap accurately compounds directly with a disabled zoom: a small tap target is hard enough to hit already, and a user who could normally zoom in to make it easier loses that option entirely when zoom is blocked.

Text does not have enough colour contrast and Text does not meet enhanced AAA contrast requirements address the same low-vision audience through a different mechanism: contrast helps someone perceive text at its rendered size, while this rule is about controlling that size in the first place.

References

• W3C Understanding 1.4.4: Resize Text
• W3C Technique G142: Using a technology that has commonly-available user agents that support zoom
• MDN: Using the viewport meta tag