Too Small to Hit: When Buttons and Links Block Mobile Users

A small “X” closes the cookie banner. A narrow magnifier opens search. Mobile navigation links sit tightly together. On desktop the layout looks clean; on a phone it takes three attempts.

That is not merely a visual detail. Small or crowded targets cause accidental activation, make interfaces harder for people with limited fine motor control, and damage the exact journeys meant to produce enquiries, purchases, or registrations.

WCAG 2.2 therefore added Success Criterion 2.5.8, Target Size (Minimum), at Level AA. In simplified terms, pointer targets should be at least 24 by 24 CSS pixels or have sufficient spacing from neighbouring targets. Defined exceptions include inline text links and controls whose size is determined by the user agent.

The operational question is not only: Does the element measure 24 by 24 pixels?

It is: Can a real person reliably activate it on a small, moving screen without triggering something else?

Where small targets become expensive

Mobile navigation

Hamburger menus, submenu arrows, language selectors, and account icons often share a narrow header. When only the visible icon is clickable rather than the surrounding area, the target is much smaller than it appears.

Common outcomes include:

• the menu does not open on the first attempt,
• the neighbouring link activates instead of the arrow,
• submenus close while the user corrects the mistake,
• visitors leave before finding the relevant service.

Forms

Privacy, newsletter, and terms checkboxes are often visually reduced. The text appears beside the input but is not connected to it, forcing the user to hit the tiny square precisely.

Calendar icons, password visibility controls, and file-removal actions create similar friction.

Cookie and consent banners

A dominant accept button beside a tiny reject link is not just a styling issue. The practical operability of the choices should be reviewed too. Small close icons, crowded toggles, and options hidden behind several layers deserve particular attention.

Sliders, carousels, and maps

Arrows, pagination dots, and map markers may look elegant but be difficult to activate. Dragging-only interactions are another concern: WCAG 2.2 requires functionality based on dragging to have a single-pointer alternative unless dragging is essential.

Tables and admin interfaces

Edit, delete, duplicate, and overflow actions are frequently compressed into a line of icons. An accidental activation here can change data rather than merely irritate the user.

Seven quick audit red flags

1. Only the visible graphic is active.
   A 16-pixel icon has no larger button area around it.

2. Targets sit directly beside each other.
   Two small controls effectively compete for the same touch area.

3. Labels are not clickable.
   A checkbox or radio button must be hit exactly.

4. Hover disguises the problem.
   Desktop styling appears generous while the actual active region remains small.

5. Overlays cover controls.
   Sticky headers, chat widgets, or consent banners obstruct navigation and form actions.

6. Zoom makes the layout collapse.
   At 200 percent, controls wrap, overlap, or become clipped.

7. Critical actions look like incidental text.
   Reject, back, remove, and cancel actions are small, faint, and crowded beside other choices.

How to audit target size properly

1. Inspect the real hit area, not only the artwork

Developer tools reveal the element box. The relevant measurement is the active link or button area, not the SVG or glyph inside it.

A 16-pixel icon inside a 44-pixel button can be very usable. A 24-pixel icon that is itself the entire target and sits beside another control may technically approach the minimum while remaining fragile in practice.

2. Test representative page types

Include at least:

• primary navigation and submenus,
• search,
• contact and checkout forms,
• cookie and consent dialogs,
• login and password recovery,
• maps, sliders, and galleries,
• tables, filters, and dashboards,
• embedded booking and chat widgets.

3. Use realistic conditions

A desktop mouse is not enough. Test:

• narrow mobile viewports,
• touch input,
• 200 to 400 percent zoom,
• device emulation and physical devices,
• one-handed use,
• larger system text,
• keyboard operation and visible focus.

The useful question is not whether a focused tester can hit the control. It is whether the action remains reliable during movement, fatigue, tremor, or reduced vision.

4. Document spacing and exceptions

WCAG 2.2 includes a spacing exception for some undersized targets. It should not become permission to build an entire interface from miniature links.

For deliberately small targets, record:

• why the exception applies,
• which neighbouring targets exist,
• how spacing was assessed,
• whether an equivalent larger control is available,
• how the real layout was tested.

5. Fix the design system

One-off patches help, but central rules are more durable:

• minimum height and width for buttons and icon buttons,
• sufficient padding,
• clickable labels,
• defined spacing between actions,
• responsive variants for dense toolbars,
• visible focus styles,
• alternatives to dragging,
• tests for sticky and overlay situations.

That turns accessibility from repeated cleanup into a default component behaviour.

What Website-Pflichtencheck would inspect

A technical and visual target-size review should look beyond isolated pixel measurements. It can examine:

• actual hit areas of links, buttons, and icons,
• spacing between adjacent targets,
• mobile navigation and submenus,
• forms, checkboxes, and upload actions,
• consent banners and close controls,
• sliders, maps, and drag interactions,
• zoom, reflow, and larger text,
• obstruction by sticky headers, chat, and overlays,
• keyboard focus and alternative operation,
• shared design-system rules,
• automated regression checks and documented manual exceptions.

The result should distinguish between controls that are merely inconvenient and those that block completion or trigger harmful mistakes.

Larger touch targets do not require a visually clumsy interface. Strong design separates visual size from active area: an icon may remain delicate while the button around it is generous and dependable.

When an important action works only for someone who can tap calmly, precisely, and with perfect vision, it is not robustly designed.

Note: This article is a technical overview and not legal advice.