Mobile rendering checker

Without a viewport meta tag, a mobile browser assumes the page was designed for a desktop width and renders it at that width, then scales it down to fit.

The result is a page that technically fits and is unreadable: every element is present and everything is a fraction of its intended size.

That also invalidates every other mobile measurement. Text size, touch targets and content width are all measured against the viewport, and a scaled-down page reports them wrongly.

A viewport declaration that disables zooming is a separate defect: it takes away the mechanism someone with low vision relies on, and no layout justifies it.

So the check reads the declaration, and where it is missing or restrictive it says the downstream measurements cannot be trusted rather than reporting them anyway.

Content wider than the viewport forces sideways scrolling, which on a phone means text disappearing off the edge of the screen mid-sentence.

The cause is almost never the layout as a whole. It is one element: a table with fixed column widths, an image with an explicit pixel width, a pre-formatted code block, an embedded frame with a hard-coded size.

Which makes the fix narrow and the symptom broad — one element pushes the whole page wide, so every page using that component scrolls.

The check reports the overflow and, where it can, the element responsible, because the measurement without the culprit is a report that the page is broken somewhere.

A tap target needs enough area to be hit reliably by a finger, and enough spacing from its neighbours that the wrong one is not hit instead.

Spacing matters as much as size. Two adequately sized links immediately adjacent are still a pair of mis-taps waiting to happen, which is why the check reads both.

Text below a comfortable reading size on a phone is not a failure of any single criterion, and it is the difference between a page someone reads and a page someone zooms into and abandons.

Small text at a marginal contrast ratio compounds: each is borderline on its own and the combination is genuinely hard to read, which is why the contrast check reads the text size too.

Whether a collapsed menu actually opens. The markup shows a toggle; whether it responds, and whether it can be closed again, is behaviour.

Whether a sticky header consumes so much of a short viewport that little content remains — which depends on the rendered height on a specific screen.

Whether form inputs bring up the right keyboard, and whether the field stays visible when it does.

How the page behaves on a slow mobile connection, which is a different experience from the same page on a fast one at a narrow width.

So this check narrows what to test by hand. It does not replace opening the site on a phone, and any tool claiming otherwise is describing a capability it does not have.

`mobile.viewport` reads the viewport declaration. `mobile.content_width` and `mobile.horizontal_scrolling` measure overflow at a phone width.

`mobile.text_size` reports text below a comfortably readable size and `mobile.touch_targets` reports targets too small or too close together.

`mobile.menu` and `mobile.navigation` examine how navigation behaves at that width. `mobile.responsive` reports the responsive layout signals present.

`mobile.performance` reports the payload at mobile conditions and `mobile.core_web_vitals` the rendering measurements taken there, since a page can be laid out correctly and still be slow on a phone.

One viewport size is measured. Phones vary, and a layout that works at one narrow width can break at another.

Rendering is simulated at that width rather than run on a device. Font rendering, input handling and browser-specific behaviour all differ on real hardware.

Interaction is not exercised: menus are not opened, forms are not filled, and gestures are not performed.

Where the viewport declaration is missing or restrictive, the downstream measurements are reported as unreliable rather than presented as findings.