It’s Not Your Finger. It’s the Target.

What WCAG, Apple, Google, and actual finger-measurement research say about target size — and why the number most designers quote is a myth

A guide for product and interaction designers

A button gets tapped. The wrong thing happens. The user tries again. This is a fat finger error — and the name already tells you where most teams look for the fix: the finger. This piece argues the fix lives somewhere else entirely.

What a target size is

Target size is the tappable area that responds to input — not the icon or label the user sees, but the invisible zone underneath it. A 24px icon sitting inside a 48px target has 12 pixels of room on every side that the user will never notice and their finger will always use.

When that zone is too small, or too close to a neighboring one, the tap lands in the wrong place. That’s the error. The finger didn’t fail. The target did.

This concept has a different name on every platform.

Apple calls it a hit target. Google calls it a touch target. WCAG calls it target size. Lighthouse called it a tap target (and filed the audit under SEO instead of Accessibility until 2024, when Lighthouse 12 moved it where it belongs). Designers tend to just say clickable area.

Five names, same problem.

How big a finger is

When a finger presses glass, the tip doesn’t make contact — the flattened pad does. That pad is wider than most people think.

MIT Touch Lab measured the average index finger contact patch at 16–20mm wide: roughly 45–57 CSS pixels at standard density. A thumb runs about 25mm, around 71 pixels.

The “44px average finger” claim you see everywhere converts to about 15.5mm. That’s smaller than the low end of a real index finger and barely two-thirds the width of a thumb. The number didn’t come from measuring a finger — more on that below.

Accuracy also shifts across the screen. Steven Hoober’s research found people tap most precisely near the center. Corners are the worst zone, with the bottom corner needing almost twice the target size of the center. About half of users hold their phone one-handed, so this gradient affects most sessions.

On a desktop, corners are the easiest place to click — a cursor can’t overshoot past the edge. On a phone held in one hand, corners are the hardest place to reach. A corner doesn’t justify a smaller target. It demands a bigger one.

What the standards require

Six sources publish target-size minimums. None of them agree, and the gap between the smallest and largest is more than 3×.

That range isn’t a mistake — it reflects context. Tapping a screen while driving is a different problem than tapping one in your hand. Android Auto’s minimum runs about 50% larger than Material’s phone standard for that reason.

The floor across all of them is higher than “make it bigger” usually implies.

Where “44 pixels” comes from

The standard explanation: the average finger is 44 pixels wide, so guidelines say 44×44. Clean story. Wrong on almost every count.

44 came from Apple’s original iPhone HIG — a design decision for a 3.5-inch screen held in one hand, not a measurement of anatomy. WCAG’s enhanced guideline (AAA, SC 2.5.5) later adopted the same figure. But the level most teams need to meet is SC 2.5.8, Level AA: 24×24 CSS pixels, with a spacing exception that lets smaller targets pass when they’re far enough from neighbors.

44 is the stretch goal. 24 is the enforceable floor.

And “pixels” is misleading. Apple’s unit is points. Android uses dp. WCAG uses CSS pixels. All three are density-independent — they stay the same physical size no matter how many hardware pixels the screen crams in.

This is why “48dp” and “48px” aren’t interchangeable. At baseline density, 1dp equals 1px. At 2× density, the same 48dp target takes 96 hardware pixels. At 4×, 192. The spec never changes. The screen just draws more dots to fill it.

44, 48, or 24-with-spacing — all reasonable defaults for their platform. The mistake is treating any of them as a fact about human fingers instead of what they are: engineering decisions that happen to be published.

Why taps miss

Size gets blamed because it’s visible in a screenshot. It’s rarely the only reason.

Too small. Smaller than a fingertip’s contact patch means some taps land outside the target no matter what.

Too close together. Two targets can each pass the minimum and still cause errors if they’re packed tight. WCAG tests this with a 24px circle centered on each target — if the circles overlap, the spacing fails.

Visual and target don’t match. A small icon inside a big target, or a big icon that only responds in its center — either way, users can’t see the real boundary.

No affordance. Desktop has hover to reveal what’s clickable. Touch has nothing. If a control only looks interactive on mouse-over, it’s invisible on a phone.

No feedback. No response to a tap means the user doesn’t know it worked, so they tap again — harder, faster, on the wrong thing. Analytics tools call this a rage tap.

No recovery. A mis-tap that’s reversible costs nothing. One that deletes data or completes a purchase costs real damage. A delete button sitting in the easiest spot on the screen to reach makes this worse — move destructive actions out of easy reach, or put a confirmation in front of them.

Size is the cause you can screenshot. The other five cause just as many failures.

Design the target, not the icon

The fix isn’t a bigger icon. It’s a bigger target with the same icon inside.

A 24px icon doesn’t need to grow to meet a 48px minimum. It needs invisible, tappable padding. The design system keeps its small icon. The target underneath does the work.

Same icon, four results. No padding: fails. Padded and centered: passes. Padded but pinned to one corner: fails (room is on the wrong side). Round target around a round icon: passes. Three variables — size, centering, shape — drive every outcome.

.icon-button {
 width: 24px;
 height: 24px;
 position: relative;
}

@media (pointer: coarse) {
 .icon-button::after {
 content: "";
 position: absolute;
 inset: -12px; /* expands target to 48×48 */
 }
}

Padding fixes “too small.” It doesn’t fix “too close.” You need both.

A CSSWG proposal for a native pointer-box-offset property has been open since 2020. Until it ships, pseudo-elements are the workaround.

Before shipping

Save this. Run it before every release.

Check Below ‘target-size review skill’ for your coding agent

“Fat finger” is a phrase that puts the blame on the user. The problem is almost never the finger — it’s the target, the spacing, the feedback, or the recovery path. Get those right and the mis-taps go away.

Want this checked automatically?

A target-size review skill runs against code, design files, or written specs — flags undersized, uncentered, or poorly-spaced targets using the same standards cited above.

→ View the skill on GitHub

If this changes how you spec your next control, share it — it helps other designers find it.

Sources

• W3C — SC 2.5.8 Target Size (Minimum), WCAG 2.2 — w3.org
• W3C — SC 2.5.5 Target Size (Enhanced), WCAG 2.1 — w3.org
• Smashing Magazine — Finger-Friendly Design, MIT Touch Lab data — smashingmagazine.com
• Nielsen Norman Group — Touch Targets on Touchscreens — nngroup.com
• Google — Sizing, Design for Driving, Android Auto — developers.google.com
• W3C CSS Working Group — Issue #4708, pointer-box-offset — github.com
• Steven Hoober — Designing for Touch, 4ourth Mobile — 4ourthmobile.com
• Steven Hoober — Fitts’ Law in the Touch Era, Smashing Magazine — smashingmagazine.com
• Colin Contreary, Embrace — Rage Taps — embrace.io

Note:

These visuals are designed to be saved and pinned into your design system docs.

Standards evolve — verify against current WCAG and platform docs before treating any number as final.

Thanks for Reading!

It’s Not Your Finger. It’s the Target. was originally published in Bootcamp on Medium, where people are continuing the conversation by highlighting and responding to this story.