Touch Target Size: Mobile Accessibility for Fingers, Not Mouse Pointers

1. Why touch target size earned its own WCAG rule

Until WCAG 2.1, there was no binding minimum size for clickable or tappable elements, even though mobile devices had long since become the majority of web traffic. The result was interfaces that looked flawless on desktop and turned into an exercise in mis-taps on a phone: tiny close icons in overlays, tightly packed star ratings, filter chips barely wider than the finger itself. WCAG 2.5.5 in version 2.1 and its refined successor 2.5.8 in version 2.2 turned this into a testable, measurable requirement.

The background is purely physiological. Studies on fingertip size show that the actual contact area of a finger on a touchscreen is considerably larger than the visually perceived fingertip, and that hit accuracy for targets under 44 pixels of edge length drops measurably. People with tremor, reduced fine motor control from Parkinson's, arthritis, or simply cold fingers in winter hit small targets even less reliably. Touch target size is therefore not a cosmetic detail, it is one of the few WCAG requirements that translates directly into lost conversions when users miss the buy button three times in a row.

2. WCAG 2.5.8 Target Size Minimum: the mandatory rule at AA level

WCAG 2.5.8 requires, at conformance level AA, a minimum size of 24 by 24 CSS pixels for every target that can be activated by a pointer, unless one of the defined exceptions applies. Exceptions exist for inline links within body text, for targets whose size is determined by the user agent and not controllable by the author, and for cases where an equivalent, larger alternative target exists on the same page.

Important for implementation: the 24x24 rule refers to the actual interactive area, not the visible icon. A 16x16 pixel icon inside a button with sufficient padding satisfies the rule as long as the overall clickable area reaches 24x24 pixels. This can be solved cleanly in CSS through a minimum height and width combined with a transparent hit-area extender, without changing the visual design at all.

/* Visible icon stays small, clickable area reaches 24x24px */
.icon-button {
  min-width: 24px;
  min-height: 24px;
  display: inline-flex;
  align-items: center;
  justify-content: center;
  padding: 4px;
}

/* If the element cannot grow for layout reasons,
   enlarge the hit area invisibly via a pseudo-element */
.icon-button--fixed {
  position: relative;
}
.icon-button--fixed::before {
  content: "";
  position: absolute;
  inset: -6px; /* expands a 12x12px visible icon to a 24x24px hit area */
}

3. WCAG 2.5.5 Target Size Enhanced: 44x44px at AAA level

WCAG 2.5.5 is the older, stricter sibling of 2.5.8 and applies at conformance level AAA with a minimum size of 44 by 44 CSS pixels. Most Magento projects target AA contractually, so 2.5.5 is not formally required. Still, the 44 pixel mark is worth treating as a practical target size for every primary call to action: add to cart button, checkout button, main navigation in the mobile menu. These elements carry the largest share of conversion and benefit the most from generous target areas.

Apple and Google adopted this insight into their platform guidelines long ago: Apple's Human Interface Guidelines recommend 44x44 points, Google's Material Design recommends 48x48 dp as the minimum size for touch-operable elements. Aligning with these established benchmarks instead of the legal minimum of 24 pixels produces interfaces that are not only WCAG compliant, but also noticeably easier to operate on real devices.

4. Spacing between targets: the underestimated second half of the rule

A minimum size alone is not enough when neighboring targets sit flush against each other without any gap. WCAG 2.5.8 only accepts targets smaller than 24 pixels as an exception if sufficient spacing exists to the nearest targets, specifically a 24 pixel diameter circle around the center of each target must not overlap any other target area. In practice this means: a row of 20x20 pixel icons without any gap violates the rule, even if each icon individually would nearly qualify on its own.

Typically affected are horizontal icon bars, for example social share buttons, image gallery thumbnails, or pagination digits in a product list. The spacing does not have to be visible, a transparent margin around each icon is enough, but it has to exist within the interactive area. Gap-based flexbox or grid layouts solve this more reliably than margin values, which tend to collapse easily under responsive wrapping.

/* Icon bar with guaranteed minimum spacing, no collapsing
   of the gap on wrap thanks to gap instead of margin */
.share-icons {
  display: flex;
  flex-wrap: wrap;
  gap: 12px; /* spacing between 24x24px targets, prevents overlap */
}
.share-icons a {
  min-width: 24px;
  min-height: 24px;
}

5. Magento pitfall 1: mini cart icon and header actions

In the Hyvä default header, search icon, account icon, wishlist icon, and mini cart often sit tightly next to each other, designed for a compact desktop look. On mobile breakpoints, the same markup is frequently carried over unchanged, with only the icon size reduced via a Tailwind class, for example from h-6 w-6 down to h-5 w-5, without adjusting the surrounding button's padding. The result is an area that is visibly small, and more importantly, one that is tappably too small.

The fix is independent of icon size: the button, not the SVG, must guarantee the 24x24 pixel minimum area. In Tailwind this can be enforced with a fixed min-h-6 min-w-6 class plus sufficient padding, regardless of how small the SVG icon itself is designed.

<!-- Hyvä header.phtml: mini cart icon with guaranteed touch area -->
<button type="button"
        class="relative flex items-center justify-center
               min-h-[44px] min-w-[44px] p-2"
        aria-label="Open cart, <?= count($items) ?> items">
  <svg class="h-5 w-5" aria-hidden="true"><!-- cart icon --></svg>
  <span class="absolute -top-1 -right-1 ..."><?= count($items) ?></span>
</button>

6. Magento pitfall 2: filter chips and star ratings

Layered navigation filters are rendered in many themes as compact chips, often with little padding so that as many attribute values as possible fit per row. On a smartphone this regularly leads to chips that are textually readable but, as a tap target, well under 24 pixels in height, especially for short values like size labels (S, M, L) or color swatches.

Star ratings are a second classic case: five separate star icons, each intended as its own clickable element for submitting a rating, are often rendered within a width of 100 to 120 pixels, which works out to just 20 to 24 pixels per star, with no gap between stars at all. The solution is the same in both cases: raise the minimum height per chip or star to 24 pixels and introduce a gap value between elements, even at the cost of how many fit per row.

<!-- Layered navigation chip with minimum height instead of compact padding -->
<a href="?size=m"
   class="inline-flex items-center justify-center
          min-h-[24px] px-3 py-1.5 rounded-full border text-sm">
  M
</a>

<!-- Star rating: each symbol as its own 24x24px target with gap -->
<div class="flex gap-1" role="radiogroup" aria-label="Submit a rating">
  <button type="button" class="min-h-[24px] min-w-[24px]"
          role="radio" aria-checked="false" aria-label="1 star">★</button>
  <!-- ... four more stars, same pattern -->
</div>

7. Testing touch target size: DevTools, real devices, automation

The most reliable test method is a real mobile device with touch simulation active, because desktop emulators do not reproduce the actual finger contact area. As a fast intermediate step, the Chrome DevTools Inspect Element function combined with the box model overlay works well: the computed width and height of an element can be read directly and compared against the 24 pixel mark without needing a physical device on hand.

For automation, Lighthouse accessibility audits offer tap target size as a dedicated check, along with axe-core rules that catch at least the obvious size violations, even though axe-core still cannot fully verify spacing between targets. A manual review with a finger on a real smartphone therefore remains mandatory, especially for tightly packed components like filter bars or rating stars.

8. Correctly classifying exceptions and edge cases

Not every small element automatically violates WCAG 2.5.8. Inline text links within a body text paragraph are explicitly exempt, because enlarging the line height for individual links would disrupt the entire text layout. Essential, context-driven presentations are also exempt, for example a calendar widget whose day digits cannot grow to 24 pixels for space reasons without making the month overview unusable.

These exceptions should not be misread as a blanket pass for compact interfaces, though. The essential presentation exception only applies when no practical alternative exists, not simply when a larger presentation is less to the designer's liking. When in doubt: if a compact layout can be rebuilt to the 24 pixel minimum with reasonable effort, the exception does not apply and implementation is mandatory.

9. Anchoring touch target size in the design system for good

Individual fixes to the mini cart or filter chips only address the current symptom. It is more sustainable to anchor minimum sizes as tokens in the design system, for example a Tailwind utility class touch-target that enforces 44 pixels of minimum height and width for all base interactive components, and to make that class mandatory in component reviews.

Figma or Sketch libraries should likewise work with 44x44 pixel frames for icon buttons, so the requirement becomes visible already at the design stage instead of only surfacing once the code is finished. Anchoring the rule early in the design process saves considerable rework on components that have already shipped.

/* Central utility class in the Tailwind theme, mandatory for
   all icon buttons and compact interactive elements */
@layer utilities {
  .touch-target {
    min-height: 44px;
    min-width: 44px;
  }
}

10. Summary

11. FAQ: Touch Target Size in Magento: The Essentials at a Glance