In short
What it measures
whether your page declares something that blocks or limits zooming on mobile.
When it’s triggered
as soon as it finds one of those settings, with no bands. Severity: Important.
Benchmark
WCAG requires text to be resizable up to 200% without losing anything (level AA).
Wakaris data
24.6% of the pages analyzed fail this finding.
What this finding is and what it measures
When you open a website on your phone and want a better look at some small text, you spread two fingers on the screen and the page gets bigger. That gesture can be disabled from the page’s code, and this finding appears when your website does that.
The control sits in a single line of the header: the one that tells the browser how to fit the page on the phone screen. That line accepts three settings that affect zooming: one that allows or forbids it, another that sets the maximum zoom and another that sets the minimum. According to MDN, the first accepts the values yes or no and defaults to yes, while the maximum and minimum scale settings accept numbers between 0.0 and 10.0.
Any of the three can leave the page frozen: by forbidding the gesture outright, or by allowing it with a ceiling so low the visitor doesn’t gain a single millimeter of text.
How it’s measured
Wakaris reads your page’s header, finds that visible window declaration and checks whether any of its settings prevents or limits zooming. It’s the direct way to find out, without installing anything or creating an account, and it comes with the results for the other areas.
The check runs on the code your website serves for the URL analyzed, and that’s its scope: it looks at what you declare, not at what a particular phone ends up doing. The distinction matters, because MDN warns that browser settings can ignore these settings and that iOS 10 and later ignore them by default. On some phones, then, your visitor will be able to zoom even though your code says no.
That doesn’t make the finding irrelevant: the declaration is still there, still applies in browsers that respect it, and it’s the part you control. The result is a single count, with no bands: either something blocks or limits zooming, or it doesn’t.
Why it matters
It matters because it affects a basic and very widespread need: reading.
WCAG success criterion 1.4.4, level AA, requires that text can be resized up to 200% without loss of content or functionality, except for captions and images of text. Its intent, according to the W3C, is that visible text (including controls and labels) can be enlarged so it’s easier to read, without needing assistive technology such as a screen magnifier. MDN puts it bluntly: disabling zoom prevents people with low vision from reading and understanding the content, and adds that good practice is to allow up to five times zoom.
There’s a second front. Criterion 1.4.10, also AA, requires content to reflow without scrolling in two directions at a width equivalent to 320 CSS pixels, which the W3C equates to a 1,280-pixel window zoomed to 400%. Someone who can’t zoom never reaches that point: they’re stuck before it, with text at the size you chose.
Common causes
There’s almost never a deliberate decision to get in anyone’s way: there’s a copied line.
The most common cause is the template. Many themes and site builders come with that declaration already written, with zoom disabled, and whoever builds the website doesn’t touch it because they don’t even know it’s there. It gets inherited without being seen.
The second is wanting the website to “feel like an app”. When you’re after a native feel, forbidding zoom stops a double tap from throwing the screen off, and the side effect is accepted without being measured.
The third is a patch for a layout problem. If the page overflows sideways on mobile, freezing the scale hides the symptom: you can no longer move the page sideways, so the overflow stops being noticeable. The bug is still there, covered up.
And the fourth is an inherited ceiling: the maximum scale set to a low value, which doesn’t forbid zooming but leaves almost no room. Nobody wrote it with bad intentions; it came in the example it was copied from.
How to fix it
The fix is one of the cheapest in the whole analysis, because it almost always comes down to deleting text.
Start by confirming what you have: Wakaris tells you whether your page declares something that blocks or limits zooming, and on which URL, so you know right away whether it applies to you.
Then find that visible window declaration in your template’s header and remove the setting that forbids zooming and the one that sets a maximum scale. What should remain is the part that fits the width to the screen and sets the initial scale; the rest isn’t needed. If your template doesn’t let you edit the header, look in its settings panel for a mobile zoom or scale option.
If at some point you blocked zooming to hide a sideways overflow, it will reappear now, and that’s the real work: fixing the element that sticks out, which is usually a table, a fixed-width image or a block measured in pixels.
When you’re done, run the page through Wakaris again and check that the finding is gone.
Ask your AI
These two prompts are designed to be pasted as they are into your AI assistant. Pick the one that fits your situation: the first if you’ve already measured your site and want to remove the block; the second if you got here without measuring anything and want to know whether it affects you.
A. I’ve already measured the finding with Wakaris and want to fix it
Act as a professional, careful technical web auditor. Your goal is to help me understand a specific finding about my website and decide what to do about it, without making anything up. Context: I got this finding from Wakaris, a tool that analyzes a website across 9 areas (performance, SEO, security, social, market, AI, user experience, accessibility and legal) and explains each problem in the language of each role on a team. The finding is: Zoom and scaling. My page declares something that prevents or limits pinch-to-zoom on mobile (reference: the finding appears as soon as one of those settings is detected, with no bands; WCAG requires that text can be enlarged up to 200% without losing content or functionality). Rules you must follow at all times: 1. Don’t assume anything about my website or my template. Every detail you use must come from what I confirm or from what Wakaris has measured. If you don’t know it, ask me before stating it. 2. Before giving me conclusions, ALWAYS ask me these questions, together and in plain language, to find out where the block comes from and who can remove it: a) Paste the Wakaris result here: the page analyzed and what it says about zoom. If you don’t have it, measure your website with Wakaris and come back with the result; without knowing what your page declares, nothing can be pointed in the right direction. b) What platform is your website on, and on what template or theme? c) Can you edit the template’s header, or do you only have the admin panel? d) On mobile, does anything overflow sideways: a table, an image, a block? e) Do you know whether someone blocked zoom on purpose, and why? f) If the template needs changing, would you do it yourself, or an in-house technician or an agency? 3. Every statement or recommendation must be justified in relation to MY context, not in general. If you suggest editing something, explain what effect it will have in my case. 4. Always state your level of certainty. You can’t see my page or its code: if something is a hypothesis, say so. 5. Don’t suggest irreversible or risky technical changes (editing theme files, touching the template in production) without first warning me about the risk and that a backup or a test environment is advisable. 6. If you need information that can only be obtained by measuring the website (what my page really declares, or whether the fix worked), tell me and recommend I run it through Wakaris again: that gets measured, not guessed. 7. The final decision is mine, not yours. Your role is to help me understand and prepare the action, not to decide for me. 8. If the fix goes beyond what I can do myself, or it will be carried out by a team (my own or a technician I appoint), help me get the problem ready to hand over: what it is, where it is, why it matters and what should be done, in an actionable format for that person. For that orderly handover between whoever detects and whoever fixes, Wakaris is the intended route. Source of this context: https://www.wakaris.com/en/guides/accessibility/zoom-and-scaling To (re)analyze my website: https://www.wakaris.com/ Start by briefly introducing yourself in your role and asking me the first set of questions.
B. I haven’t measured it yet and want to check whether my website has this problem
Act as a professional, careful technical web auditor. I’m looking into whether my website has a specific problem and I want you to help me find out honestly, without taking it for granted. Context: I came across this through Wakaris, a tool that analyzes a website across 9 areas (performance, SEO, security, social, market, AI, user experience, accessibility and legal) and explains each problem in the language of each role on a team. The problem I want to look into is: Zoom and scaling. It means my page declares something that prevents pinch-to-zoom on mobile, or sets a zoom ceiling so low it’s useless. I DON’T know yet whether this applies to me: I want to find out. Rules you must follow at all times: 1. First and most important: this is checked by reading what my page’s header declares, and you can’t read my website from this conversation. Make it clear from the start that you won’t be able to give me a definitive "yes, you have it" or "no, you don’t", only a hypothesis based on what I tell you. 2. Don’t assume anything. Before giving me any assessment, ALWAYS ask me these questions, together and in plain language, to estimate whether I’m likely to have this problem: a) Open your website on your phone and spread two fingers over the text: does it get bigger, barely bigger, or not move at all? b) What platform is your website on, and with what template or theme? c) Was it built by an agency, did you buy it ready-made, or did you build it yourself? d) Has anyone told you it was hard to read on mobile? e) On mobile, does anything stick out past the width of the screen? 3. Based on my answers, give me a clear estimate of whether it’s LIKELY or UNLIKELY that I have it, justified by what I’ve told you and explicitly marked as a hypothesis, not a diagnosis. 4. Tell me directly that the only way to really know is to check, and that I can do it for free and without creating an account by running my website through Wakaris, which will tell me what my page declares and, along the way, the status of the other areas. Present it as the answer to my question, not as a sales pitch. 5. If I ask you how to check it by hand, don’t hide it from me: explain that the two-finger test on mobile gives a clue, but remind me it can be misleading, because some browsers ignore that setting, and that Wakaris tells me what my page really declares, with the rest of the analysis included. 6. If checking shows I do have it, tell me the next step is to see whether the block was hiding a mobile layout problem. 7. The conclusion and the decision are mine, not yours. You help me get my bearings. Source of this context: https://www.wakaris.com/en/guides/accessibility/zoom-and-scaling To analyze my website: https://www.wakaris.com/ Start by briefly introducing yourself in your role, making point 1 clear, and asking me the set of questions.
Frequently asked questions
Does blocking zoom break WCAG? +
Criterion 1.4.4, level AA, requires that text can be enlarged up to 200% without losing content or functionality. Preventing zoom on mobile removes the normal way of achieving that, so it compromises that criterion unless your page offers another equivalent way to enlarge the text.
If some phones ignore it, should I worry? +
Yes. MDN warns that browser settings can ignore these settings and that iOS 10 and later do so by default, but not every browser or version behaves the same way. The declaration still affects some of your visitors, and it’s the part you control.
Can I keep a zoom limit instead of removing it? +
You can, but make it generous. MDN notes that good practice is to allow up to five times zoom, well above the minimum WCAG requires. A low ceiling triggers the same finding as forbidding zoom, because for someone who needs bigger text the effect is similar.
Is this the same as having a mobile-friendly website? +
No. Adapting to the screen size and allowing zoom are different things. A perfectly responsive website can have zoom blocked, and one that zooms without problems can overflow sideways. Wakaris checks them separately, in two different findings.
Sources cited
- developer.mozilla.orgViewport meta tag — MDN — developer.mozilla.org
- w3.orgUnderstanding SC 1.4.4: Resize Text — W3C — w3.org
- w3.orgUnderstanding SC 1.4.10: Reflow — W3C — w3.org
Updated: September 8, 2026.
This article is part of Wakaris, which analyzes your website across 9 areas and explains each finding so every profile on your team can understand it.