Interfaces designed with a mouse usually fail on touch for one reason. A cursor points at an exact spot; a fingertip lands on an area. The icon sits neatly at 16 pixels on screen, and in the hand it either activates the item next to it or does nothing at all.
A cursor is one pixel; a fingertip is not
There are published figures to work from. WCAG 2.2 sets a minimum target size of 24 by 24 CSS pixels and an enhanced level of 44 by 44. Mobile platform design guidelines land in much the same region, around 44 to 48. These are values from published guidelines rather than anything we measured, which is exactly why they are safe to quote.
The working rule is simple: aim for 44 for anything meant to be tapped, and if something genuinely has to be smaller, do not let it fall below 24.
Growing the hit area without growing the visuals
Often the design will not tolerate a bigger icon. In that case, separate the visual size from the hit area. The simplest tool is padding — leave the glyph alone and pad the button, and the clickable area grows with it.
If padding disturbs the layout, extend the area with a pseudo-element instead.
.icon-btn { position: relative; } plus .icon-btn::after { content: ""; position: absolute; inset: -10px; } widens the real hit area by ten pixels on every side while the thing on screen stays exactly the same size.
Spacing is part of the size
A small target with empty space around it is genuinely tappable, and the accessibility guidelines allow an exemption from the size rule precisely when there is enough clearance around a target. Conversely, two 44-pixel buttons pressed hard against each other still produce mis-taps along the shared edge.
The riskiest case is a list where the whole row is a link and a small control — a delete button, say — lives inside it. Those two need invisible breathing room between them.
Hover-only affordances do not exist on touch
Touch has no hover. A submenu that appears on mouseover, an explanation living only in a tooltip, a button revealed when you hover a card — to a touch user, those features are simply absent. Some mobile browsers treat the first tap as a hover and the second as a click, which reads to the user as “I pressed it and nothing happened”.
The fix is to stop guessing from viewport width; wide touchscreens exist, so width is the wrong question. Ask about the input device instead — put hover embellishment inside @media (hover: hover) and (pointer: fine), and always keep a tap-reachable route to the underlying function.
Checking interaction quality on real screens continues in the Themes & plugins archive, and the checklist plugin we publish is on the free tools page.
Next part
Once things can be pressed, the question becomes what to press. Next: mobile navigation — what the hamburger actually costs, and the alternatives.