Touch Target

It began with screens built for a mouse being used with a finger instead. A cursor comes to a point, so a 16-pixel icon can be hit exactly. A fingertip meets the glass across roughly 8 to 10 millimetres, and which part of that contact patch counts as the press is not something the user can see or control.

So the same screen behaved differently under a finger. With share and delete icons sitting side by side at the end of a row, reaching for share hits delete. A small checkbox takes three attempts to tick, and the third one works for reasons nobody can explain. On an action that can't be undone, that misfire gets recorded as user error while the cause sits in the layout. For someone using one hand on a moving bus, or whose hands shake, the gap is wider still, and they are the people least likely to report it as a bug.

A touch target is that margin written down as a number. Separately from how large the icon looks, it fixes how much area has to respond to a press. Among accessibility requirements — designing so people can use a product regardless of disability or circumstance — it's one of the most mechanically checkable.

Make each element's responsive area at least a set size and keep neighbours from touching. Five things to decide.

1. Pick the number. Apple's human interface guidelines say at least 44 points on a side; Google's material design recommends 48dp. WCAG, the international standard for web accessibility, sets a floor of 24 by 24 CSS pixels and allows spacing to make up the difference. A team picks one, writes it down, and judges against it. Leaving the choice unwritten means every review argues the number again.
2. Separate the visible size from the responsive area. This distinction carries the whole concept. An icon can be drawn at 20 pixels with padding around it that brings the pressable area to 44. That's how a dense screen meets the standard without being redrawn, and it is the step most teams miss.
3. Look at the gaps between neighbours too. Two areas can each be 44 pixels and still misfire at the boundary if they're flush against each other. Around 8 pixels of separation is the convention, and irreversible actions like delete get more than that on purpose.
4. Enlarge by position. The top corner of a phone screen is hard for a thumb to reach one-handed, so the same size is harder to hit there. Fitts's law — that closer, larger targets get hit faster — is why size and position get considered together rather than as separate checks.
5. Check on a real device. Pressing with a mouse on a laptop never surfaces this. Two people with differently sized hands trying it with a thumb is the fastest check available, and it takes about a minute per screen.

The numbers can also be swept mechanically. Highlighting responsive areas in developer tools and listing everything under the threshold routinely turns up twenty items on a single screen, most of them icons nobody thought of as small.

Every screen used with a finger qualifies, but some places get caught more than others.

Lists come first. Several actions per row is the structure that squeezes icons smallest. The judgment that comes out of it is often structural: make the whole row open the item and move individual actions onto the screen that opens. Enlarging three icons in place rarely fits.

Tables are second. More columns means narrower cells, and the buttons inside them shrink to match. Reducing the number of buttons and grouping actions at the row level beats forcing the sizes to fit into cells that were never going to hold them.

Third is mobile-first work, designing for the small screen before the large one. Meet the standard on a phone and a desktop layout passes automatically, with room to spare. Reverse the order and the density chosen on a large screen gets pushed into a small one, breaking it.

Fourth is review. App store review and public-sector accessibility audits check this numerically, which makes it a condition of shipping rather than a preference. A single button failing the threshold can hold a release, which is an expensive way to learn the number.

Desktop isn't exempt. Small targets are slower to hit with a mouse too, and touchscreen laptops and kiosks are operated by finger. That said, a desktop-only tool can be fine at the 24-pixel floor, which is why some teams record separate thresholds per screen type.

"This icon's hit area is 24 pixels. It needs to be 44."

The comment is about the responsive area, not about how the icon is drawn.

"Leave the icon alone and add padding."

Meet the standard while keeping the density of the screen as designed.

"Delete and share are flush against each other and people are misfiring. Start with the gap."

Spacing, not size, is the cause here, so enlarging the icons would not help.

This came in as a report on the Pagedeck document list. Share, duplicate and delete icons sat together at the end of each row, and support logged seven tickets a month about documents being deleted that nobody meant to delete.

Noa checked and found the hit areas were 28 pixels each with 2 pixels between them. The fix wasn't larger icons but a different structure. The row now carries one overflow button with a 44-pixel area, and the three actions moved inside it. Delete sits apart at the bottom of that menu, separated from the other two by a divider.

The most common mistake is assuming the standard requires bigger icons. The number is written as a size, so the artwork looks like it has to grow with it. But what the standard governs is the responsive area, and the drawing can stay as it is. Without that distinction, teams either abandon the threshold because it would make the design look clumsy, or fill the screen with oversized icons that solve the measurement and spoil the layout. A 20-pixel icon with 12 pixels of padding on each side reaches 44 while the screen stays exactly as it was.

Reading it as a problem only for finger-driven screens is the other one. The word touch is in the name, which invites that. But what the threshold actually addresses is precision of input, and precision drops in plenty of situations that have nothing to do with fingers: shaking hands, a moving vehicle, a trackpad instead of a mouse. Build a desktop product without this item and the same finding comes back at the accessibility review, with the same number attached to it.