Mobile Touch Targets: Size, Spacing, and WCAG 2.2

The barrier nobody screenshots

Most accessibility findings can be shown in a screenshot. Low contrast text, a missing label, a broken layout. Touch target problems are different. The page looks fine. The button is just slightly too small and slightly too close to its neighbor, and a meaningful share of visitors keep missing it.

The visitors who pay the most for tiny targets are people with motor disabilities, including tremor and limited dexterity. After them comes almost everyone else at some point. Large thumbs, a moving train, gloves, one hand holding a coffee or a child. A target that demands precision taxes them all.

On business sites the smallest targets tend to guard the most important actions. Phone icons in headers. Close buttons on popups. Carousel dots. Plus and minus quantity buttons in carts. Inline links packed into footers. None of these look broken in a design review, which is why they survive redesign after redesign until someone measures them.

What the standards actually say

WCAG 2.2 added Success Criterion 2.5.8, Target Size Minimum, at the AA level. It asks pointer targets to be at least 24 by 24 CSS pixels, with specific exceptions. The most useful exception is spacing. A smaller target can pass if it sits inside its own undisputed 24 pixel circle, meaning its neighbors are far enough away.

WCAG 2.1 has the stricter Success Criterion 2.5.5, Target Size Enhanced, at the AAA level, asking for 44 by 44 pixels. Platform guidance lands near that number too. Apple recommends 44 by 44 points for touch controls, and Android material guidance recommends 48 by 48 density independent pixels.

The practical reading for a business site is simple. Treat 24 pixels as the floor the standard asks for, and treat 44 to 48 pixels as the working target for anything visitors tap often, especially calls to action, navigation, and form controls.

Where tiny targets hide

The recurring offenders are remarkably consistent across audits.

Icon only buttons come first. A 16 pixel social icon or a 20 pixel close button renders at exactly its icon size unless someone adds padding. The icon can stay small. The tappable area around it cannot.

Inline links in dense text come second, especially stacked link lists in footers where the lines sit tight and every line is a link. Here line height and spacing do the work.

Form controls come third. Native checkboxes and radio buttons render small, which is one more reason to associate a real label with each control. A correctly associated label becomes part of the tap target, so the visitor can tap the word instead of the tiny box.

Carousel dots, pagination arrows, star ratings, and quantity steppers round out the list. Each is small by visual convention, and each can carry a larger invisible hit area.

Fix the hit area, not the artwork

The good news is that target size is mostly a CSS problem with a component level fix.

The visual element and the interactive area do not have to match. Padding on the button enlarges what responds to a tap without changing what the design shows. A minimum height and width on the shared button and icon button components fixes every instance at once. For inline icons, a pseudo element can extend the clickable area beyond the rendered glyph.

Spacing is the other half. Two adequately sized buttons placed flush against each other still produce mistaps at the boundary. Margins between adjacent targets matter as much as the size of each target, and the WCAG 2.2 spacing exception formalizes exactly that.

As with most audit patterns, the instance count is misleading. Three hundred undersized targets across a site usually trace back to a handful of shared components, and the fix is a few lines in each.

Test where your visitors actually are

Desktop browser testing with a mouse hides this entire category. A pointer is precise. A thumb is not.

Open the key pages on a real phone. Try to complete the actions that matter commercially. Call, get directions, open the menu, close the popup, add to cart, submit the form. Use your less dominant hand for an honest approximation of imprecision. Every mistap you produce, some share of your visitors produces constantly.

Browser device emulation helps for measuring. The inspector can confirm the computed size of a control in CSS pixels, which turns the question from looks small into a measurable 20 by 20.

How to verify the fix

Set the floor in the design system. A minimum interactive size on the shared button, icon button, and link components, plus minimum spacing between adjacent targets. Then confirm the floor holds on the templates that matter, by measurement, not by eye.

Then re scan. Automated checks can flag targets below the minimum size on the rendered page and catch regressions when components change later.

A free scan takes about a minute and flags detectable issues on the page you care about most. The full audit report shows each finding with screenshots and code context, so a developer can fix the shared component instead of hunting through pages.

No scan certifies legal compliance, and this article is not legal advice. What target size work does is remove a constant source of friction for mobile visitors, including the ones trying to call or buy, and it supports remediation toward WCAG 2.1 and 2.2 AA in a way you can demonstrate. Our compliance checklist places touch targets alongside the other mobile findings worth fixing first.