TL;DR: WCAG 2.2's SC 2.5.8 (Level AA) requires interactive targets to be at least 24×24 CSS pixels, while the stricter SC 2.5.5 (Level AAA) asks for 44×44. Five documented exceptions (spacing, equivalent, inline, user agent control, and essential) cover legitimate cases where a smaller target is still compliant. Read them before assuming every small icon is automatically a violation.
Most "accessibility checklist" coverage treats this as a native-mobile-app rule, checked once in a build and forgotten. That misses the point: SC 2.5.8 is written against pointer input in general, and most real failures show up in responsive web layouts: a close (×) button at 16px, pagination links packed edge to edge, or an icon-only toolbar button with zero padding. It's CSS layout math, not platform math.
This piece covers what the criterion actually says, the five exceptions most summaries skip, how to measure a target the spec's way, CSS fixes for undersized targets, and where the web platform hits a ceiling that makes a native build, a conversation for a mobile app development team, the right next step.
SC 2.5.8, Target Size (Minimum), is Level AA and new in WCAG 2.2: a pointer-input target must be at least 24 by 24 CSS pixels, except where one of five conditions applies. SC 2.5.5, Target Size (Enhanced), is Level AAA and sets a stricter 44×44. Almost every commercial site targets AA, which makes 24×24 the number that governs most production work; 44×44 is the enhancement tier, not the baseline.
The "CSS pixel" qualifier matters: it's a logical unit, what width: 24px means in a stylesheet, not a physical device pixel. A high-DPI screen may render one CSS pixel as three physical pixels, but the target is measured in the logical unit the layout engine uses. You don't need device-pixel-ratio math; your computed CSS box, padding included, just needs to measure 24×24.
Most summaries mention one exception, spacing, and stop. There are five, and knowing all of them separates a real audit from a guess.
Eyeballing a target's visible icon is the most common measurement mistake. The criterion cares about the full interactive box, padding included, not just the glyph or image inside it. A 16px icon with 4px of padding on every side has a 24×24 hit area and passes; the same icon with zero padding fails, even though the artwork looks identical.
Browser DevTools' box model inspector checks this fastest: select the element and read the content-plus-padding dimensions, not the bounding box of a child SVG or icon glyph. If a ::before or ::after pseudo-element expands a small target's hit area, inspect that pseudo-element's own box too: that's the one that has to clear 24×24, and it's easy to size it wrong while the visible icon still looks correct.
Most target-size failures are fixable in CSS alone, without touching the visual design.
/* Bad: a 16px icon button with no extra hit area */
.icon-btn {
width: 16px;
height: 16px;
}
/* Good: visual size stays small, hit area meets 24x24 via padding */
.icon-btn {
width: 16px;
height: 16px;
padding: 4px;
box-sizing: content-box; /* adds 8px total: 16px + 4px + 4px = 24px */
}When padding would disturb a tight layout, a pseudo-element hit-area expansion keeps the visual footprint untouched while giving the browser a larger clickable region:
.icon-btn {
position: relative;
width: 16px;
height: 16px;
}
.icon-btn::before {
content: "";
position: absolute;
inset: -4px; /* expands the hit area to 24x24 without resizing the icon */
}Two things worth pre-empting: touch-action controls gesture behavior (panning, zooming) and has nothing to do with target size; setting it doesn't satisfy 2.5.8. And flexbox or grid gap between small controls can satisfy the spacing exception without resizing anything, but only if the gap actually clears the 24px circle test, so measure it rather than assume.
The criterion isn't scoped to things labeled "button." It applies to any pointer-operable control: custom checkboxes and radio buttons styled with CSS instead of native elements, icon-only buttons, close (×) buttons in modals and toasts, pagination packed into a thin strip, inline links crammed into dense nav, and per-row action icons in a data table. Any of these under 24×24 CSS pixels needs one of the five exceptions to justify its size. Otherwise it's a failure, regardless of what the component is called in the design system.
No. Treating it as one is the most common misreading of this criterion. SC 2.5.8 is written against pointer input, covering mouse and trackpad as much as touch. A desktop user with a motor impairment, a trackpad user without fine-grained precision, or someone on a touch-enabled laptop are all in scope. The spec has no device-type carve-out: a target too small for a thumb is often too small for an imprecise mouse click too. The failure mode isn't unique to touchscreens; it's unique to small hit areas.
CSS layout gets you far toward compliant touch targets: 24×24 CSS pixels, padding, pseudo-element tricks, spacing-exception gaps. But there's a ceiling. Once a product needs genuine native touch interaction, such as haptic feedback tied to a gesture, resolving conflicts with OS-level gestures (edge-swipe navigation, multi-finger shortcuts), reading hardware sensors, or exposing accessibility semantics through a platform API that goes further than ARIA can in a browser, that's no longer a layout decision. It's a native-app decision.
At that point, the right move is handing the problem to a mobile app development team who can build against native accessibility and gesture APIs directly, instead of stretching web-platform primitives past what they're built for. Recognizing that boundary early, before a web-first team spends weeks fighting a limitation a native SDK solves outright, is part of getting touch-interaction compliance right.
<button>.WCAG 2.2 Level AA, which includes SC 2.5.8, is the technical standard most US ADA Title II/III expectations point to in practice, and EN 301 549 in the EU references the same WCAG levels directly. Neither is a compliance guarantee by itself, and this isn't legal advice, but meeting 2.5.8 is the baseline auditors check first.
Both exist, at different levels. SC 2.5.8 (Minimum) is Level AA and requires at least 24×24 CSS pixels. SC 2.5.5 (Enhanced) is Level AAA and requires 44×44. Most commercial sites target AA, so 24×24 is the number to design against; 44×44 is the stricter enhancement, not the baseline.
No. It only applies if an undersized target has enough empty space around it that a 24px-diameter circle centered on it doesn't touch the circle of any neighboring target. Dense UI, including toolbars, table row actions, and icon-only nav, usually can't satisfy that radius.
Reflow (SC 1.4.10) requires content to work without horizontal scrolling at 400% zoom, and that reflow can quietly shrink a once-compliant target as padding and margins compress. Test target size at the zoom levels your layout actually supports, not just at 100%.
Native, unstyled controls fall under the user agent control exception: unmodified by your CSS, the browser's default rendering is exempt. Apply custom styling that changes the visual or hit-area size, and that exception no longer applies.
Open DevTools, select each interactive control, and read the computed box model, padding included, not just the visible icon. Flag anything under 24×24 not covered by one of the five exceptions, then re-check at 400% zoom, since reflow is where compliant-looking targets most often slip under the line.