Zoom disabled, tap targets too small, and the sideways scroll you will never see on a desktop

Your site probably looks fine on the monitor you built it on. That tells you less than you think. A page can block zoom, crowd its links too tightly for a thumb, and slide sideways under every swipe, and none of it shows up on a desktop. A few basic mobile usability checks catch all three in about ten minutes, once you know where to look.

Why your desktop hides all three

Each failure depends on something a desktop does not have.

• Zoom. Desktop browsers ignore the viewport meta tag. Whatever it says about zoom has no effect on the machine you review the site on.
• Tap targets. A mouse pointer lands on a single pixel. A 20 pixel link is easy to click with one and easy to miss with a fingertip, which covers far more of the screen.
• Width. A 1,000 pixel table fits comfortably in a desktop window. On a phone that is around 400 CSS pixels wide, it pushes the whole page sideways.

Even testing on your own phone can miss the first one, as the next section explains.

Zoom disabled: one line in your head tag

Open your homepage source and find the viewport tag. A healthy one looks like this:

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

A problem one carries extra instructions:

<meta name="viewport" content="width=device-width, initial-scale=1, maximum-scale=1, user-scalable=no">

maximum-scale=1 and user-scalable=no both tell the browser the visitor may not pinch to zoom. For someone with low vision, that ends the visit. They cannot enlarge the body text, the price, or the phone number. Zoom support sits under the WCAG success criterion on resizing text, which expects content to stay usable at 200 percent.

Why you never noticed

Safari on iPhone has ignored these zoom restrictions for pinch gestures since iOS 10. If your test device is an iPhone, pinch zoom works and the bug is invisible to you. Chrome on Android honors the tag by default, so a visitor on an Android phone gets a page they cannot enlarge unless they have dug into their accessibility settings to force it.

Why it got there

The line is rarely an accident. The usual story: someone tapped into a contact form on an iPhone, the page zoomed in on its own, and the fastest fix was to cap zoom for everyone. iOS Safari zooms whenever a visitor focuses an input with a font size under 16 pixels. The cap stops that jump on iPhone without blocking pinch zoom there, which is why it looks harmless. On Android, it blocks zoom outright.

Fix the cause instead:

input,
select,
textarea {
  font-size: 16px;
}

Then remove maximum-scale and user-scalable from the viewport tag. Form fields stop jumping and zoom works everywhere. The contact form audit covers the 16 pixel rule alongside the other form fixes.

If the tag comes from a theme or page builder, change it in the header template or the theme settings. Editing the rendered HTML will not survive the next update.

Tap targets too small for a thumb

Three numbers are worth knowing:

| Source | Minimum target | |---|---| | WCAG 2.2, level AA | 24 by 24 CSS pixels, or enough spacing around it | | Apple Human Interface Guidelines | 44 by 44 points | | Google's Android guidance | 48 by 48 density-independent pixels |

The 24 pixel figure is the accessibility floor. Aim for 44 to 48 on anything a visitor needs to tap. Google's guidance on accessible tap targets recommends 48 pixels with roughly 8 pixels of space between neighbors.

The usual offenders on a small business site:

• Footer link lists set in small type with no padding between lines
• Social icons, 16 or 20 pixel glyphs placed edge to edge
• The close button on a popup, often the smallest target on the page
• Text links in a paragraph that wrap onto consecutive lines
• Pagination numbers and carousel dots

What the visitor experiences: they aim for "Contact" and land on "Careers." They try to close a popup, miss the tiny X, and tap the overlay instead.

The fix is a bigger hit area, not a bigger icon. A minimum size and padding enlarge the tappable box without changing how the element looks:

nav a,
footer a,
.social-links a {
  display: inline-flex;
  align-items: center;
  min-height: 44px;
  min-width: 44px;
}

button.icon {
  padding: 12px;
}

Then test it the honest way. Open the page on a real phone and tap every link in the header and footer with your thumb, not a fingertip held at a careful angle. If you hit the wrong one even once, so will your visitors.

The sideways scroll

Desktop testing hides this one most completely. On a phone, the visitor swipes up, the page drifts left, and a strip of blank space appears on the right. From then on the layout wobbles with every swipe. Nothing looks broken in a screenshot, which is why it can survive for years.

Something on the page is wider than the screen. The common culprits:

• Tables with no scroll wrapper, especially pricing tables, hours of operation, and spec sheets
• Images with a fixed pixel width and no max-width: 100%
• Embeds like maps and videos pasted in with width="600" hard coded
• Long unbroken strings, such as a full URL or email address in body text
• Fixed-width containers left over from an old theme, like a wrapper set to width: 960px
• A desktop navigation bar with six or more links in a single row and no mobile menu

Find the element in one step

Open the page in Chrome, turn on device mode in DevTools, pick a phone size, and paste this into the console:

document.querySelectorAll('*').forEach((el) => {
  if (el.getBoundingClientRect().right > document.documentElement.clientWidth) {
    console.log(el);
  }
});

Every element that pokes past the right edge gets logged. Usually the first one or two entries are the cause and the rest are their children.

Fix the cause, not the symptom

The tempting fix is overflow-x: hidden on the body. It stops the wobble, but it crops whatever was overflowing, so the last column of your pricing table simply disappears. On a wrapper element it also creates a scroll container, which breaks position: sticky headers inside it. If you want a safety net, overflow-x: clip trims the overflow without that side effect. The MDN reference for overflow explains the difference.

Better fixes, matched to the culprits:

img,
video {
  max-width: 100%;
  height: auto;
}

iframe {
  max-width: 100%;
}

.table-wrap {
  overflow-x: auto;
}

p,
li {
  overflow-wrap: break-word;
}

Wrap each table in <div class="table-wrap"> so the table scrolls inside its own box while the page stays put.

Running mobile usability checks yourself

A short routine catches most of this:

1. View source and read the viewport tag. Remove maximum-scale and user-scalable if either is there.
2. Open DevTools device mode at a narrow phone width and run the overflow snippet above.
3. If your own phone is an iPhone, borrow an Android phone and try to pinch zoom.
4. Tap every header and footer link with your thumb.
5. Tap into each form field and watch for the page jumping.

Repeat on your top three landing pages, not only the homepage. Templates differ, and the pricing page is where the wide table usually lives.

Where a scan fits

The manual pass works, but it is easy to skip on pages you rarely open. A complete scan from the AcuityScan homepage includes a mobile module that fetches your page with an iPhone user agent and reads the HTML your phone visitors receive. It flags maximum-scale=1 and user-scalable=no in the viewport tag, tables with no scroll wrapper, images with fixed widths over 400 pixels, form inputs styled below 16 pixels, and a long desktop nav with no mobile menu.

The tap target check is a heuristic, and we label it that way. It reads inline sizes on links and buttons, not the rendered layout, so treat a finding as a list of places to test with your thumb.

The mobile module runs alongside 350+ checks across 8 modules. Blocked zoom hurts the same visitors the accessibility check is built for, so read the two sets of findings together.

TL;DR

• Remove maximum-scale=1 and user-scalable=no from your viewport tag. Stop iOS form zoom with 16 pixel inputs instead.
• iPhones ignore the zoom block for pinch gestures, so test zoom on an Android phone.
• Aim for 44 to 48 pixel tap targets with space between them. Use padding and minimum sizes, not bigger icons.
• Sideways scroll comes from one element wider than the screen. Find it with the console snippet, then fix that element instead of hiding overflow on the body.