Touch target size: WCAG and mobile testing guide

Touch target size is the clickable or tappable area of a link, button, input, or other control. A target can look clear on a desktop and still be difficult to activate on a phone, especially when several small controls sit close together.

Test the rendered page at a narrow viewport before release. Measure the active area, not only the icon or text inside it, and review spacing wherever a mistaken tap could trigger the wrong action.

Touch target size checklist

Use this short pass on navigation, forms, toolbars, pagination, dialogs, and sticky controls:

1. Test the deployed page at a phone-sized viewport.
2. Measure the full interactive box for each important control.
3. Check small targets against the WCAG size and spacing rules.
4. Add padding to the control instead of scaling the icon.
5. Retest menus, validation states, cookie banners, and other content that appears after interaction.
6. Tap the main task on a real device before sign-off.

Target size is one part of interaction quality. A control also needs a clear accessible name and visible focus state, as covered in the keyboard accessibility testing checklist.

Know the WCAG target size requirements

WCAG 2.2 Success Criterion 2.5.8 is a Level AA requirement for pointer targets. It requires a target to be at least 24 by 24 CSS pixels, unless an exception applies. The exceptions cover sufficient spacing, an equivalent control, inline text, unmodified user-agent controls, and essential presentations.

The spacing exception matters. An undersized target can pass when a 24 CSS pixel diameter circle centered on its bounding box does not intersect another target or the equivalent circle around another undersized target. The W3C explanation of Target Size (Minimum) includes diagrams for testing that rule.

Success Criterion 2.5.5 Target Size (Enhanced) uses 44 by 44 CSS pixels at Level AAA. That larger size is a useful design target for frequently used controls, actions near a screen edge, and actions that are hard to undo.

You may also see 48 by 48 pixels in design guidance. Google’s accessible tap target guidance recommends about 48 device-independent pixels with space between targets. Treat 48 pixels as a usability recommendation, not as the wording of WCAG 2.5.8.

Measure the interactive area, not the icon

A 20 pixel menu icon can sit inside a 44 pixel button. The icon stays visually compact while the button provides a larger hit area. The element receiving the click is what matters.

This control has a small icon and a larger button box:

<button class="icon-button" type="button" aria-label="Open navigation">
  <svg aria-hidden="true" width="20" height="20" viewBox="0 0 20 20">
    <!-- icon path -->
  </svg>
</button>

.icon-button {
  display: inline-grid;
  inline-size: 44px;
  block-size: 44px;
  padding: 0;
  place-items: center;
}

Do not add a click handler only to the SVG. Keep the semantic button as the target so its full box receives pointer input and its accessible name remains available to assistive technology.

For text buttons and links that are not inside a sentence, use padding and minimum dimensions:

.primary-action,
.toolbar-action {
  align-items: center;
  display: inline-flex;
  justify-content: center;
  min-block-size: 44px;
  min-inline-size: 44px;
  padding-inline: 0.875rem;
}

The W3C C42 technique shows how min-height and min-width can also create sufficient clearance around smaller links. Test the result after responsive styles, font loading, and browser defaults have been applied.

Fix crowded mobile tap targets

Small controls become risky when another action is close enough to receive the same imprecise tap. Common problem areas include:

• A row of icon buttons in a card header.
• Pagination numbers with no gap.
• A close button placed against another dialog action.
• Checkbox or radio inputs whose label text is not clickable.
• Footer links compressed into several narrow columns.
• Sticky controls that overlap page content on a small screen.

Increase the active area first. If density still causes collisions, add layout gap or move secondary actions into a menu. For form controls, connect the visible label to the input so tapping the label activates the field. The website form testing checklist covers the rest of the form path.

Do not apply a global minimum height to every inline link. WCAG has an inline-text exception because links inside sentences reflow with the text. Review those links for readable line height and separation, then focus the target-size treatment on standalone actions and controls.

Test touch target size in every rendered state

Measure the initial page and the states a visitor can reveal. Open the mobile menu, trigger validation, expand accordions, and inspect the controls inside dialogs or cookie notices. WCAG applies to targets in new content that appears over the page, even when obscured targets underneath are outside the measurement at that moment.

A useful manual pass is:

1. Set the browser viewport to the smallest width you support.
2. Open each navigation or overlay used in the main task.
3. Inspect each important target with the browser’s element tools.
4. Read the rendered width and height from its box model.
5. Check any undersized control against the spacing exception.
6. Repeat the primary task with touch input on a real phone.

Keep target-size notes with the rest of the mobile website testing evidence. A screenshot proves layout, but it does not prove that the correct element received the tap.

Add a touch target size check to Playwright

Automate the critical controls whose expected size you own. Mark them with stable test identifiers, use a mobile viewport, and read their rendered bounding boxes. Playwright documents both mobile emulation and the `boundingBox()` measurement.

import { expect, test } from "@playwright/test";

test.use({
  hasTouch: true,
  viewport: { width: 375, height: 812 },
});

test("critical controls keep a 44px touch target", async ({ page }) => {
  await page.goto("https://example.com");

  const targets = [
    page.getByRole("button", { name: "Open navigation" }),
    page.getByRole("link", { name: "Start free audit" }),
    page.getByRole("button", { name: "Submit" }),
  ];

  for (const target of targets) {
    const box = await target.boundingBox();
    expect(box, "target should be visible").not.toBeNull();
    expect.soft(box!.width).toBeGreaterThanOrEqual(44);
    expect.soft(box!.height).toBeGreaterThanOrEqual(44);
  }
});

This test enforces a project standard for three controls. It does not evaluate every WCAG exception, judge whether spacing circles intersect, or prove that the whole page conforms. Keep the manual spacing review and real-device task in the release process.

Add the stable check to your website regression testing suite after the component dimensions are intentional. That turns a reviewed decision into a useful guardrail instead of a noisy site-wide rule.

Check touch target size with Slop Audit

Slop Audit renders a public page at a 375 by 812 mobile viewport and measures visible links, buttons, fields, and other controls. Its report counts controls below a 40 pixel width or height. It warns when that count exceeds the larger of two controls or 15 percent of the sampled controls, rounded to the nearest control. The result gives developers rendered geometry to review alongside mobile screenshots and other findings.

The 40 pixel check is a product heuristic, not a WCAG conformance test. Slop Audit does not evaluate every spacing exception, activate every state, inspect authenticated pages, or replace testing with people who use different input methods.

Run a Slop Audit on the deployed page before launch, then inspect the tap target finding with the accessibility checks before launch. Fix the critical task first and rerun the same URL to confirm the rendered dimensions changed.

Touch target size release checklist

Before shipping, confirm that:

• Important standalone controls meet the target size chosen by your team.
• Any control below 24 by 24 CSS pixels has a valid WCAG exception.
• Icon buttons use a larger semantic control instead of a tiny SVG hit area.
• Adjacent actions have enough clearance for an imprecise tap.
• Menus, dialogs, validation states, and cookie notices were measured after opening.
• The primary mobile task works on a real touch device.
• Automated checks and the review note state the threshold they enforce.

A useful sign-off records the viewport, target dimensions, applicable exception, and tested interaction. That evidence is easier to review than “mobile looks fine” and easier to rerun after the next CSS change.