Mobile layout

What we measure at 375 pixels wide

The mobile checks are not an opinion about your design. A headless browser loads the page, resizes the window to four widths, and measures what the layout actually does at each one.

What a phone does to a layout that a desktop does not

A layout that breaks at phone width rarely looks broken to the person who owns it, because they see it on a laptop. The visitor sees something else: a page they have to drag sideways to read, a button their thumb cannot land on, or a price set in text too small to read without pinching. Any one of those ends the visit, and nothing in your analytics will tell you which one it was.

We do not know how much of your traffic arrives on a phone, and the report does not guess — that figure is in your own analytics, not in anything a site sends to a visitor. What the engine can tell you is where the layout gives way, and at exactly which width. In the ranking that orders the report, horizontal scrolling and undersized tap targets are classed as things that stop a visitor completing the action the page exists for, which is the second-heaviest class the engine uses.

Measured in a real browser, not read off the source

Reading the HTML tells you almost nothing about whether a layout holds. The engine does record how many @media rules appear, and how many container, row, col-, grid, flex and responsive class names are present, but it raises no finding from either count. A page can carry a well-known responsive framework and still push a table two hundred pixels past the edge of the screen, and a page with no framework at all can be flawless.

So the responsive checks run in a headless Chromium browser through Playwright. The page is loaded, given time to settle, and then the window is resized and the layout measured directly: the overflow figure is the document's full scroll width minus the width of the window, in pixels, read from the live page rather than inferred from markup.

Four widths, and what each one is for

The page is measured at 375, 768, 640 and 1280 pixels. 375 is phone width. 768 is a tablet, and the width at which most two-column layouts are asked to fold. 1280 is the desktop baseline. 640 is the odd one: it is what a 1280-pixel window becomes at 200% browser zoom, so it catches the same failure for someone who has simply made the text bigger. WCAG 2.1 asks for content to reflow without horizontal scrolling — the criterion is written at 320 CSS pixels, so the widths tested here are more forgiving than the standard, not less.

A finding is raised when the overflow is more than four pixels. The tolerance is deliberate: sub-pixel rounding and scrollbar arithmetic routinely produce a one or two pixel difference on pages that are entirely fine, and reporting those would fill the category with noise. Each width is measured after a short pause so that layout and any resize handlers have finished running.

Tap targets are judged as a proportion, not a count

Every link, button, input, select, textarea and element with a button role is measured on the rendered page, and any with a visible box smaller than 44 by 44 pixels is counted. Elements with no size at all are excluded, because a hidden menu is not a tap target. The 44-pixel figure is the one in WCAG 2.1 success criterion 2.5.5; that criterion sits at AAA level, and WCAG 2.2 later added a 24 by 24 minimum at AA, so this is a usability judgement rather than a legal threshold.

Severity scales with the share, not the raw number. An earlier version raised one flat informational finding whenever a single small target existed, and the result was that every site scored exactly 95: across ten real audits one site had 42 of 63 targets undersized, another 253 of 749, and both came out identical. Now half or more is a warning, a fifth or more is informational, and below a fifth is not reported at all — inline links inside body text are caught by the selector and were never really tap targets.

Small text, and the checks that could not run

Font sizes written into inline styles are read, and anything under 12 pixels raises a warning recommending 14 to 16. The reason is what a browser does next: at that size most people on a phone will pinch-zoom to read, and some browsers apply their own minimum font size, which can break the layout the text was sitting in. This is an honest partial check — it reads sizes in the markup, not sizes set in a stylesheet.

If the headless browser cannot load the page at all, the responsive, accessibility and functional categories are removed from the score entirely and listed as unmeasured with the reason. They are never recorded as zero. A category the audit could not reach is a fact about the audit, not a defect on your site, and scoring it as a failure would drag the overall figure down for work that was never done.

What the engine checks here

Each of these is a rule in the code, not a category heading.

Questions

We use a responsive theme. Does that settle it?

Not by itself. Most overflow findings come from one element inside an otherwise responsive theme — a fixed-width table, an embedded map, a wide image without max-width, a long unbroken URL. The theme handles the layout; the content pushed into it is what escapes. That is why the measurement is taken from the rendered page rather than from the presence of a framework.

Do you test on a real iPhone?

No, and the report does not claim to. It is headless Chromium resized to each width. That measures layout, overflow and element size accurately, and it does not cover iOS Safari quirks, real touch behaviour, or how a specific device handles a specific font. Anything found this way is reproducible in your own browser by narrowing the window, which is the point.

Almost nobody visits us on a phone. Can we skip this?

Check your analytics before deciding, because that is the only place the real split exists. One thing applies regardless of the split: Google crawls and indexes with a smartphone agent, so what a phone-sized browser sees of your page is what is being indexed, whoever happens to be visiting.

Sources

Public and checkable. Nothing here rests on a number we cannot point at.

This is one of fifteen categories. You can read a real report this engine produced on this very site — including the findings it raised against us — or ask for an audit of yours.