Skip to content
Strynal, Digital Agency

Design 5 min read

Sizing Touch Targets for Accessible, Tappable UI

Practical rules on touch target sizing and spacing: the platform minimums, spacing requirements, and common mistakes that make interfaces hard to tap.

By Strynal Team

Tapping the wrong element is a frustration almost every phone user can name. It usually points to a design decision made on a desktop, sized for a cursor rather than a fingertip. Knowing the numbers and applying them consistently is what separates interfaces that feel considered from those that merely look designed.

Why Default Sizing Fails on Touch

When designers work in Figma or Sketch, they’re moving a cursor. A 16px icon button or a 20px text link is perfectly precise under a mouse. A fingertip is not a cursor. The average adult index finger pad covers roughly 44–57 px at 1x, and it doesn’t land with sub-pixel accuracy.

The gap between what looks right at 100% zoom on a desktop screen and what actually works under a thumb is where most touch target errors originate. Small targets produce mis-taps. Mis-taps produce errors. Errors produce drop-off.

Accessibility is not an afterthought: it applies to touch target sizing just as much as colour contrast or screen reader support. People with motor impairments, hand tremors, or who are using their phone one-handed in motion rely on generously-sized targets more than the average user. Getting the size wrong excludes a portion of your audience silently, without any error log to flag it.

The Numbers You Need

Apple’s Human Interface Guidelines set a minimum tappable area of 44 × 44 points (pt) for iOS and iPadOS elements.

Google’s Material Design recommends 48 × 48 dp (density-independent pixels) as the minimum for any touchable element.

WCAG 2.5.5 (Target Size, Enhanced) sets a minimum of 44 × 44 CSS pixels. WCAG 2.2 introduced the softer 2.5.8 criterion at 24 × 24 CSS pixels for targets with sufficient spacing from adjacent interactive elements. For most production work, 44 × 44 px is the practical floor.

All three standards refer to the interactive area, not the visible element. A 20px icon can meet the standard if the invisible tap area surrounding it reaches 44px. CSS padding is the most direct way to achieve this without altering visual layout.

Spacing Matters as Much as Size

Two 44px targets placed flush against each other produce the same mis-tap problem as two 22px targets. The gap between elements is part of the system.

Sizing a target correctly and placing it incorrectly achieves nothing. The minimum target size standard assumes adequate spacing from neighbouring interactive elements.

WCAG 2.5.8 defines adequate spacing as at least 24px of offset from any adjacent target where the target itself is smaller than 44px. In practice, an 8px gap between targets is a reasonable minimum for most layouts. Complex controls (icon toolbars, bottom navigation bars, action menus) benefit from 12–16px gaps.

The thumb-zone model matters here too. The bottom-centre of a phone screen is the most naturally reachable area with one hand. Targets in the top corners or along the far edges require more stretch and are more prone to mis-taps. Those zones deserve extra spacing care, not less.

Common Mistakes

Making the label the target

A “Forgot your password?” text link that is 18px tall and 160px wide occupies 18 × 160px of actual tap space. That is 18px of vertical room, well below every standard. Adding padding-top: 13px; padding-bottom: 13px; on that anchor tag costs nothing and meets the minimum.

Designing for hover instead of touch

Hover states exist only on pointer devices. A touch interface has no hover. That tooltip which appears on hover, the dropdown that only opens on hover, the subtle underline on mouse-over to signal a link: none of these exist for touch users. Design for touch first and treat hover as a progressive enhancement. The same thinking applies to keyboard navigation, another non-pointer interaction pattern that needs deliberate treatment rather than being inherited from the desktop layout.

Treating a design system token as a one-time fix

Setting 44px as a minimum token height solves the problem for the components built with that token. Bespoke components, inline links, icon-only buttons in tight layouts, and third-party widgets fall outside the token and need to be checked individually. The token is a floor, not a guarantee.

Tight segmented controls

Segmented controls, tab bars, and toggle groups are common offenders. Each segment should still clear 44px in height. If meeting that constraint means reducing the number of options, that is usually the right trade-off. Fewer well-sized options beat more options that users reliably mis-tap.

What to Do in Practice

In design:

  • Set minimum component heights in design system tokens and enforce them at the token level, not per-component at review time.
  • Use a dedicated annotation layer to show actual tap areas distinct from visible element bounds. This makes the invisible visible and gives developers a clear spec.
  • Check thumb-zone ergonomics for any mobile-primary interface. Primary actions should sit in the comfortable reach zone, not wherever there is visual space.

In development:

  • Extend tap areas with padding, not margins. Padding is part of the hit target; margin is not.
  • When disabling tap highlight colour on iOS (-webkit-tap-highlight-color: transparent), replace it with an explicit active state rather than removing feedback entirely.
  • Test on a real device. Browser device emulators are useful but they do not replicate the precision gap between finger and pixel that actual hardware reveals.

In QA:

  • Automated tools can flag some target size violations, but coverage is inconsistent across tools and browsers. Manual spot-checks on device remain necessary. Web accessibility testing covers the full tooling picture in more depth.

How Strynal Approaches Touch Target Design

Touch target sizing at Strynal is a component-level constraint, not a QA checkbox. Every interactive element in a design system we build ships with minimum height tokens and specified tap area behaviour. We design mobile-first: the touch interaction model is the primary constraint, and desktop behaviour is layered on top.

Our UI/UX service covers this end-to-end, from the first design review to production testing on device. If your existing interface has tap target problems, an audit usually surfaces the critical failures quickly. Most are fast to fix once they are visible.

Get in touch if you want a second set of eyes on the touch ergonomics of what you are building.