Tap Targets Too Small and Close Together: How to Fix It

What this check flags

This check fires when interactive elements on your page — links, buttons, form inputs, icons — are smaller than roughly 48×48 CSS pixels, or when they sit so close to a neighbor that a fingertip can't hit one without grazing the other. The stakes are real: a thumb-sized target that's actually 24 pixels wide turns navigation into a coin flip, and the resulting mis-taps drive the kind of rage-clicking and instant bounces that quietly bleed conversions.

A real example, and the fix

Here's one I hit on an e-commerce category page. The design team stacked "Add to wishlist" and "Quick view" as two text links directly under each product card, separated by a thin bullet:

<div class="card-actions">
  <a href="/wishlist/add/812">Wishlist</a> •
  <a href="/quickview/812">Quick view</a>
</div>

Each link rendered at 13px with zero vertical padding, and the two sat about 6px apart. On a phone, people aiming for "Quick view" kept landing on "Wishlist" and getting a confirmation toast they never wanted. The fix was not clever — it was just giving each target room to breathe:

.card-actions a {
  display: inline-block;
  min-height: 48px;
  padding: 12px 16px;
  line-height: 24px;
}
.card-actions a + a { margin-left: 8px; }

After the change, each link occupied a 48px-tall hit area with an 8px gutter between them. Mis-taps on that component dropped off a cliff in the session recordings. No layout redesign, no new framework — just padding and a min-height.

The size and spacing thresholds

Different tools word the rule slightly differently, but the numbers cluster tightly. Here's what the major sources actually check against.

Aim for 48px and you clear every one of these at once. Treat 44px as the floor and 24px as the "only if you truly can't" exception.

How to detect it on your own site

1. Run PageSpeed Insights or Lighthouse. Open PageSpeed Insights, test the URL, and look under the mobile Accessibility and best-practices audits for "Tap targets are sized appropriately." Lighthouse lists the exact offending elements.
2. Use Chrome DevTools device mode. Toggle the device toolbar, pick a phone, and hover elements to read their rendered box in pixels. Anything under 48px tall in the interactive layer is a candidate.
3. Emulate a real thumb. In DevTools, enable the "Show rulers" and inspect the computed height of links and buttons. If two adjacent targets share fewer than 8px of clearance, note the pair.
4. Test on an actual phone. Nothing beats loading the page on a mid-range Android and trying to tap every control one-handed. The spots where you fumble are exactly the ones the audit flagged.

How to fix it

1. Set a minimum hit area. Give links and buttons min-height: 48px and enough horizontal padding to match. Padding counts toward the tap area — you don't have to make text bigger, just the clickable box.
2. Add spacing between neighbors. A margin of 8px or more between adjacent targets stops the "which one did I hit?" problem.
3. Expand icon-only controls. A 20px hamburger or close icon should live inside a 48px padded wrapper. Pad the parent, not the glyph.
4. Watch inline links in body copy. Two links on the same line, or stacked list links with tight line-height, are the usual repeat offenders. Bump line-height to at least 1.5.
5. Re-test after each change. Fix, reload Lighthouse, confirm the audit passes. Don't guess — verify.

Common mistakes

• Making the text bigger but leaving padding at zero — the visual grows, the hit area doesn't.
• Fixing it in the desktop stylesheet but not inside the mobile media query where the real problem lives.
• Shrinking a nav to fit a phone by cramming links closer instead of collapsing them into a menu.
• Assuming a mobile text too small pass means tap targets are fine — they're separate checks with separate thresholds.

FAQ

Do tap targets directly affect my Google rankings?

Not as a standalone ranking signal since the Mobile Usability report was retired. But it feeds page experience and, more importantly, it wrecks the behavioral metrics — mis-taps and bounces — that do influence how well a page performs. See the Mobile Usability Report entry for the history.

What's the single number I should target?

48×48 CSS pixels with 8px of spacing. Hit that and you satisfy Lighthouse, Apple's HIG, and WCAG simultaneously.

Does padding really count toward the tap area?

Yes. The browser registers taps across the element's full box, padding included. A 14px text link with 17px of vertical padding is a 48px target.

My links pass on desktop but fail on mobile. Why?

Tap targets are evaluated at the mobile viewport. Responsive rules often shrink spacing on small screens, so a component that's comfortable on a laptop gets cramped on a phone. Fix it inside your mobile breakpoint.

Is this the same as the page not being mobile friendly?

It's one ingredient. A page can be broadly mobile friendly and still fail tap targets on one crowded component. Treat this check as a focused subset.