Mobile Tap Targets - Practical Fix Guide

This check estimates whether interactive controls are large enough for touch users. Undersized targets increase accidental taps, form errors, and mobile frustration.

Start here

Before You Fix It: What This Check Means

Tap-target sizing and spacing reduce mis-taps in touch-first navigation patterns. In plain terms, this tells you whether people using keyboards or assistive tech can use the page reliably. Scavo samples interactive elements (links, buttons, form controls, labels, summaries) and estimates target size from inline style/attributes.

Why this matters in practice: issues here can block completion for assistive-tech users and create compliance exposure.

How to use this result: treat this as directional evidence, not final truth. Automated checks do not replace complete manual assistive-technology validation. First, confirm the issue in live output: verify with keyboard flow and at least one assistive-technology pass Then ship one controlled change: Set minimum touch-size tokens in design system. Finally, re-scan the same URL to confirm the result improves.

This check estimates whether interactive controls are large enough for touch users. Undersized targets increase accidental taps, form errors, and mobile frustration.

What Scavo checks (plain English)

Scavo samples interactive elements (links, buttons, form controls, labels, summaries) and estimates target size from inline style/attributes.

Thresholds in this check:

  • Minimum threshold: 24px (critical WCAG-style floor)
  • Recommended comfort target: 44px

How Scavo scores this check

Result behavior:

  • Fail: undersized (<24px) targets are significant (>=25% ratio or >=3 targets)
  • Info: fewer than 3 measurable targets (sample too limited)
  • Warning: some undersized targets (<24px) but below fail threshold
  • Warning: none under 24px but some under 44px
  • Pass: no undersized sampled targets

In your scan report, this appears under What failed / What needs attention / What is working for mobile_tap_targets, followed by Recommended next steps and Technical evidence (for developers) when needed.

  • Scan key: mobile_tap_targets
  • Category: ACCESSIBILITY

Why fixing this matters

Small touch targets cause mis-taps and slow task completion, especially on dense navs and form-heavy pages. This is a direct conversion and usability issue on mobile.

Target-size consistency also reduces support friction and helps accessibility compliance posture.

Common reasons this check flags

  • Icon buttons with tiny dimensions.
  • Tight inline controls in tables/cards.
  • Low padding on links/buttons in mobile breakpoints.
  • Legacy components not updated to modern touch spacing.

If you are not technical

  1. Test key mobile flows one-handed on a real device.
  2. Prioritize CTA, nav, and form control targets first.
  3. Ask for component-level size tokens, not one-off CSS patches.
  4. Re-scan and confirm undersized count declines.

Technical handoff message

Copy and share this with your developer.

Scavo flagged Mobile Tap Targets (mobile_tap_targets). Please increase undersized interactive controls to meet at least 24px minimum and preferably 44px comfort size, then verify at mobile breakpoints.

If you are technical

  1. Set minimum touch-size tokens in design system.
  2. Increase padding/hit area for icon-only controls.
  3. Ensure spacing between adjacent targets to reduce mis-taps.
  4. Validate responsive breakpoints and state variants.
  5. Add UI regression checks for mobile target dimensions.

How to verify

  • Inspect computed control dimensions on mobile viewport.
  • Test tap accuracy on key journeys (menu, signup, checkout).
  • Confirm no critical controls drop below minimum size.
  • Re-run Scavo and check critical under-24px count.

What this scan cannot confirm

  • It estimates from measurable inline signals; some computed styles may be missed.
  • It does not fully model spacing/context exceptions.
  • It does not replace manual mobile usability testing.

Owner checklist

  • [ ] Assign owner for mobile interaction ergonomics.
  • [ ] Enforce target-size tokens in component library.
  • [ ] Include real-device tap QA for major releases.
  • [ ] Recheck after UI density or nav redesigns.

FAQ

Is 24px enough?

It is minimum threshold in this check. 44px is usually more comfortable for real users.

Can we keep small icon controls if visually required?

Increase invisible hit area/padding so interaction remains accessible.

Why info instead of pass/fail sometimes?

If too few measurable targets are detected, Scavo reports limited confidence.

What should we fix first?

Controls that trigger core actions: primary CTAs, menu toggles, form buttons.

Sources


Need a touch-target token spec for your current components? Send support your button/link component list.

More checks in this area

aria_labels

ARIA Labels Missing on Interactive Elements

When interactive elements don't have accessible labels, screen readers announce them as "button" or "link" with no context — forcing blind users to guess what each control does. Notable accessibility settlements include Bashin's $2M settlement and accessiBe's $1M FTC settlement (Accessibility.Works, 2024). Proper ARIA labels are foundational accessibility requirements under WCAG 2.1.

Open guide
color_contrast

Colour Contrast Too Low — Fails WCAG AA Requirements

Approximately 8% of males and 0.5% of females have colour vision deficiency — roughly 1 in 12 men worldwide (Vision Center). WCAG AA requires a minimum 4.5:1 contrast ratio for normal text. Low contrast also affects everyone reading on mobile screens in bright sunlight. With over 5,100 ADA web accessibility lawsuits filed in 2025 — a 20% increase from 2024 (EcomBack) — contrast failures are actionable legal risk.

Open guide
form_labels

Form Inputs Missing Associated Labels

When a label isn't programmatically associated with its input (via for/id or wrapping), screen readers don't announce what the field is for, and voice control users can't say "click email field." Form label errors are among the most commonly cited issues in accessibility audits, and they're straightforward to fix — just add matching for and id attributes.

Open guide