Interactive element is too small to tap accurately

What is this issue?

An interactive element (a link, button, role="button" element, non-hidden input, select, or any element with tabindex="0") has a rendered bounding box smaller than 24 by 24 CSS pixels in both width and height, the Level AA minimum introduced in WCAG 2.2. A target below that size can still pass if it qualifies for the criterion’s spacing exception: enough space around it that a 24px zone centered on the small target doesn’t overlap the equivalent zone around any adjacent target.

Two narrow additional exceptions exist: targets inline within a sentence or block of running text (a link inside a paragraph) are exempt entirely, since resizing every inline link would break normal text flow, and a target that’s the only reasonable presentation for the content, such as a point on an interactive map, is also excused. Everything else (a standalone icon button, a small close “×” control, a compact toolbar icon) needs to meet the size or spacing bar.

Why does this matter?

Hitting a small target accurately requires precise, steady pointer control, whether that pointer is a fingertip, a mouse cursor, or a stylus. For someone with a tremor, a motor condition affecting fine control, or anyone whose hand simply isn’t perfectly steady in the moment, a target sized for an idealized precise tap is a target they will frequently miss, not occasionally, but as a routine part of using the page.

Missing a target isn’t a neutral outcome; it often means hitting something else instead, since interactive elements rarely sit in isolation. A near-miss on a “delete” icon crammed next to an “edit” icon can trigger the wrong action entirely, and recovering from an accidental deletion or an unintended navigation costs real time and, in consequential cases, real data, a cost a sighted mouse user with steady hands never has to think about, because they clear the same target without noticing it was small.

Who is affected?

• Motor impairments: tremors, limited fine motor control, or use of a switch or head-pointer device all reduce pointing precision, making a small target (one requiring exact placement to activate) disproportionately hard to hit reliably compared with a larger one.
• Low vision users: targets that are small on screen are also visually harder to locate precisely before attempting to tap or click them, compounding the size problem with a targeting problem.

What users experience

Consuela has essential tremor, a neurological condition causing involuntary hand shaking that worsens with focused, precise movements: the exact motion a small tap target demands. She’s using a food delivery app on her phone to remove an item from her cart, where the “remove” and “edit quantity” icons sit side by side, each rendering at roughly 18x18px with only a few pixels of gap between them. Her first tap lands on “edit quantity” instead of “remove,” opening a stepper control she didn’t intend to trigger; her second attempt, made more carefully and more slowly, finally lands on the correct icon, a two-step process for what should have been one tap, repeated for every item she needs to adjust.

How do I fix it?

Increase the element’s rendered size to at least 24 by 24 CSS pixels. This is the most direct fix, and it works because target size is measured from the element’s actual bounding box: increasing padding, min-width, and min-height all count toward that box, so the visual icon inside it doesn’t need to grow at all to satisfy the requirement.

When the design intentionally keeps an icon visually small (a common pattern in dense toolbars or compact UI), add padding around the icon rather than resizing the icon itself, so the clickable area reaches 24x24px while the visual footprint stays unchanged. If enlarging every target individually isn’t practical, the spacing exception is a legitimate alternative: ensure enough gap exists between adjacent small targets that accidentally missing one doesn’t land on a neighbor. Where practical, 44x44px (the size both Apple’s and Google’s own platform guidelines recommend) is a more comfortable target than the 24px WCAG minimum, worth using as the default rather than treating 24px as the design goal.

Code Examples

/* Rendered target: 18x18px - fails the 24x24px minimum */
.icon-btn {
  width: 18px;
  height: 18px;
  padding: 0;
}

/* Method 1: padding reaches 24x24px without resizing the visual icon */
.icon-btn {
  width: 18px;
  height: 18px;
  padding: 3px; /* 18px + 3px + 3px = 24px total target */
}

/* Method 2: min-width/min-height, aiming above the bare minimum */
.icon-btn {
  min-width: 44px;
  min-height: 44px;
  display: flex;
  align-items: center;
  justify-content: center;
}

Method 1 keeps the icon exactly as small visually as the original design intended; only the clickable padding around it grows, which is invisible to a sighted user but doubles the effective target size for anyone tapping or clicking it. Method 2 goes further, targeting the 44x44px size platform guidelines recommend, using display: flex to keep the visual icon centered within the larger clickable area rather than stretching the icon itself.

Common Mistakes

Mistake: “The icon just needs to look bigger, so we’ll scale up the SVG.” Scaling the visual icon changes its appearance without necessarily changing the actual clickable bounding box, especially if the icon sits inside a container with its own fixed dimensions. Measure the rendered target’s actual width/height (or use getBoundingClientRect() in DevTools) rather than assuming a visually larger icon automatically means a larger target.

Mistake: “We can’t make these targets bigger without breaking the compact toolbar design.” Padding solves this without changing the visual layout at all: the icon stays the same pixel size, and only the invisible clickable area around it grows. This works in nearly every toolbar or icon-grid layout without requiring a visual redesign.

Mistake: “This is a mobile-only concern since it’s about touch targets.” Small target size affects anyone with reduced pointing precision, including mouse users with tremors or limited fine motor control, not exclusively touchscreen users. Treat this as a general interaction-design requirement, not a mobile-specific one.

How RedFlag Detects This

Custom automated: RedFlag’s own DOM detector, runs on every scan. RedFlag’s runCustomRules engine measures the rendered getBoundingClientRect() of every interactive element on the page (links, buttons, role="button" elements, non-hidden inputs, selects, and elements with tabindex="0") and flags (reporting up to ten offending elements) any with a rendered width or height under 24 CSS pixels. Zero-size elements, typically hidden via display: none, are excluded so genuinely invisible elements don’t produce noise. This check reuses the same rule id as a native axe-core rule, but the detection logic itself is RedFlag’s own custom implementation rather than a call into axe-core.

False negative: the detector measures raw element size only; it does not evaluate WCAG’s spacing exception, so a target under 24px that legitimately passes because of generous spacing from its neighbors is flagged the same as one with no such spacing, meaning some flagged elements are actually compliant on manual review. False positive: as above, any small target that qualifies for the spacing exception produces a flag despite being compliant; inline text links, which are exempt from the size requirement entirely, are also measured by bounding box and can be flagged if they happen to render as a small, isolated clickable region. Manual step: for any flagged element, check both its actual size and its spacing from neighboring targets before concluding it’s a genuine failure; a small target with generous surrounding space may already satisfy the criterion as written.

Manual Testing

1. Open the page in Chrome DevTools and use the device toolbar to simulate a touchscreen device, or test on a physical phone or tablet.
2. For each small icon, button, or link, select it in the Elements panel and check the “Box Model” or computed width/height in the Styles pane. Confirm it’s at least 24x24 CSS pixels.
3. For any target under 24x24px, measure its distance from adjacent interactive targets; if there’s enough gap that a 24px zone around each target wouldn’t overlap, it may still pass under the spacing exception.
4. Physically tap small or closely-grouped targets on a real touch device and note whether mis-taps land on a neighboring control rather than the intended one.
5. Confirm inline text links within paragraphs are excluded from this check, since they’re exempt from the size requirement by design.

Related WCAG Success Criteria

2.5.8 Target Size (Minimum): The size of the target for pointer inputs must be at least 24 by 24 CSS pixels, except when the target has adequate spacing, is inline within text, or is the only reasonable presentation for the content. This rule is a direct measurement of that minimum against every interactive element’s rendered bounding box.

A stricter Level AAA sibling from WCAG 2.1, 2.5.5 Target Size (Enhanced), requires 44 by 44 CSS pixels with no spacing-based exception, worth targeting directly for products aiming at AAA, though 24x24px with spacing is the more commonly required AA baseline this rule documents.

Related Issues

Skip link target is missing or not focusable shares this cluster’s focus on keyboard and pointer usability, though it addresses focus-target validity rather than physical size.

CSS locks content to a single orientation shares this rule’s underlying concern with physical device access for motor-impaired users, applied to screen orientation rather than tap-target size.

UI component has insufficient contrast commonly co-occurs with small-target failures in the same audit, since compact, low-contrast icon buttons are a frequent design pattern that fails both checks together.

Page animations have no reduced motion alternative and Text spacing overrides break the layout round out this cluster’s shared theme: presentation choices that work fine for a typical user but become real barriers for someone whose physical interaction needs differ from that default.

References

• W3C Understanding 2.5.8: Target Size (Minimum)
• W3C WCAG 2.2: What’s New