Touch target size and WCAG 2.5.8

Success criterion 2.5.8 Target Size (Minimum) is Level AA and new in WCAG 2.2. It says the target for pointer inputs must be at least 24 by 24 CSS pixels. The target is the area that responds to the click or tap, not the icon drawn inside it, so a 16 pixel icon in a button with padding around it can pass comfortably.

CSS pixels are the unit your layout already uses, so this is measured in the same numbers you write in your stylesheet, whatever the device pixel density.

Five exceptions are written into the criterion, and two of them account for most of the controls that look too small but conform:

• Spacing. An undersized target passes if a 24 pixel circle centred on it does not touch the circle of any other target. Room around a control counts, so a row of small icons with generous gaps can pass where the same icons packed together cannot.
• Inline. A link inside a sentence is exempt, because its size follows the line height of the text around it.
• Equivalent. The same function is available through another control on the page that is big enough.
• User agent control. The browser decides the size and you have not changed it.
• Essential. The presentation is required, which covers cases like a pin on a map.

The WCAG 2.2 checklist covers the other criteria that arrived with 2.2.

We scanned the homepages of 342 well-known US organisations in June and July 2026, across online retail, health systems, federal government and banking. On target size:

• 69 of the 342 homepages, or 20%, had at least one undersized control. Only colour contrast was more common, at 30%.
• Those 69 sites carried 509 undersized controls between them, which is 18% of every failing element we found across all rules.
• The median affected site had 4 of them. The worst had 57.
• It is usually a handful rather than a systemic problem: 14 sites had exactly one, 30 had between two and five, and only 5 had more than twenty.

By sector, the share of homepages with at least one undersized control was 33% of online stores, 21% of government sites, 12% of hospitals and 12% of banks. Retail leading is consistent with the rest of that study, where stores came last on every measure. The full comparison is in web accessibility by industry.

The number that surprised us is how often target size sits on an otherwise clean page. Of the 69 affected homepages, 18 had no other WCAG failure at all. Their contrast was fine, their images had alt text, their buttons had names, and the one thing standing between them and a clean automated result was a control a few pixels too small.

Another way to see it: 38 of the affected sites had no critical issues, the kind that can hard block a screen reader user, yet still failed this. Teams that have done the obvious accessibility work are exactly the ones likely to be caught by 2.2's newest rule, because it postdates the checklist they worked from.

Target size and contrast also travel together. 43% of the affected sites failed both, which fits: a cramped icon row and low contrast tend to come from the same design pass.

Three patterns account for most of what we saw. A row of social or utility icons in a header or footer, sized to the icon rather than to a tappable box. Close buttons on cookie banners and modals, which are often drawn small on purpose. And pagination or filter controls, where a dense grid of numbers leaves no room between targets.

The fix is usually padding rather than a bigger icon. Increasing the clickable box with padding, or a pseudo-element that extends the hit area, keeps the design identical while the target grows. Where a design cannot give a control more room, the spacing exception is a legitimate route: leave enough space around it that nothing else is within reach of a stray tap. Both are cheaper than they sound, and neither requires redrawing anything.

Keyboard users are a separate audience with a separate rule, so a control that is small but reachable by tab still needs to satisfy keyboard operation on its own terms.

The two large public studies of web accessibility do not report it. WebAIM's annual survey of a million home pages counts six error types, all of them WCAG 2.1-era, and target size is not among them. The HTTP Archive's Web Almanac 2025 accessibility chapter covers focus indicators, contrast, labels and landmarks, but does not measure pointer target sizes either. Both are excellent sources for what they do cover, and our statistics page collects their figures.

Native platform guidance has asked for more than the web for years. Google's Android accessibility help tells developers to make touch targets "at least 48dp", double what WCAG asks for in CSS pixels. WCAG 2.2 set a lower bar deliberately, as a floor that existing designs could reach.

• Sample. 342 homepages that returned a real page, from four curated sector lists: online stores, US health systems, US federal government, and US banks and financial services. Scanned in June and July 2026. These are recognisable organisations rather than a random or traffic-ranked sample, so read it as a snapshot of well-known sites.
• Engine. axe-core, run against the WCAG 2.x A and AA rule sets including WCAG 2.2, in a real Chromium browser after the page was scrolled and allowed to settle. A control counts here when axe reported it as failing the target-size rule.
• Viewport. Pages were rendered at a desktop viewport of 1280 by 720. A phone-width layout can produce different controls and different sizes, so these figures describe desktop renders rather than mobile ones.
• Scope. Homepages only. Checkout, booking and account flows sit behind the homepage and were not tested.
• Borderline cases. The spacing exception depends on the distance between neighbouring targets, so a control an automated check counts can still conform once a person reads the criterion against the layout. Treat the counts as a floor for further review rather than a verdict.
• Not captured. We stored counts per rule, not the element type or the measured size of each control, so we cannot break these numbers down by button, link or icon.
• Not a compliance audit. Automated failures are not a legal determination. We report aggregate figures and name no organisation.