Target Size Pass Rate: Catching Clickable Boxes Too Small to Use

2026-10-29

A checkout button can be enormous while the quantity minus button beside it is 16 pixels wide. Reporting a site level average for target size hides that completely. The metric only works when it is counted the way users fail: one small, repeated control at a time.

WCAG 2.2 made this measurable. Criterion 2.5.8, target size minimum, set the AA floor at 24 by 24 CSS pixels, subject to spacing and inline exceptions. Now the argument is about counting honestly.

Define the metric before you dashboard it

Pass rate equals compliant targets divided by all in scope targets, counted from rendered pages, not design files. In scope means links and controls, minus the standard's own exceptions: inline links in text, targets whose size is essential to the content, and cases where an equivalent larger control exists for the same action.

Decide your threshold stack up front and write it on the report: AA at 24 pixels as the compliance line, 44 pixels as the quality line your team designs to. Mixing the two in one number produces a metric that is neither a legal measure nor a design guide.

Where the failures concentrate

Icon toolbars are the classic offender: edit, duplicate, and delete icons packed at 16 to 20 pixels with no padding counted as part of the target. Footer and pagination links follow, small text links with line height doing no work for touch. Then the cart and checkout controls, steppers and remove links, small precisely where motor difficulty costs money.

Count by component and template, and the fix list writes itself. One stepper component fix can move the pass rate of an entire store section. That is the advantage of this metric over page level auditing: it points at shared code, not at individual pages to patch.

Spacing can save a small target, sometimes

Criterion 2.5.8 allows a target under 24 pixels if undersized targets are positioned so a 24 pixel circle centred on each does not overlap another target. Dense icon rows rarely satisfy that, which is the point. The exception exists for genuinely constrained layouts, not for toolbars designed small on purpose.

Do not let the exception become the reporting trick. Count how many of your passes rely on the spacing rule and report that share. A pass rate propped up by exceptions is a fragile pass rate, and an auditor will count it their way, not yours.

Track the trend, not the snapshot

Report pass rate monthly by template family: header, product card, cart, checkout, footer, account. A single redesign can regress one family while improving the total, and the total is the number that will be quoted back to you in a complaint or a filing.

Pair it with a failure count in absolute terms for your highest traffic templates. Percentages reassure. Absolute counts on a checkout stepper used 40,000 times a month concentrate minds in a way 97.2 percent pass never will.

Frequently asked questions

What target size does WCAG 2.2 require?

At Level AA, criterion 2.5.8 requires targets of at least 24 by 24 CSS pixels, with exceptions including spacing, inline text links, and essential sizes. Level AAA criterion 2.5.5 sets 44 by 44 pixels. Many design systems target 44 as a quality goal.

Does padding count toward target size?

The target is the pointer activation area, so padding that is part of the clickable element counts. Visual icon size alone does not. A 16 pixel icon inside a 28 pixel button is a 28 pixel target, provided the whole area activates.

Why measure per template instead of per page?

Because failures live in shared components. One undersized stepper or toolbar, reused across thousands of pages, is a component fix. Page level averages hide it, and page level fixes waste effort repeating the same repair.

Are inline text links exempt?

Yes, links within sentences and blocks of text are an exception under 2.5.8, because their size is governed by the text itself. Standalone navigation, footer, and list links are not automatically exempt and should be counted.