Touch Target Size: Making Sense of 24px, 44pt, and 48dp

The minimum touch target size for accessibility is 24 by 24 CSS pixels — that’s the enforceable floor set by WCAG 2.2 Success Criterion 2.5.8 at Level AA. Apple’s 44pt and Google’s 48dp are not competing standards; they’re platform recommendations for comfortable tapping. The practical rule: never ship a control smaller than 24px, and build primary controls at 44–48px.

If you’ve searched this topic and come away more confused than you started, that’s normal. Three authorities publish three different numbers in three different units. Here’s how they fit together, why each exists, and how to fix undersized buttons with a few lines of CSS instead of a redesign.

Why are there three different touch target numbers?

Because they answer three different questions. WCAG sets a conformance minimum — the smallest a target can be before it’s a testable failure. Apple and Google publish design guidance — the size at which a fingertip stops mis-tapping. A floor and a comfort zone are not a contradiction; a doorway has a legal minimum width and a width architects actually build.

The units are closer than they look. A CSS pixel, an Apple point, and an Android dp are all density-independent measures that stay roughly the same physical size across screens. Google’s own web guidance translates its figure for websites: web.dev recommends “around 48 device independent pixels,” which works out to around 9mm — “about the size of a person’s finger pad area.”

So the honest reconciliation is one sentence: 24px is the floor you must not go under; 44–48px is the size you should actually build.

What does WCAG 2.5.8 actually require?

SC 2.5.8 Target Size (Minimum) requires that “the size of the target for pointer inputs is at least 24 by 24 CSS pixels,” with five exceptions (W3C Understanding document). It was added in WCAG 2.2, which the W3C published as a final Recommendation on 5 October 2023, and it sits at Level AA — the conformance level nearly every accessibility policy, contract, and legal standard points to. We covered all nine new criteria in our WCAG 2.2 overview; this is the deep dive on the one that trips up the most designs.

Two details matter more than the number itself.

The target is the hit area, not the picture. WCAG measures the region that responds to a tap. A 16px gear icon inside a padded 32px button is a 32px target. This is what makes most fixes trivial — you grow the invisible hit area, not the artwork.

Spacing can substitute for size. An undersized target still passes if, per the W3C, a “24 CSS pixel diameter circle” centered on it doesn’t intersect any other target or its circle. A lone 20px icon floating in whitespace passes. Three 20px icons packed edge-to-edge fail — and that cluster of tiny adjacent controls is exactly what the criterion was written to catch, because it’s where a tremor or a thumb on a rush-hour train produces the wrong tap.

When does a small target still pass? The five exceptions

WCAG 2.5.8 lists five situations where an under-24px target is not a failure (W3C):

1. Spacing. The 24px-circle rule above — enough clearance around an undersized target.
2. Equivalent. Another control on the same page does the same thing and meets the minimum. A tiny inline “next” arrow is fine if a full-size Next button exists too.
3. Inline. Links inside a sentence or block of text are exempt, because their size is “constrained by the line-height of non-target text.” Your body-copy links do not need to be 24px tall.
4. User agent control. Elements the browser renders by default — a native scrollbar, an unstyled checkbox — are exempt as long as you haven’t restyled them.
5. Essential. Cases where the size is legally required or essential to the information, like pins on a digital map.

The inline exception is the one that saves the most panic. The rule is aimed at standalone controls, not prose. But note what it doesn’t exempt: a link styled as a button, a lone linked icon, or a navigation menu are all standalone targets, and the 24px minimum applies.

Where does the 44px number come from, then?

From two places that reinforce each other. Apple’s design guidance has told iOS developers for over a decade to “create controls that measure at least 44 points x 44 points so they can be accurately tapped with a finger”. And WCAG 2.1 — published before 2.2 — includes SC 2.5.5 Target Size, which requires “at least 44 by 44 CSS pixels”… at Level AAA.

That AAA is the catch. Level AAA is the aspirational tier of WCAG; laws, regulations, and procurement standards almost universally stop at Level AA. So for years the only target-size criterion in WCAG was one almost nobody was obligated to meet. The Working Group’s answer in 2.2 was to add a smaller, more pragmatic minimum at AA — which is why the newer standard has the smaller number. It’s not a loosening of 2.5.5; it’s a floor being installed underneath it.

Google’s 48dp guidance rounds the same physical reality — a fingertip is about 9mm wide — up to Android’s 8dp grid. Different unit, same finger.

Is any of this legally required?

The 24px rule specifically? Not yet, in most US contexts — and we’d rather tell you that straight than imply otherwise. The Department of Justice’s rule for state and local government websites adopts WCAG 2.1 Level AA as its technical standard, with compliance deadlines in April 2027 and April 2028 depending on population size. WCAG 2.1 AA does not contain 2.5.8. Private ADA lawsuits and settlements against businesses also overwhelmingly reference WCAG 2.1 AA — we explain why in our breakdown of the DOJ Title II web rule.

So why bother? Three reasons. First, the standard only moves in one direction — new laws and contracts increasingly cite WCAG 2.2, and sites built to 2.2 automatically satisfy 2.1. Second, target size is one of the cheapest criteria to meet, usually pure CSS. Third, and mostly: tiny targets lose you real customers with tremors, arthritis, big thumbs, or a phone in one hand — the same motor and dexterity barriers behind much of WCAG’s input guidance. This is a fix that pays for itself in completed checkouts.

The usual offenders

After enough audits, the same undersized controls show up on almost every small-business site:

• Carousel dots. The little pagination circles under a hero slider are routinely 8–10px, packed in a row — failing both the size minimum and the spacing alternative at once.
• The cookie-banner “X.” Ironically, the control everyone wants to hit is often a 12px glyph with no padding.
• Quantity steppers. The plus/minus buttons on ecommerce product pages, frequently under 20px and touching each other — right at the money step of the funnel, next to the form fields that carry their own requirements.
• Footer social icons. A row of 16px logos with no gaps.
• Date-picker arrows and pagination numbers. Dense grids of small, adjacent targets.
• Icon-only toolbar buttons. Which often fail twice — too small to tap and too faint to see, since icons and controls also need 3:1 contrast under SC 1.4.11 Non-text Contrast.

None of these need a visual redesign to fix. Which brings us to the good news.

How to fix small targets without a redesign

Because WCAG measures the hit area rather than the artwork, the fix is padding — the icon stays exactly the size your designer chose while the tappable region grows around it:

/* 16px icon, 44px tap target — nothing changes visually */
.icon-button {
  display: inline-flex;
  align-items: center;
  justify-content: center;
  min-width: 44px;
  min-height: 44px;
  padding: 12px;
  background: transparent;
}

We suggest sizing to 44px, not 24px: it clears WCAG 2.5.8 with margin, satisfies Apple’s guidance, and lands within rounding distance of Google’s 48dp. Where layouts are genuinely tight — dense tables, toolbars — fall back to the 24px floor plus the spacing rule.

Then verify your own site in five minutes:

1. Open your homepage on your phone and try to hit every control with your thumb, one-handed. Note every mis-tap.
2. In desktop Chrome, right-click a suspect control, choose Inspect, and hover over the element — DevTools shows its rendered width and height in pixels.
3. Anything under 24px in either dimension is a candidate failure. Check the exceptions: is it inline text? Is there a full-size equivalent? Is there clear space around it?
4. For clustered controls (carousel dots, steppers), check spacing: if the centers of two adjacent targets are less than 24px apart, the spacing exception can’t save them.
5. Hand the list to your developer with the CSS pattern above. Most sites clear every failure in an afternoon.

A word of caution from our testing work: automated checkers can flag some undersized targets, but the exceptions — equivalent controls, essential sizes, inline context — need human judgment, so a clean automated report doesn’t mean you pass 2.5.8.

The one-sentence policy to adopt

Set it in your design system and stop relitigating it: interactive targets are 44px minimum, 24px absolute floor for cramped exceptions, with 8px between neighbors. That single line satisfies WCAG 2.2 AA, Apple, and Google simultaneously, and your customers with shaky hands, thick thumbs, and cracked screens will simply find your site easier to use — they’ll never know why.

If you’d like to see where your site stands right now — undersized targets, contrast failures, missing labels and the rest — run a free accessibility scan. It takes a couple of minutes and gives you a concrete list to hand your developer.