← Back
[W] Writing

Bigger touch targets that look the same

There's an argument that comes up on every dense interface.

Accessibility guidance says touch targets should be around 44px. The design says this toolbar button is 24px, because it sits in a dense toolbar and 44px would look ridiculous.

Both are right. They only seem to conflict if you assume that the thing you can see and the thing you can touch have to be the same size.

These use the same sizes as the small HextaUI buttons. Try tapping just above or below one, with the larger area on and off.

An invisible pseudo-element

A button's ::after counts as part of the button. So give it a larger box, make it invisible, and every tap inside that box lands on the button.

Here's what's in HextaUI's button, simplified from Tailwind.

@media (pointer: coarse) {
  .button-xs::after {
    content: "";
    position: absolute;
    inset-block: -10px; /* 24 + 10 + 10 = 44 */
    inset-inline: 0;
  }

  .button-sm::after {
    content: "";
    position: absolute;
    inset-block: -6px; /* 32 + 6 + 6 = 44 */
    inset-inline: 0;
  }
}

Both end up 44px tall, from two different sizes. Nothing visible changes. There's no layout shift, because a positioned pseudo-element takes up no space.

Three details that make it work

Only grow on touch. pointer: coarse limits this to devices where the main pointer is imprecise. A mouse doesn't need it, and on desktop a big invisible area can steal clicks from whatever's nearby.

Mostly grow vertically. Text buttons sit side by side, so their areas would overlap if they grew sideways. Most toolbars have room above and below. So my text buttons use inset-inline: 0. Icon-only buttons are square, so those grow all the way around, because a 24px square is much harder to hit.

Switch it off inside groups. In a button group, the buttons touch each other, and their areas overlap. So HextaUI hides the larger area there.

xs, drawn24px
xs, touchable44px
sm, drawn32px
sm, touchable44px
Only the height changes for text buttons.

The limit

It isn't magic. If two small targets are closer together than the space you've added, one area sits on top of the other, and the later element wins. If a toolbar is that tight, the toolbar is the problem.

It's also worth using an actual phone, because this can't be checked in a browser's device mode with any confidence. You need to find out if your thumb agrees.

The bigger idea is that a lot of "design vs accessibility" arguments are like this one. They're rarely a real conflict. Usually there's an assumption everyone has stopped questioning.

Next