Mobile usability: the defects a desktop review never sees

Viewport, tap targets, horizontal scroll and the keyboard that covers the button. The checks that decide whether a phone visitor can finish.

Mobile · Published: 4 September 2026 · 4 min read · Дмитрий Орлов

Most teams review their site on a laptop and ship. Most of their traffic is on a phone. The gap between those two sentences is where a specific family of defects lives — none of them visible at 1440 pixels wide, all of them capable of ending a purchase.

Start with the viewport

One missing line makes a phone render the page at desktop width and shrink it:

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

Two variations of it are worse than the omission. maximum-scale=1 and user-scalable=no block pinch-zoom, which is a hard accessibility failure for anyone with low vision, and browsers increasingly ignore them anyway. Nothing about your layout is worth taking zoom away from a reader.

Tap targets

A fingertip is about nine millimetres. Interface guidelines settle on roughly 44 by 44 CSS pixels as a minimum, with a few pixels of separation. Below that, taps land next to their target and the visitor blames the site rather than their thumb.

Where it goes wrong is predictable: icon-only buttons scaled down for mobile, links in a dense footer, checkbox labels that are not clickable, and pagination controls sized for a mouse. The pattern to look for is a small control next to another small control — a mis-tap on an isolated button costs a moment, a mis-tap in a row of five costs a wrong action.

Horizontal scroll

If any element is wider than the viewport, the whole page slides sideways and text runs off the edge. The usual culprits are a fixed-width table, an image without max-width: 100%, a code block, or a container with a min-width copied from the desktop design.

The test is one line in the console:

document.documentElement.scrollWidth > window.innerWidth

Run it at 360 pixels on every template, not just the home page.

The keyboard problem

On a phone, the on-screen keyboard covers the bottom third of the screen. A submit button fixed to the bottom of a form ends up underneath it. So does the error message that explains why the form did not submit. This is the single most common reason a mobile form "does nothing" — the feedback exists, off-screen.

Check with the keyboard open, not with the field merely focused in a desktop emulator.

Text and inputs

Font sizes below 16 pixels in an input make iOS zoom the page on focus, and the layout never quite recovers. Body text under 14 pixels is a readability problem in daylight. And every input deserves the right inputmode and autocomplete — a numeric keypad for a phone number is a two-attribute change that measurably lifts completion.

Test at real widths

Emulation in DevTools catches layout; it does not catch the keyboard, the browser chrome that eats a hundred pixels, or a tap that lands two millimetres off. Run the important flows on an actual device once a release, and automate the mechanical part — viewport meta, target sizes, overflow, input attributes — on every page, on every deploy.