"Tap targets are not sized appropriately": the sizing rules that still apply

Quick answer: Lighthouse retired this audit along with the rest of the Mobile Friendly group, so it no longer appears in a current report. The requirement remains: WCAG 2.2 asks for 24 by 24 CSS pixels at Level AA, and 44 by 44 is the practical target. Fix small targets with padding or a pseudo-element hit area, not by enlarging the icon.

If you are looking for this audit in a current Lighthouse report, it is not there. Google removed the Mobile Friendly group from the SEO category, and tap-targets went with it, along with font-size, viewport, and plugins. We verified this against PageSpeed Insights running Lighthouse 13.4.1: none of those four audit IDs appear in the response.

The requirement did not go away with the audit. Touch target size is a WCAG success criterion, it is still checked by accessibility tooling, and it still decides whether people can use your buttons. This page covers what the numbers actually are now, and what the old audit asked for, since plenty of tools and old reports still quote it.

TL;DR

• Lighthouse: no longer checks this. Do not expect it in a current report.
• The live requirement: WCAG 2.2 SC 2.5.8 asks for 24 by 24 CSS pixels minimum at Level AA. The stricter AAA criterion (2.5.5) asks for 44 by 44.
• The practical target: 44 to 48 px, which is what Apple and Google both recommend and what the retired audit enforced.
• The fix: add padding, or expand the hit area with a pseudo-element. Do not scale up the icon.

Does Lighthouse still check tap targets?

No. The tap-targets audit was part of the SEO category's Mobile Friendly group, which Google retired after it stopped treating mobile-friendliness as a separate ranking signal. A current PageSpeed Insights run returns 11 SEO audits, and none of them is about tap targets.

Two consequences worth knowing:

• A passing Lighthouse SEO score says nothing about your touch targets now. If you were relying on it as your check, you no longer have one.
• Other tools still report it. GTmetrix, older Lighthouse versions pinned in CI, and various SEO crawlers still run the old rule, which is why the phrase keeps circulating. If a tool is showing you this today, it is running its own copy of the check, not Google's.

What is the minimum touch target size?

There are four numbers in circulation and they are all "correct" for different standards, which is the main reason this is confusing:

If you need one number, use 44 px. It satisfies WCAG AA with room to spare, matches Apple's guidance, and is within a few pixels of both Material and the old Lighthouse rule. Twenty-four is a legal floor, not a design goal: it is roughly a third of an adult fingertip.

Note that 2.5.8 has exceptions. A target smaller than 24 px still conforms if it has enough surrounding space that a 24 px circle centred on it would not overlap another target, if it is inline within a sentence, if the size is browser-controlled, or if the specific presentation is essential. Spacing is a legitimate alternative to size, which matters for dense interfaces like toolbars.

What did the old Lighthouse tap-targets audit require?

Worth knowing because other tools copied it. The audit failed when targets were smaller than 48 by 48 px, or when two targets sat closer than 8 px apart, so a finger aimed at one could plausibly land on the other. Its report listed the offending element next to the target it overlapped, which was genuinely the useful part: overlap, not raw size, is what usually causes mis-taps.

How do I fix small tap targets?

Add padding, do not enlarge the icon. The visual size and the touch size are separate concerns. A 16 px icon inside a button with 14 px of padding is a 44 px target that still looks like a 16 px icon.

.icon-button {
  padding: 14px;          /* 16px icon + 28px padding = 44px */
  line-height: 0;         /* stop line-height inflating the box unevenly */
}

Or set the box directly, which is more predictable when content varies:

.icon-button {
  min-width: 44px;
  min-height: 44px;
  display: inline-flex;
  align-items: center;
  justify-content: center;
}

Expand the hit area without touching layout. When padding would break a tight design, a pseudo-element enlarges the touchable region while the visible element stays exactly where it is. This is the technique worth knowing:

.icon-button { position: relative; }

.icon-button::after {
  content: '';
  position: absolute;
  top: 50%;
  left: 50%;
  width: 44px;
  height: 44px;
  transform: translate(-50%, -50%);
}

Keep it to genuinely isolated controls. Two adjacent buttons with invisible 44 px hit areas will overlap each other, which trades a small-target problem for a wrong-target problem.

Space out link lists. Footer and navigation lists usually fail on spacing rather than size, because the links are only as tall as their text. Increase line-height or add vertical padding to the anchor itself, not to the list item, so the padding is part of the clickable area.

.footer-nav a {
  display: block;
  padding: 12px 0;
}

The elements that fail most often, in order: icon-only buttons (close, share, favourite), footer link lists, pagination controls, checkboxes and radios with tiny hit areas, table row actions, and carousel arrows.

What about overlapping tap targets?

Two separate issues get discussed together here.

Overlap is when adjacent targets are close enough that a fingertip covers both. This was what the retired audit measured with its 8 px rule, and it is the failure users actually notice, because they tap the right place and get the wrong result. Spacing fixes it; size alone does not.

Double-tap to zoom is different. On mobile, browsers historically waited about 300 ms after a tap to see whether a second tap was coming. Modern browsers skip that wait when the viewport is set correctly, and you can be explicit:

button, a, .tappable {
  touch-action: manipulation;
}

That disables double-tap zoom on those elements and removes any residual delay, while leaving pinch zoom intact. Do not disable zoom globally with user-scalable=no: it is a WCAG failure in its own right.

How do I test touch target sizes?

Since Lighthouse dropped the check, use a tool that implements WCAG 2.2:

1. axe DevTools has a target-size rule for SC 2.5.8. This is the most direct replacement for what the Lighthouse audit did.
2. Measure in DevTools. Switch to device mode, inspect the element, and read the box model. You want the padded box at 44 px or more, not the icon.
3. Test with a thumb, on a real phone. Emulators do not have fingers. One pass through your primary flow, one-handed, finds problems no scanner reports.

What mistakes should I avoid?

• Assuming a green Lighthouse SEO score covers this. It no longer does, and that is the trap this whole page exists for.
• Scaling the icon instead of the hit area. It makes the design worse and is not what any standard asks for.
• Treating 24 px as the goal. It is the AA floor, with spacing exceptions attached. Design to 44.
• Adding padding to the list item instead of the link. Only the anchor is clickable, so the padding does nothing.
• Disabling zoom to dodge double-tap delay. Use touch-action: manipulation on the elements that need it.
• Giving every button an invisible expanded hit area. Adjacent expanded targets overlap, which is the failure you were trying to fix.

Related audits

• Background and foreground colors do not have sufficient contrast, the other WCAG criterion that fails most often in real audits
• Image elements do not have alt attributes, the accessibility audit Lighthouse does still run
• Document does not have a main landmark, structure for assistive technology

Audit your URL at https://lighthouse-md.com.