Your Site Probably Blocks Pinch-to-Zoom on Mobile. That Is a Lawsuit Risk.

Open your website on a phone right now. Take two fingers and try to pinch-to-zoom on the body text. If the page resists, snaps back, or simply ignores you, your site has a problem that almost every accessibility consultant flags inside the first ten minutes of an audit. It is one of the easiest accessibility failures to ship by accident and one of the easiest to fix once a developer looks at it. It is also one of the failures that turns up most often in demand letters from US plaintiffs’ firms in 2026, because every iPhone and Android device since 2018 makes it trivial for a customer to demonstrate the issue on video.

This article is written for non-developers — founders, marketing managers, ecommerce owners, in-house counsel reviewing an audit report. You do not need to read HTML to act on any of this. You need to understand what the bug is, why it matters legally, how to confirm whether your own site has it, and exactly what to ask your developer to change.

What is actually broken

Every modern website has a tiny piece of HTML in its head section called the viewport meta tag. It tells the phone browser how to size and scale the page. Most websites copied a version of it from a Stack Overflow post or a starter template years ago. A surprisingly large fraction of those starter templates contain two short instructions that, taken together, prevent the user from zooming the page: maximum-scale=1.0 and user-scalable=no.

The reason developers used those instructions historically was vanity. In the early days of responsive design, some developers were worried that users would accidentally zoom and ruin their carefully crafted layouts. Apple and Google have both said, in their developer documentation and in their accessibility guidelines, that disabling user zoom is almost always wrong. But the bad copy-paste lives on. The WebAIM Million report has consistently found that roughly one in three home pages of the top million sites still ships with user-scalable disabled in 2026, even after a decade of public guidance against it.

The result is that a customer with low vision who needs to zoom a phone screen to 200 percent or 300 percent to read your text simply cannot. They can pinch and pull at the screen, and the browser snaps it back to the original size. They cannot read your menu, they cannot fill in your form, they cannot complete their order. They give up and go somewhere else. Sometimes they file a complaint.

The Web Content Accessibility Guidelines criterion this fails

The bug fails two specific WCAG success criteria. The first is 1.4.4 Resize Text at Level AA, which requires that text can be resized up to 200 percent without loss of content or functionality. The second is 1.4.10 Reflow, also Level AA, which requires that content can reflow at 320 CSS pixels wide and a 400 percent zoom on desktop. On mobile, the practical equivalent is that pinch-to-zoom must work.

WCAG Level AA is the standard that every major accessibility law in 2026 points to. The US Department of Justice Title II rule that became enforceable in April 2026 references WCAG 2.1 AA. The European Accessibility Act, in force since June 2025, points to WCAG 2.1 AA through the harmonised standard EN 301 549. The UK Public Sector Bodies Accessibility Regulations, the Section 508 update for US federal contractors, AODA in Ontario, and the Australian Disability Discrimination Act case law all converge on the same baseline.

Failing 1.4.4 and 1.4.10 means your site fails the law in every one of those jurisdictions. None of this is legal advice — consult a qualified attorney for your jurisdiction — but the pattern in 2026 demand letters is consistent: plaintiffs’ firms include a screenshot of your site, a screenshot of the viewport tag with user-scalable=no highlighted, and a short paragraph explaining the WCAG criterion. It is a copy-paste accessibility violation, which is exactly why it is so common in copy-paste demand letters.

How to check your own site in two minutes

There are three quick ways. None of them require developer tools.

First, the gesture test. Open your site on an iPhone or Android phone. Try to pinch-to-zoom on a paragraph of body text. If the page resists, snaps back, or refuses to scale, your site has the bug. Try a few different pages. Sometimes the home page is fine but the checkout page is broken, because the checkout was built later by a different developer with a different template.

Second, the iOS Accessibility Inspector test. On an iPhone, open Settings, then Accessibility, then Zoom, and turn Zoom on. Open your site. Try to zoom the rendered page. iOS will sometimes still let users zoom even when a site has disabled it, depending on the version, so this test is less reliable than the gesture test. It is a good sanity check for the worst cases.

Third, the source-code test. In Chrome or Edge on a desktop computer, open your site. Right-click anywhere on the page and choose View Page Source. In the long block of HTML that opens, press Ctrl-F (or Cmd-F on a Mac) and search for the word “viewport.” You will land on a line that looks something like this:

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

If you see maximum-scale=1.0 or user-scalable=no (or both), your site has the bug. The correct version of the line is shorter:

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

You do not need to memorise the syntax. You need to be able to spot the offending words and point at them. That is enough to start a useful conversation with whoever maintains your site.

What an actual demand letter looks like

The pattern in 2026 looks like this. A plaintiff’s firm trains a paralegal to scan the websites of small businesses in a target industry — often hospitality, professional services, ecommerce, or healthcare — with a checklist. The paralegal runs an automated scan, captures the viewport tag, records a short video on a phone trying to zoom, and sends a demand letter offering to settle for a fixed fee (commonly between 10,000 and 25,000 US dollars depending on jurisdiction).

The letter rarely names every accessibility issue on the site. The viewport bug appears in nearly all of them, because it is so easy to demonstrate. The letter cites WCAG 1.4.4 and 1.4.10, points at the line of HTML, and includes the screenshot. The settlement offer is structured to be lower than the cost of defending the case, which is the entire point of the model. Most small businesses pay.

Three things matter for prevention. First, do not ship the offending viewport tag in the first place. Second, run your published accessibility statement carefully, because a site that publishes a statement claiming WCAG 2.1 AA conformance while failing 1.4.4 is at higher risk of an unfair-practices claim than a site that quietly fails. Third, document a remediation backlog with dates, because demand-letter triage in 2026 increasingly responds to evidence of active remediation work.

What to ask your developer to do

The fix takes about three minutes for a competent developer in any modern stack. You will be asked one question in return: do you want pinch-to-zoom enabled on every page, or do you have a specific page (a 3D product configurator, a custom drawing tool, a kiosk-mode page) where disabled zoom is intentional? In practice the answer is almost always “every page.”

The specific instruction to give your developer is short. Open the relevant template — in WordPress this is usually header.php; in Shopify it is the theme.liquid file; in Squarespace and Wix it is a single setting in the custom-header advanced section; in React, Vue, Angular, or other JavaScript stacks it is in the application shell. Replace the existing viewport meta tag with this exact line:

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

Do not include maximum-scale and do not include user-scalable. That is the whole change.

After the fix is shipped, repeat the gesture test on the live site to confirm. Then add the test to your release checklist so that the bug does not come back the next time a new template is installed or a junior developer copies the wrong starter project.

Common objections, briefly answered

“But our designer prefers the locked-down look.” That is a design preference; WCAG conformance is a legal requirement. The two conflict here, and the legal requirement wins. A designer who cannot accommodate user zoom in 2026 needs to update their training.

“Our analytics show very few users zoom.” This is sometimes true and almost always misleading. Many low-vision users have already left your site because they could not use it; they do not appear in your analytics. WebAIM survey data has consistently found that customers with low vision are roughly proportional to the general population (around 7 percent of adults have a moderate or worse vision impairment), but their representation in your data is suppressed by the very bug you are measuring.

“We have a custom mobile app and we disabled zoom there.” That is a separate question with separate WCAG criteria. Native mobile apps fall under WCAG 2.1 AA via different mechanisms (and Section 508 references them explicitly), so the same logic broadly applies. Native app text scaling is usually handled by following the operating system’s dynamic type or accessibility-text-size settings rather than by pinch-to-zoom. Consult your mobile-app developer separately about that.

“We tried to enable zoom and it broke our layout.” That is a design problem, not a zoom problem. Modern responsive layouts handle zoom gracefully. If yours does not, your layout has a deeper issue that will also fail WCAG 1.4.10 Reflow on desktop. Fixing the viewport tag is step one; fixing the layout to handle scaling without horizontal scroll or content clipping is step two.

Why this is worth doing this week

The barrier between “this is broken” and “this is fixed” is one line of HTML. The barrier between “we did not know” and “we did know and ignored it” is reading this article. The barrier between “we settled a demand letter for 18,000 dollars” and “we did not get a demand letter in the first place” is usually a remediation backlog that includes the line item “fix the viewport meta tag, sitewide.”

For the cost of one short conversation with your developer, you remove one of the most common entries on a 2026 demand-letter checklist. There are dozens of other accessibility issues to fix on most sites, but this is the cheapest, fastest, and most legally exposed one. Start here.

We’re building a simple accessibility checker for non-developers — no DevTools, no jargon. Join our waitlist to get early access.