Minimum Target Size
also called Target Size Floor, Pointer Target Minimum
The floor on how small a tappable control may be before pointer errors become systematic - 24 by 24 CSS pixels at level AA - together with the spacing rule that decides whether a smaller control still passes.
Three icon-only buttons sit in each row of a dense table: edit, duplicate, delete. Each has a 16 by 16 pixel hit area with 2 pixels between them. Phone users report deleting the wrong row - and the buttons have correct accessible names, work with a keyboard, and pass every automated check.
This is a pointer-accuracy failure with a number attached. WCAG 2.2, a W3C Recommendation since 5 October 2023, added success criterion 2.5.8 Target Size (Minimum) at level AA: pointer targets must be at least 24 by 24 CSS pixels, subject to five exceptions. The stricter 2.5.5 Target Size (Enhanced) is AAA at 44 by 44.
Why it matters
A finger's contact patch is far larger than 16 pixels and the user cannot see what is under it, so error rate rises as target size falls and as spacing falls, and the two compound. The spacing test fails for 3 of 3 buttons in every row. When one adjacent action is destructive, an accuracy problem becomes a data-loss problem and the fix cost moves from CSS to a restore path. The European Accessibility Act has been enforceable since 28 June 2025 with EN 301 549 referencing WCAG level AA, so for services in scope this is an obligation.
The mechanism teams miss is the cheap one. The visible icon and the hit area are different boxes, so padding or a pseudo-element grows the target while the layout stays exactly as dense.
Implementation patterns
- Set the floor in the shared button component, not per screen; the per-table patch is what regresses next quarter.
- Expand the hit area without the visual box, using padding with a negative-margin wrapper or a positioned
::beforecovering 24 by 24 centred on the glyph. - Assert it mechanically: a computed-size check fails the build when a consumer shrinks a target, and a lint rule catches heights below the floor.
- Reserve 44 pixels for destructive and in-motion use - delete, pay, confirm - and test on a real touch device, because an emulator driven by a mouse never produces a mis-tap.
Industry example
The clearest reference is the standard itself. The W3C's Understanding document for 2.5.8 names the five exceptions - spacing, equivalent, inline, user agent control and essential - and spacing governs most arguments: a 24-pixel-diameter circle centred on each undersized target must not intersect another target's circle.
Apply it twice. At 16 pixels with 2-pixel gaps the circles overlap, so the criterion fails. A lone 16-pixel close button in a dialog corner passes, because nothing is near it. Two controls of identical size, one conforming and one not - which is why "is 16 pixels allowed?" has no answer without spacing context.
Failure scenarios
- The dense table, with mis-taps concentrated on the action beside the destructive one.
- A compliant component broken by a consumer overriding its height to fit a row.
- A fix applied to the glyph rather than the box: the icon looks bigger, the target did not change, and the next audit re-files the finding.
Trade-offs
| Choose | Gains | Pays |
|---|---|---|
| 24-pixel floor everywhere | AA conformance; one enforcement point | some redesign of dense layouts |
| 44 pixels on key actions | far fewer errors on destructive paths | real vertical space; a layout rethink |
| Rely on the spacing exception | very dense designs still conform | fragile - a later layout change breaks it silently |
The third row is the one worth naming: it makes conformance a property of the surrounding layout rather than of the component, so the library cannot enforce it.
When not to use it
The criterion carves out where the floor does not apply: links inside running text, sizes set by the user agent, cases where the same action is available through a conforming control elsewhere, and presentations where size is essential - a map pin at a precise coordinate.
Do not generalise it into "make everything 44 pixels". Applied indiscriminately that destroys density on data-heavy screens, which carries its own cost: fewer rows means more scrolling for everyone. Judge per control class - 24 as the floor, 44 where an error is expensive, and the spacing exception used knowingly rather than found in an audit.
Interview question
Q: A product owner says the 24-pixel floor breaks their dense data table and asks for an exception. How do you respond, and what do you ship?
What a strong answer covers: separating hit area from visual box so density need not change; running the spacing test instead of arguing; the destructive action as the one that must reach 44; the row-menu alternative and its cost of an extra tap; the fix in the shared component with a computed-size assertion.
Quick check
Quiz: A 16 by 16 pixel control passes 2.5.8 in one place and fails in another. Why? Answer: the spacing exception - a 24-pixel circle centred on the target must not intersect another's, so an isolated small control conforms while the same control in a tight row does not.
Flashcard: What is the AA minimum pointer target size, and the cheapest way to meet it? — 24 by 24 CSS pixels under WCAG 2.2 SC 2.5.8. Expand the hit area with padding or a positioned pseudo-element; the icon and the target are different boxes.