What does a mobile accessibility checker check?

Whether a phone user can do the three things WCAG guarantees them on a small screen: make the text bigger (SC 1.4.4 Resize Text), use the page in either orientation (SC 1.3.4 Orientation), and read it without scrolling sideways (SC 1.4.10 Reflow). This one reads your viewport meta for user-scalable=no and maximum-scale, and reads your inline CSS and up to eight linked stylesheets for touch-action rules that block a pinch, orientation media queries that rotate or hide the page, and fixed desktop widths on html or body.

Is user-scalable=no an accessibility violation?

Yes. It tells the browser to ignore a pinch, so a reader with low vision cannot enlarge the text, which fails SC 1.4.4 Resize Text at level AA. axe-core, the engine behind most automated accessibility testing, reports it as a critical issue. Chrome and Samsung Internet on Android obey it. iPhone Safari has ignored it since iOS 10, which is why teams that test on iPhones rarely find it themselves.

Is maximum-scale=1 a WCAG failure?

Yes. maximum-scale=1 means the page can never be zoomed past its starting size, which switches zoom off as completely as user-scalable=no. SC 1.4.4 asks for text to be resizable to 200%, so any maximum-scale below 2 fails. A value of 2 or more passes; below 5 this checker still mentions it, because that is where the phone's own limit would otherwise sit.

Why did our developer add maximum-scale=1 in the first place?

Almost always to stop iPhone Safari zooming into a form field when it is tapped. Safari does that whenever a field's text is smaller than 16px, and maximum-scale=1 was the popular way to stop it. It no longer works on iOS — Safari ignores it — and on Android it takes zoom away from everyone. The real fix is one CSS rule: give inputs, selects and textareas a font size of at least 16px on small screens. We found and fixed that exact zoom on this site's own forms.

What should my viewport meta tag say?

and nothing else. viewport-fit=cover is fine if you design for the notch. Leave out user-scalable, maximum-scale and minimum-scale.

What is an orientation lock and how is it detected?

A page that only works in portrait or only in landscape. On the web it is usually a CSS media query like @media (orientation: landscape) { body { display: none } } paired with a "please rotate your device" message, or a rule that rotates the whole page 90 degrees. SC 1.3.4 at level AA forbids it unless one orientation is essential. People with a phone or tablet mounted to a wheelchair or bed frame cannot turn it. This checker reports a lock only when the page root — html, body, main or the app's root element — is rotated a quarter turn or hidden inside an orientation query. A query that just rearranges the layout is what media queries are for, and is not reported.

Can CSS stop a phone from zooming even with a correct viewport?

Yes. touch-action: none (or pan-x / pan-y without pinch-zoom) on html, body or every element hands all two-finger gestures to the page's scripts, so pinching does nothing however the viewport is written. It is usually left over from a carousel or swipe library scoped too wide. touch-action: manipulation keeps zoom and removes the tap delay, and is never reported.

Does this test reflow at 320px or tap target size?

No, and it does not pretend to. Whether a layout collapses into one column at 320px, whether text overlaps at 200%, and whether a tap target is 24 by 24 pixels are questions about the rendered page. This reader sees the HTML and CSS before scripts run. The free scan renders each page in a real browser before testing it.

It says our stylesheets couldn't be read.

Some servers refuse requests that don't come from a browser, and some pages link dozens of stylesheets; we read at most eight per check. The viewport verdict does not depend on CSS and stands either way. The CSS half — touch-action and orientation locks — is only as complete as the sheets we could read, and the result says how many that was.

Does this store my domain?

No. The check is an HTTP GET of the page you name and of its stylesheets, run inside the request and discarded when it answers. There is no account, no email field and no row written anywhere. If you go on to run the free scan, that one does keep a report so you can come back to it, which is the whole point of a report.

Can a phone zoom your website?

Enter your domain. We read your viewport meta and your stylesheets and tell you whether a phone user can pinch to make the text bigger, turn the phone on its side, and read the page at the phone's own width — and, where they can't, the one line that stops them and what to replace it with.

Free, instant, no signup and no card. Nothing is stored.

Free, instant, no signup and no card. We read the HTML your server sends for that one page and up to eight of its stylesheets, and check a phone can zoom it, rotate it and read it at its own width. Nothing is stored.

The line nobody on the team has seen fail

Open the source of almost any site and the fourth or fifth line is its viewport meta. On a lot of sites it reads width=device-width, initial-scale=1, maximum-scale=1, user-scalable=no. Those last two instructions tell a phone to ignore a pinch. A reader with low vision — the person pinch-zoom exists for — is left with the text at whatever size the designer picked.

It survives because it is invisible to the people who would fix it. iPhone Safari stopped obeying both instructions in iOS 10, so a team that tests on iPhones pinches, sees the page zoom, and moves on. Chrome and Samsung Internet on Android still obey them. When we read 83 home pages of retailers, banks, airlines, agencies and restaurant chains for this tool, four national brands had switched zoom off this way — and every one of them zooms fine on an iPhone.

The reason it was added is usually a good one. iPhone Safari zooms into any form field whose text is smaller than 16px, and the zoom jumps the layout under the reader's thumb. Pinning maximum-scale=1 was the popular fix. We hit the same zoom on this site's own forms — and fixed it the other way, with a 16px font size on small screens, because an accessibility company cannot ship a zoom lock. That is the fix for yours too.

What this checker refuses to call a failure

A free checker that a stranger runs on their own site has exactly one way to be useless, and it is to cry wolf. So four things are called failures here — zoom switched off, zoom capped below 2x, a pinch blocked in CSS, and the page rotated or hidden in one orientation — each under SC 1.4.4 or SC 1.3.4 at level AA. Everything else is reported, argued, and kept out of the count.

maximum-scale=2 passes. SC 1.4.4 asks for 200%. A cap at 2x meets it, so it is review, not a failure — even though we would still take it out.

touch-action: manipulation is fine. It removes the tap delay and keeps pinch-zoom. A touch-action: none on a carousel, a map or a body.modal-open state class is also not reported — only the whole page counts.

An orientation query is not a lock. Rearranging a layout in landscape is what (orientation: landscape) is for. Only rotating or hiding the page root is reported, and a rotation inside @keyframes is an animation, not a lock.

A desktop width is not a phone width. A min-width on body inside a (min-width: …) query, one that a phone-sized rule narrows again, and anything in a print stylesheet are all left alone.

We read 83 home pages before shipping it. The one false alarm that turned up — a Next.js page whose framework data repeats the viewport meta inside a script, which is an echo, not a rewrite — is now a fixture, and so is every rule above. The checker is re-tested against all of them on every deploy.

What the checker looks for

Four failures, then the review and verify items — real problems that WCAG does not forbid outright, or that cannot be proved from source, reported separately and never counted as violations.

Pinch-to-zoom switched offFailureSC 1.4.4 Resize Text (Level AA): The viewport meta says `user-scalable=no` (or `0`), which tells a phone's browser to ignore a pinch. A reader with low vision cannot make the text bigger, and on a phone pinch-zoom is the only way to. Chrome and Samsung Internet on Android honour the instruction. iPhone Safari has ignored it since iOS 10, which is why a team that tests on iPhones never sees the problem.; The fix: Delete `user-scalable=no` from the viewport meta. If it was added to stop iOS zooming into a form field when it is tapped, the real fix is a 16px font size on inputs, selects and textareas — iOS only zooms into text smaller than that.
Zoom capped below 200%FailureSC 1.4.4 Resize Text (Level AA): The viewport meta sets `maximum-scale` below 2, so a pinch stops before the text is twice its size — which is the minimum SC 1.4.4 asks for. `maximum-scale=1` is the common one and it switches zoom off completely. It is almost always there to stop iOS zooming into a small form field, and it does that by taking zoom away from everyone on Android.; The fix: Remove `maximum-scale` (and `minimum-scale` if it matches it). To stop the iOS focus-zoom, give text fields a font size of at least 16px on small screens instead.
The page's CSS blocks a pinchFailureSC 1.4.4 Resize Text (Level AA): `touch-action` on html, body or every element (`*`) is set to a value with no `pinch-zoom` in it — `none`, `pan-x`, `pan-y` or both. The browser then hands every two-finger gesture on the page to the page's own scripts instead of zooming, so the viewport meta can be perfect and zoom still does nothing. It is usually left over from a carousel, a drawing canvas or a swipe library that was scoped too wide.; The fix: Scope `touch-action` to the element that needs it (the carousel, the map, the canvas), not the whole page. If a page-wide rule is needed to remove the tap delay, `touch-action: manipulation` does that and keeps pinch-zoom.
Locked to one orientationFailureSC 1.3.4 Orientation (Level AA): Inside an `(orientation: portrait)` or `(orientation: landscape)` media query, the page's root element is rotated a quarter turn or hidden — the CSS way of saying "turn your phone back". Someone with a phone or tablet mounted to a wheelchair or a bed frame cannot turn it, and a person who holds it sideways to get bigger text loses the page entirely. Content may only be restricted to one orientation when that is essential, like a piano app or a bank cheque.; The fix: Delete the rule, and let the layout reflow in both orientations. If the landscape layout is cramped, fix the layout: a smaller header, a single column, no fixed heights.
No viewport meta — the page renders at desktop widthReviewSC 1.4.10 Reflow (Level AA), in practice: There is no `<meta name="viewport">` in the served HTML, so a phone lays the page out about 980px wide and shrinks the whole thing to fit its screen — every word at a third of its size, with the reader zooming and scrolling sideways to read a line. It is review rather than a failure because a viewport can be added by a script after this read, and because SC 1.4.10 is judged on the rendered page.; The fix: Add `<meta name="viewport" content="width=device-width, initial-scale=1">` to the <head> — with nothing else in it. Then check the layout at 320px wide.
Viewport pinned to a fixed pixel widthReviewSC 1.4.10 Reflow (Level AA), in practice: The viewport meta sets `width` to a number of pixels instead of `device-width`, so every phone lays the page out at that width and shrinks it to fit. On a 390px phone, `width=1024` renders every word at 38% of its size. The page cannot reflow into one column, which is what SC 1.4.10 asks for at 320px.; The fix: Use `width=device-width, initial-scale=1`, and give the layout a mobile breakpoint.
html or body has a fixed desktop widthReviewSC 1.4.10 Reflow (Level AA): A stylesheet gives html or body a `min-width` or `width` in pixels wider than any phone, outside a desktop-only media query. The page then scrolls sideways on a phone, and at 400% zoom on a laptop — the other half of SC 1.4.10 — every line has to be read by scrolling left and right. It is review because a later rule this reader did not see can override it.; The fix: Remove the fixed width, or move it inside `@media (min-width: …)` so it only applies where there is room for it.
"Please rotate your device" messageReviewSC 1.3.4 Orientation (Level AA), where it blocks the page: The page carries text asking the reader to rotate their device, or saying it is best viewed one way up. That message is almost always shown by a media query that hides the page in the other orientation — which is the failure SC 1.3.4 describes. It is review because this reader could not see the rule that shows it.; The fix: Delete the message and the rule that shows it, and let the page reflow in both orientations.
Zoom limited below 5xReviewSC 1.4.4 passes at 2x; this is best practice: The viewport meta caps zoom at 2x or more, which meets SC 1.4.4 — but below 5x, the level a phone's browser would otherwise allow. For someone who needs 300% or 400% to read, that cap is where the page stops being usable. It is not a WCAG failure, which is why it is not counted as one.; The fix: Remove `maximum-scale`, or set it to 5 or more.
A script rewrites the viewport to switch zoom offVerify: An inline script writes `maximum-scale=1` or `user-scalable=no` into the viewport. The usual reason is the iOS form-field zoom: pin the zoom while a field has focus, put it back on blur. If it only runs while a field is focused on iOS — which ignores it anyway — it does little harm. If it runs on load, zoom is off for everyone on Android, and this reader cannot tell which.; The fix: Delete the script and give text fields a 16px font size on small screens, which stops the iOS zoom without touching the viewport at all.
text-size-adjust: noneVerify: `-webkit-text-size-adjust: none` on the page stops iOS enlarging text when the phone is turned sideways. On current browsers that is all it does. Older desktop WebKit also refused the reader's own text-zoom setting under it, and some reset stylesheets still carry it from then. `100%` does the same job without the side effect.; The fix: Change `none` to `100%`.

The two-minute phone test

The checker reads source. This is the part only a person can do, and it needs one Android phone — an iPhone will hide the most common failure from you.

Pinch to 200%. The text should get twice as big. If nothing happens, the page has switched zoom off.
Turn the phone sideways. The page should reflow to the new width. A blank screen or a "please rotate" message is an orientation lock.
Scroll down without scrolling sideways. Every line of text should fit the screen. Sideways scrolling to read a sentence is a reflow failure.
Turn on large text and finish a task. Set the phone's font size to its largest and check out, book or submit a form. If a button is cut off or text overlaps, that is the finding that matters most, whatever any tool says.

Common questions

What does a mobile accessibility checker check?: Whether a phone user can do the three things WCAG guarantees them on a small screen: make the text bigger (SC 1.4.4 Resize Text), use the page in either orientation (SC 1.3.4 Orientation), and read it without scrolling sideways (SC 1.4.10 Reflow). This one reads your viewport meta for user-scalable=no and maximum-scale, and reads your inline CSS and up to eight linked stylesheets for touch-action rules that block a pinch, orientation media queries that rotate or hide the page, and fixed desktop widths on html or body.
Is user-scalable=no an accessibility violation?: Yes. It tells the browser to ignore a pinch, so a reader with low vision cannot enlarge the text, which fails SC 1.4.4 Resize Text at level AA. axe-core, the engine behind most automated accessibility testing, reports it as a critical issue. Chrome and Samsung Internet on Android obey it. iPhone Safari has ignored it since iOS 10, which is why teams that test on iPhones rarely find it themselves.
Is maximum-scale=1 a WCAG failure?: Yes. maximum-scale=1 means the page can never be zoomed past its starting size, which switches zoom off as completely as user-scalable=no. SC 1.4.4 asks for text to be resizable to 200%, so any maximum-scale below 2 fails. A value of 2 or more passes; below 5 this checker still mentions it, because that is where the phone's own limit would otherwise sit.
Why did our developer add maximum-scale=1 in the first place?: Almost always to stop iPhone Safari zooming into a form field when it is tapped. Safari does that whenever a field's text is smaller than 16px, and maximum-scale=1 was the popular way to stop it. It no longer works on iOS — Safari ignores it — and on Android it takes zoom away from everyone. The real fix is one CSS rule: give inputs, selects and textareas a font size of at least 16px on small screens. We found and fixed that exact zoom on this site's own forms.
What should my viewport meta tag say?: <meta name="viewport" content="width=device-width, initial-scale=1"> and nothing else. viewport-fit=cover is fine if you design for the notch. Leave out user-scalable, maximum-scale and minimum-scale.
What is an orientation lock and how is it detected?: A page that only works in portrait or only in landscape. On the web it is usually a CSS media query like @media (orientation: landscape) { body { display: none } } paired with a "please rotate your device" message, or a rule that rotates the whole page 90 degrees. SC 1.3.4 at level AA forbids it unless one orientation is essential. People with a phone or tablet mounted to a wheelchair or bed frame cannot turn it. This checker reports a lock only when the page root — html, body, main or the app's root element — is rotated a quarter turn or hidden inside an orientation query. A query that just rearranges the layout is what media queries are for, and is not reported.
Can CSS stop a phone from zooming even with a correct viewport?: Yes. touch-action: none (or pan-x / pan-y without pinch-zoom) on html, body or every element hands all two-finger gestures to the page's scripts, so pinching does nothing however the viewport is written. It is usually left over from a carousel or swipe library scoped too wide. touch-action: manipulation keeps zoom and removes the tap delay, and is never reported.
Does this test reflow at 320px or tap target size?: No, and it does not pretend to. Whether a layout collapses into one column at 320px, whether text overlaps at 200%, and whether a tap target is 24 by 24 pixels are questions about the rendered page. This reader sees the HTML and CSS before scripts run. The free scan renders each page in a real browser before testing it.
It says our stylesheets couldn't be read.: Some servers refuse requests that don't come from a browser, and some pages link dozens of stylesheets; we read at most eight per check. The viewport verdict does not depend on CSS and stands either way. The CSS half — touch-action and orientation locks — is only as complete as the sheets we could read, and the result says how many that was.
Does this store my domain?: No. The check is an HTTP GET of the page you name and of its stylesheets, run inside the request and discarded when it answers. There is no account, no email field and no row written anywhere. If you go on to run the free scan, that one does keep a report so you can come back to it, which is the whole point of a report.