What makes a touch target accessible beyond just its visual size?

An accessible touch target needs more than a big-enough icon: it needs an adequate hit area, enough spacing from its neighbors, and a clear name and state for assistive technology. The tappable region is what matters, not the graphic, and that region can and should extend well past the visible mark. Making the icon larger is a half-measure that addresses only the part of the problem you can see. Accessibility lives in the interactive area and its labeling, which are invisible in a static comp but decide whether a person with a tremor, large fingers, or a screen reader can actually use the control.

The hit area is the first thing the visible size obscures. The region that responds to a tap is set by the element’s box and padding, not by the drawing inside it, so a 16-pixel glyph can sit inside a 44-pixel button if you give the button enough padding, and a 44-pixel-looking icon can have a tiny hit area if the click handler is bound to the glyph alone. The practical floors come from converging guidance. The current WCAG 2.2 baseline, Success Criterion 2.5.8 Target Size (Minimum), is Level AA and asks for at least 24 by 24 CSS pixels, while the stricter 2.5.5 Target Size (Enhanced) is Level AAA at 44 by 44. The major platforms aim higher than the AA floor: Apple’s Human Interface Guidelines call for 44 by 44 points, and Google’s Material Design recommends 48 by 48 density-independent pixels, which is the comfortable target to design toward.

Spacing is the second invisible requirement, and WCAG’s minimum criterion bakes it in directly. A target smaller than the size floor can still pass if it is spaced so that a 24-pixel-diameter circle centered on it does not overlap the circle of any neighboring target. In plain terms, small controls need breathing room around them, because a finger that lands slightly off should not hit the wrong thing. Two undersized icons jammed edge to edge fail even if each is individually drawn cleanly; the same two icons with adequate gap can be acceptable.

A concrete example: a card has a row of three 20-pixel social-share icons pressed tightly together in the corner. They look tidy at desktop zoom, but on a phone they are below the size floor, give no spacing for an imprecise tap, and (if they are bare SVGs in links) announce as nothing useful to a screen reader. Fixing it means wrapping each icon in a button or link with padding so the tappable box reaches at least 44 by 44, adding margin so the targets do not crowd each other, and giving each one an accessible name (“Share on LinkedIn”) and, where it toggles, a state.

Note one exception: size and spacing are necessary but not sufficient: a perfectly sized target that has no accessible name is still inaccessible to a screen reader, and a toggle that never communicates its on/off state leaves those users guessing. Conversely, a few exceptions exist in the standard, such as targets whose function is available another way or inline links inside a sentence, so the rule is about interactive controls, not every clickable pixel. Accessibility is the whole package of area, spacing, and labeling.

When you build interactive controls, give each one a hit area of at least 44 to 48 pixels regardless of how small the icon looks, keep adequate space between adjacent targets, and supply a clear accessible name and (for toggles) a state. Then check it on a real phone with your thumb, not just at desktop zoom; if a slightly off tap hits the wrong control or a screen reader cannot name what you are about to press, the visible size was never the point.