A visitor on the inquiry form at the fictional Northside Garden Care site is trying to read the small print under the date field. They spread two fingers on the phone screen, and the page does not enlarge. On another page, the same gesture works, but the label slides under a fixed bar and the Send request button is harder to reach.
Leave pinch-zoom (pinch to zoom) and text resizing on, and address any layout problems that appear when visitors enlarge the page. To check, open the live page on a real phone and try enlarging it. Record whether enlargement worked and whether the text and controls stayed usable. This checks enlargement, not the full layout.
The rest of the guide explains what that recommendation means, how to report what you find, and what to send the team if enlargement is blocked or no longer usable.
The situations below are fictional teaching inputs. They are not test results.
Leave Enlargement Under the Visitor’s Control
Leave pinch-zoom and text resizing available. Visitors may need the page larger than the designer chose, and they should be able to enlarge it without special tools.
WCAG 2.2 Success Criterion 1.4.4 Resize Text, at Level AA, requires that, 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 W3C explanation says this helps people with low vision increase text size so they can read it. It does not say that a site may satisfy the criterion by stopping visitors from enlarging the page. Do not read it as a requirement for a particular pinch-zoom factor.
Use what you find to decide what to ask for:
| Review Finding | Recommended Response |
|---|---|
| Visitors can enlarge the content and continue to read and use it | Keep that ability. Check important pages and form steps too. |
| Enlargement works, but text disappears, overlaps, or becomes unusable | Report the problem in the enlarged state. Do not solve it by turning enlargement off. |
| You cannot enlarge the page on a real phone | Record the device, browser, page, and what you tried. Ask the team to investigate restrictions. |
| The team wants to block zoom to protect the layout, or to stop a form from jumping when a field is focused | Keep visitor control. Investigate the underlying problem instead. |
| An interactive map has its own scripted zoom | Treat this as the narrow case discussed in a 2021 W3C note, not permission to block enlargement across the site. Visitors still need another way to enlarge the rest of the page. |
Pinch-Zoom, Text Resizing, and Preview Scaling Are Different
These three are easy to mix up, and they are not interchangeable checks.
Pinch-zoom is the visitor spreading two fingers to enlarge the page on a phone.
Text resizing is the visitor enlarging text through the browser’s zoom or text-size settings. That is the wording behind WCAG 1.4.4.
Preview scaling is a preview tool changing how large its preview appears on your screen. It is not a test of either of the above.
What Font Size Should You Use for a Mobile Website? covers the starting size for body text, and already notes that scaling a visual preview is not a text-resize accessibility test.
Online Website Previewer can help you see how large text and controls look in its phone view, which is 390 by 844 CSS pixels. It is a free tool and does not need an account. Paste the page address and press Preview. The tool’s own Zoom in and Zoom out controls belong to the preview. They are not evidence that a visitor can pinch-zoom the live site.
A visual preview also cannot show whether pinch-zoom is blocked. The preview changes the width, not the browser the site sees, and it does not copy iOS, Safari, or touch input. For the pinch-zoom question, open the live page on a real phone. What a Phone Preview Shows and What to Check on a Real Phone covers that limit in more detail.
Check Enlargement on a Real Phone
Start with the phone and browser you have. Record which they are. You do not need to have tested every visitor’s setup before you can send a finding.
Open the live page directly in the phone’s browser.
- Try enlarging ordinary content with a pinch gesture.
- Check whether important text stays readable and key controls stay usable after you enlarge.
- Using a safe test path, repeat the enlargement check on an important form or task step without submitting an inquiry or payment.
- If the browser offers zoom or text-size settings, try those as well. Where those controls live varies by browser, so use what that browser provides.
- Record the page, device, browser, settings or gestures you tried, and exactly what happened.
A successful pinch does not establish whether text resizing works. These observations can help the team investigate, but they do not replace an accessibility assessment.
If enlargement works on one phone and fails on another, record both. A successful check on one phone does not establish what happens on another, because browser behavior differs.
Safari on iOS, according to a WebKit post from February 2, 2017, ignores user-scalable, minimum-scale, and maximum-scale in Safari itself. The same post notes that some in-app web views could still allow a page to block zoom. Today’s behavior of any named in-app browser has not been verified here, so do not treat a Safari result as covering every app that opens a page on iOS.
Chrome’s current Help page describes a Force enable zoom setting for pages that prevent zoom. That means a page can still block zoom unless the visitor turns that setting on.
In a December 2020 test, Chrome, Edge, Firefox, and UC on Android obeyed user-scalable=no, while Samsung Internet allowed zoom by default. That is one dated test, not a current re-test, and not a claim about today’s default.
Report the Symptom, Not an Assumed Cause
A useful finding names what happened, not a guessed cause. You cannot see the page’s viewport tag from a visual review, and the browser decides whether a restriction actually works.
A note could say:
On the Northside Garden Care inquiry page at [page address], in [browser] on [device], I could not enlarge the content with a pinch gesture. Please investigate whether the page restricts enlargement, and why.
The useful finding is what happened on the phone. If the team will look at the page’s viewport settings, they may investigate identifiers such as user-scalable=no or a low maximum-scale. You do not need those names in the note for the finding to be useful, and this guide is not instructions for editing the tag.
If enlargement works but the enlarged page is unusable, say that instead:
On the same inquiry page, pinch-zoom worked in [browser] on [device], but the date-field label moved under the header and the Send request button was partly covered. Please fix the enlarged layout rather than turning zoom off.
Address the Reason for Blocking, Not the Visitor’s Workaround
Teams sometimes block zoom because the layout breaks when people enlarge it, or because a form jumps when a field is focused. Those are reasons to fix the layout, not to take control away from the visitor. Developers and designers have reported that, on iOS, focusing a small form field can make the page zoom in. That is a community report, not Apple documentation. Confirm it on a real phone if it is relevant. If a field is causing an unwanted zoom, the fix is the field, not a site-wide block.
A map’s own zoom controls do not establish that visitors can enlarge the rest of the page. A 2021 W3C note (HTML 5.3, a note rather than a standard) says authors should not suppress or limit resizing, because it causes accessibility and usability issues, and then names map applications, where custom zoom is handled in the page’s own scripts, as a possible appropriate case. Keep that case narrow. It is not permission to block zoom on the rest of the site, and it is not an exemption for games or other interactive pages. WCAG 2.2 Success Criterion 1.4.10 Reflow lists maps, diagrams, video, games, presentations, and data tables as examples that may need two-dimensional layout. That is a reflow exception, not permission to block zoom. If a map has its own zoom, visitors still need another way to enlarge the surrounding page, such as browser zoom or a text-size control.
Send a Finding the Team Can Act On
Include the page address, the device and browser you used, what you tried, and what happened. Say whether enlargement was blocked, or whether it worked and then became unusable. If behavior differs by browser, record that too. If you also noticed a layout issue in a visual preview, record that separately, with the preview size, so the two checks are not mixed together.
Ask the team to leave pinch-zoom and text resizing on, and to fix the reported symptom rather than turning enlargement off. If a map has its own zoom, that still does not mean the rest of the page can be blocked. The visitor should not have to hunt for a hidden browser setting to read the page.
