Ask a designer how big a tap target has to be and you will hear forty-four. It is in design system documentation, in accessibility checklists, in code review comments, and it is usually attributed to WCAG.
The WCAG requirement at the level almost everyone is actually held to is twenty-four.
Two criteria, two levels
There are two target-size criteria and they are not alternatives. They sit at different conformance levels.
The one that arrived in WCAG 2.2 is Success Criterion 2.5.8, Target Size (Minimum), at Level AA:
"The size of the target for pointer inputs is at least 24 by 24 CSS pixels, except when…"
The 44 is Success Criterion 2.5.5, Target Size (Enhanced), at Level AAA:
"The size of the target for pointer inputs is at least 44 by 44 CSS pixels except when…"
Almost every accessibility policy, procurement rule and legal standard specifies AA. AAA is explicitly not intended to be required across a whole site. So a team told "WCAG says 44" is being held to a level their own policy does not ask for, using a number from a criterion they are not claiming.
Why the confusion has a real source
This is not simply a misreading. Until WCAG 2.2, there was no AA target-size criterion at all — 2.5.5 was the only one, and in WCAG 2.1 it was titled just "Target Size", with no "(Enhanced)" to signal that a smaller sibling existed. The suffix was added in 2.2 precisely because 2.5.8 arrived beside it.
⚠️ That makes one common citation impossible: "WCAG 2.1 SC 2.5.5 Target Size (Enhanced)" names a title that did not exist in 2.1. The phrase "Target Size (Enhanced)" appears eighteen times in WCAG 2.2 and not once in WCAG 2.1, while the string "2.5.5" appears thirteen times in 2.1 — the criterion is there, under the older name.
So for roughly four years, "the WCAG target size" genuinely was 44, and anyone who learned it then learned it correctly. WCAG 2.2 became a Recommendation on 5 October 2023.
The exception nobody quotes correctly
2.5.8 has five exceptions where 2.5.5 has four, and the extra one is the reason 24 is workable at all. It is also the one most often restated wrongly:
"Undersized targets (those less than 24 by 24 CSS pixels) are positioned so that if a 24 CSS pixel diameter circle is centered on the bounding box of each, the circles do not intersect another target or the circle for another undersized target"
⚠️ This is not "leave 24 pixels of space between targets". The circle is 24 pixels in diameter and it is centred on the target, so it extends 12 pixels in each direction. Two 10-pixel icons pass when their centres are 24 pixels apart — about 14 pixels of visible gap, not 24. The test is also asymmetric: an undersized target next to a full-size button is measured against that button's actual edge, not against a circle around it.
The W3C's own explanatory material is unusually candid about what this buys:
"This success criterion defines a minimum size and, if this can't be met, a minimum spacing. It is still possible to have very small, and difficult to activate, targets and meet the requirements of this Success Criterion"
Where 44 actually comes from
The number is Apple's, and Apple has moved.
Apple's Human Interface Guidelines now present 44×44 points as the default control size for iOS and iPadOS, with 28×28 points listed as the minimum. Other platforms differ again — 28×28 default on macOS, 66×66 on tvOS. Google's Android documentation recommends a touch target of at least 48dp by 48dp.
⚠️ And the unit is points, not pixels. A CSS pixel is defined by visual angle, roughly 0.0213 degrees, anchored to a 96dpi reference at arm's length; a point is 1/72 inch, so one point is about 1.333 CSS pixels. Apple's 44 points is therefore around 58.7 CSS pixels — larger than WCAG's AAA 44, not equal to it. Four different numbers in four different unit systems, collapsed into "44px" by everyone who repeats it.
What this does not mean
It does not mean 24 is a good size. It is a floor, and the W3C says in as many words that you can clear it and still ship something hard to hit. Their own advice is that important controls should aim for 2.5.5.
Nor does it mean Apple's figure is wrong. It is a platform convention for a platform, and it is a more generous one than the standard requires. The error is only in the attribution — in citing a design guideline as a conformance requirement, at a level it does not belong to.
What to do with it
If you are conforming to AA, the number to test against is 24 by 24 CSS pixels, with the spacing exception available for genuinely small controls, and the spacing measured as centre-to-centre rather than edge-to-edge.
If you are writing the rule down for a team, write the criterion number and the level beside it. "44px minimum tap target" survives review because nobody can tell from the sentence which document it came from; "2.5.8, AA, 24×24 CSS px" cannot be misfiled.
And if a checklist tells you a 30-pixel button fails WCAG AA, it is wrong, and it is worth knowing why before you spend a sprint on it.
Where this comes from
The quoted normative text and the exceptions are Success Criteria 2.5.8 and 2.5.5 of Web Content Accessibility Guidelines 2.2, W3C Recommendation, in the version published 12 December 2024; the criterion first became a Recommendation on 5 October 2023. The candid passage is from the W3C's Understanding document for 2.5.8. The CSS pixel definition is from the WCAG glossary and from CSS Values and Units Level 3. Platform figures are from Apple's Human Interface Guidelines accessibility page and Google's Android accessibility documentation, both read on 16 September 2026.
⚠️ The counts come from the specification documents themselves. "24 by 24" appears twice in WCAG 2.2 and zero times in WCAG 2.1, while "44 by 44" appears twice in both — the pair matters, because the zero is only meaningful beside a term that is present. "Level AA" occurs 64 times in 2.2 and 57 in 2.1, so the older document was searched rather than unreachable. "Human Interface" appears zero times in either: Apple is nowhere in WCAG.
View author profile → · Editorial policy
