Tap target size: the 44 by 44 pixel guideline

What a tap target is

A tap target is anything a finger has to hit: a link, a button, a form control, a checkbox. Unlike a cursor, a fingertip covers several millimetres and the contact point is not where the user is looking.

The common guideline is around 44 by 44 CSS pixels with space between adjacent targets. WCAG 2.2 sets a minimum of 24 by 24 with exceptions for inline links and spacing. Padding is the usual way to reach it: the tappable area grows while the visible element stays the size the design wants.

What squirrel checks

The rule runs on every crawled page. It counts button and [role="button"] elements, a[href] links, and input, select and textarea controls. It then looks at the inline style on the buttons and links for a font-size, height or width declared as an integer number of pixels below 30. The patterns are case-sensitive and unanchored, so min-width: 20px matches the width test and a fractional width: 20.5px matches nothing. It emits up to two checks:

• tap-targets reports info when the page has any interactive element. Message: 84 interactive element(s) found, with Ensure tap targets are at least 44x44px as the value.
• small-tap-targets warns when any of those carries a small inline dimension. Message: 3 element(s) may have small tap targets, with Check inline styles for small dimensions as the value. Severity warning, weight 5.

The counts are sums of selector matches with no deduplication, so an <a href> carrying role="button" is counted twice, in the small-target count as well when it qualifies. Nothing is measured either: static markup carries no computed size, so the rule reports the count as context and uses inline styles as a weak proxy. A page whose sizes come from an external stylesheet produces the informational count and nothing else.

How to fix it

.icon-button { padding: 12px; min-width: 44px; min-height: 44px; }

Give small controls padding rather than a larger icon, and keep at least 8 pixels between adjacent targets. Navigation links and icon-only buttons are where this usually goes wrong.

Measure it in a browser. This rule tells you how many targets there are, not how big they render.

Enable / disable

Disable this rule

[rules]
disable = ["mobile/tap-targets"]

Disable all Mobile rules

[rules]
disable = ["mobile/*"]

Enable only this rule

[rules]
enable = ["mobile/tap-targets"]

enable replaces the default ["*"], so this is the only rule selected. Leave disable out: a rule that matches any disable pattern is skipped even when enable names it. Only an enabled setting under a rule’s own [rule_options] table overrides both lists.

Related rules

• a11y/touch-targets: inline sizing hints for potentially small touch targets.
• mobile/font-size: text sized too small for the same reason.
• mobile/horizontal-scroll: layout problems on the same screens.
• links/anchor-text: whether those targets are named at all.

Mobile findings ship in every audit next to the SEO, performance and agent experience rules. See Core Web Vitals for how an agent works through a report.

References

• Understanding target size (minimum), WCAG 2.2
• Page experience, Google Search Central

Check your site

Run squirrel audit https://example.com and open the Mobile section of the report. Each page is reported with its interactive element count and any small inline dimensions. Signed-out local audits need no account and cost nothing. Signed-in audits spend credits.