Touch targets and why minimum sizes keep getting violated

The guidance on touch target sizes is clear, widely published, and consistently violated. Apple's Human Interface Guidelines have recommended 44x44 points for tap targets since iOS 7. Material Design's guidelines set 48x48 density-independent pixels. WCAG 2.2 introduced a minimum of 24x24 CSS pixels for touch targets (SC 2.5.8, AA level), a floor and not a recommendation. None of this is obscure.

And yet: icon buttons at 16x16, close icons that require precise tapping, nav items so densely packed that the wrong one fires on half the attempts. These aren't fringe cases. They're present in production on products with large design teams that care about quality.

The reason isn't ignorance of the numbers. The reason is that design environments lie.

The design environment problem

A UI element in a design file is a layer. The visual representation of that layer might be a 20x20 icon. But the tappable area for that icon on a real device is whatever the developer chose to implement, which is usually the rendered size of the element rather than any specified touch target. The design file shows you the icon; it doesn't show you the gap between the icon and the nearest adjacent interactive element.

Desktop design tools operate at resolutions that compress the reality of mobile interaction. A 16px icon at 100% zoom on a 27-inch monitor is navigable with a cursor. On a phone, 16 CSS pixels is roughly 2-3 millimeters. The average fingertip contact area is much larger than that. The gap between what looks fine in a design tool and what's usable on a device is real and systematic.

The design tool doesn't tell you whether adjacent targets have enough separation to prevent accidental activation. It doesn't simulate a touch interaction or show you how a target size feels at actual physical scale. A 28x28 button looks fine. A 28x28 button next to another 28x28 button with 4px between them is, in practice, a single large target that activates whichever one you hit.

Why the violations cluster where they do

Touch target problems are not evenly distributed across an interface. They cluster in specific locations, and recognizing those locations is half the fix.

Icon-only action buttons in tables and lists. A table row with edit and delete icons at the end of each row, both 20x20, both 8px apart. This pattern is everywhere. The icons look proportional to the row height. The tap targets are inadequate.

Navigation bars with many items. A bottom nav bar trying to fit six destinations instead of four means each item gets less horizontal space. Visual designers reduce the icon size or the label to compensate. The tap target shrinks.

Close and dismiss buttons on overlays. Modal close buttons placed in the corner at small size because visually they should be subordinate to the content. Subordinate visually and inadequate for touch.

Inline links in dense text. Mobile body text is already compressed for screen width. A linked word in a paragraph is usually smaller than any touch target guidance, and it's surrounded by non-interactive text on both sides that will absorb mis-taps.

Form controls that are visually styled down. A checkbox or radio that's been styled with custom CSS to be smaller than the browser default, to match a compact design. The visual element is 16x16. The tappable area of a native checkbox was larger, and the custom one doesn't preserve it.

The right mental model for fixing this

The visual size of a UI element and the touch target size are separable concerns. A 16x16 icon can have a 44x44 touch target through padding, through an invisible overlay, or through the interactive element's minimum size being larger than its visual content. The appearance doesn't have to change; the tappable area does.

Annotating minimum touch target sizes in design specs is necessary but not sufficient. Engineers who receive a spec saying "icon should be 20px" will implement a 20px element. The spec needs to say "icon is 20px visually; minimum tappable area is 44x44; implement with padding." That's a different instruction that produces a different output.

On iOS, a common pattern is applying negative margins or additional transparent padding to achieve the target size. In CSS, you can use min-height and min-width on the interactive element, or use ::after pseudo-elements to extend the hit area beyond the visible bounds. These are well-known techniques. The blocker is usually that the spec didn't ask for them.

Spacing between adjacent targets

Target size is one variable; target spacing is the other. WCAG SC 2.5.8 accounts for this by measuring the "CSS pixel space" between targets: targets smaller than 24x24 can still meet the criterion if the space between them brings the total activation area to 24x24. The more actionable guidance from platform HIG docs is to treat adjacent target spacing as a separate constraint from individual target size.

In practice: if you can't make every individual target 44x44, make sure adjacent targets are separated by enough that a finger press on one won't routinely activate the other. 8px between 44x44 targets is fine. 4px between 28x28 targets is a usability problem for users with reduced dexterity, and a frustration for everyone.

How this gets fixed at scale

One approach that works: define a touch target minimum as a design token or component property, not as a guideline. If the button component has min-height: 44px in the component, every button inherits it without anyone needing to remember. The policy is encoded in the implementation, not the documentation.

The components most likely to violate target sizes are the ones with the most flexibility: icon buttons, chips, tags, inline links. These are also the components where a designer is most likely to adjust the visual size for density reasons. Building the minimum touch target into the component baseline, and requiring a deliberate override to reduce it, catches more violations than any annotation will.

The minimum size requirements aren't arbitrary. They come from research into touch input variance, tremor, and the physical constraints of using a glass surface with a fingertip. Every time a product ships a 16x16 close button, a percentage of users fail to close the overlay on the first try, and the users most affected are the ones with the least control over their touch input.