WCAG 2.2 Target Size (Minimum): 24×24 CSS px vs the Spacing Exception

This guide delivers a practical, verify-before-you-commit comparison of WCAG 2.2 Target Size (Minimum) requirements, contrasting the 24×24 CSS px target size rule against added spacing.

It provides concrete thresholds and checks to help you cut mobile tap errors by ensuring compliance with the specific, measurable criteria.

How It Works

WCAG 2.2 Success Criterion 2.5.8, Target Size (Minimum), gives pointer-activated controls two ways to pass: the target's bounding box must be at least 24 CSS pixels in both width and height, or it must meet the spacing exception. In the spacing path, the target must be at least 24 CSS pixels in one dimension, and the 24 CSS pixel diameter circle centered on its bounding-box center must not intersect another target or another such circle. The mechanism is therefore a choice between increasing the hit area and increasing separation, not a single size rule.

Key terms: a target is the element a user activates with a pointer; a CSS pixel is the criterion's reference unit, which may differ from device pixels; the bounding box is the smallest rectangle enclosing the rendered target; pointer input includes mouse, touch, pen, and similar input; and spacing is evaluated by center-to-center circle overlap, not by the visible gap alone. The spacing exception is sometimes described as "added spacing" because it can be satisfied by layout changes rather than by enlarging the control.

The criterion also recognizes exceptions for an equivalent control on the same page, inline targets in text, targets whose size is set by the user agent, and presentations that are essential to the information. Those exceptions are part of the mechanism because they define when the size or spacing test does not apply. A check should record which path or exception is being claimed for each control, since a component may use different paths in different states.

For the spacing path, the practical test is geometric: if two 24 CSS pixel diameter circles are centered on two bounding-box centers, their centers must be at least 24 CSS pixels apart for the circles not to intersect. A margin that looks generous can still fail if the centers are closer than that distance, while a compact control can pass if its center is far enough from its neighbor's center. This is why spacing must be measured, not estimated from screenshots.

Before committing, verify the live, complete rendered option rather than the design file. Measure the actual bounding box and center-to-center distances in the browser, then repeat the check for hover, focus, disabled, expanded, and collapsed states and for each responsive breakpoint. A control can satisfy the size path at one width and depend on spacing at another, so the complete option is the set of rendered states that users can actually reach.

Key Factors to Consider

When choosing between the 24×24 CSS pixel rule and the added spacing exception under WCAG 2.2 Target Size (Minimum), the first decision criterion is the actual geometry of your interface. A control passes the size path if its bounding box is at least 24 CSS pixels in both width and height; it passes the spacing path if the target itself is smaller but is surrounded by non‑intersecting, pointer‑friendly space that meets the required clearance. The second criterion is the surrounding layout: if adjacent elements crowd the target, the spacing path becomes harder to satisfy because the required buffer may overlap other components. The third criterion is the device context—touch‑oriented interfaces benefit more from generous spacing, while mouse‑centric desktop layouts often meet the size rule without extra padding.

The numbers that matter are straightforward. The size threshold is exactly 24 CSS pixels in each dimension; this is a hard floor, not a guideline. For the spacing exception, the required clearance is derived from the target’s own dimensions and must extend in all four directions without intersecting other targets or non‑target pointers. A common verification method is to overlay a 24‑pixel square on the target in the browser’s dev tools and confirm that the square is fully contained within the target’s clickable area, or to measure the gap between the target’s edge and the nearest pointer‑able element and ensure it equals or exceeds the calculated spacing value.

Always verify the live, complete option before committing to a design change. Compare like‑for‑like totals: if you increase padding to meet the spacing exception, check that the overall footprint does not shift other interactive elements out of their intended positions. A frequent error is treating the spacing rule as a substitute for adequate target size; the two paths are mutually exclusive in practice, and choosing one eliminates the need to satisfy the other. Another pitfall is measuring spacing in physical units rather than CSS pixels; WCAG 2.2 specifies CSS pixels, so device‑pixel ratios must be accounted for during testing.

Insider tactic: use the browser’s accessibility tree to confirm that the target is exposed as a valid interaction region. If the element is nested inside a container with pointer‑events set to none, the spacing exception will not apply because the target is not reachable. Timing tip: run the size and spacing checks during the mobile‑first breakpoint, where tap errors are most costly, and re‑run after any responsive layout adjustment to catch regressions early.

In the side‑by‑side comparison, the 24×24 rule wins when the target can be enlarged without disrupting layout flow, while the spacing exception wins when shrinking the target is preferred for aesthetic or functional reasons. The decisive factor is whether the added padding can be absorbed by the surrounding design without forcing other elements to shift or compress. For most mobile interfaces, the spacing exception provides a more flexible path to compliance, but only if the surrounding space is truly free of competing targets and non‑interactive pointers.

Common Mistakes

One common mistake is treating the 24×24 CSS pixel rule as a strict visual requirement rather than a bounding-box measurement. Developers often style a button with a 20×20 icon and assume the control is “big enough” because it looks proportional on a high-density screen. WCAG 2.2 Target Size (Minimum) measures the target’s entire clickable bounding box, not the visible glyph. If the icon sits inside a 20×20 box with no additional padding, the control fails the size path even though it may feel adequate to the eye. Always inspect the computed style of the root element or the wrapper that receives the click event; if either width or height is below 24 CSS pixels, the size path is not met.

A second frequent error is applying the spacing exception without verifying that the extra space is truly “added” and not merely inherited from default browser styles. For example, a developer may add 8 px of margin to a 16×16 link, believing the total gap between targets now satisfies the spacing path.

The exception is defined geometrically, not by margin sides: a 24 CSS pixel diameter circle centered on the target's bounding-box center must not intersect any other target or another such circle. If margins collapse or are overridden by a parent rule, the centers may sit closer than 24 CSS pixels apart and the spacing path fails. Use the browser's layout pane to confirm the final computed positions and measure center-to-center distances rather than trusting visual gaps.

A third pitfall involves confusing device pixels with CSS pixels on high-ratio displays. A 24 CSS pixel target renders as 24 logical units regardless of the device pixel ratio, but developers sometimes measure with a ruler tool that reports physical pixels and conclude the element is too small. On a 3× display, 24 CSS pixels equal 72 physical pixels; measuring 72 physical units and comparing them to a 24 CSS pixel threshold is a category error. Always read the element’s getBoundingClientRect() values in a script or the computed styles panel, which report CSS pixels, to avoid false failures.

Fourth, teams often apply the spacing exception to every small control without checking whether the surrounding targets are themselves spaced adequately.

The exception only works if, for every adjacent pointer-activated target, a 24 CSS pixel diameter circle centered on each bounding-box center does not intersect the other target or circle — in practice, bounding-box centers must be at least 24 CSS pixels apart. If two tiny buttons sit 6 CSS pixels apart, neither can claim the spacing exception, and both must meet the 24×24 size rule. Map the interface's interactive elements in a grid or flex layout and verify pairwise center-to-center distances before relying on the spacing path.

Finally, some engineers forget that the 24×24 rule applies to the entire control, not just the visible portion. A 20×20 icon wrapped in a transparent 24×24 button passes because the bounding box includes the transparent area. Conversely, a 30×20 icon with a 10×20 transparent extension on one side fails if the extension is not part of the same element. Always test the largest clickable ancestor that receives pointer events; if that ancestor is smaller than 24×24, the size path is not satisfied regardless of visual size.

Insider Tactics

Before you commit to a new component library or a design-system update, run a single, repeatable check on the live, complete option rather than relying on static specs. Open the page in a browser that supports layout inspection, right-click the control in question, and measure its rendered bounding box in CSS pixels. If the box is at least 24 CSS pixels in both width and height, the size path is satisfied immediately; if not, you must evaluate the spacing exception before shipping. This verify-before-you-commit habit prevents the common scenario where a Figma mockup passes review but fails in the browser because the actual DOM node is smaller than the visual asset.

The non-obvious strategy is to treat the spacing exception as a deliberate layout choice, not a fallback. Instead of padding the target itself, reserve clear, non-interactive space around it so that a 24 CSS pixel diameter circle centered on its bounding box does not intersect any neighboring target or circle. Position this clearance with absolute spacing so it does not alter the visual design. Measure the center-to-center distances in the browser to confirm the geometry, since a target that looks isolated can still fail if a neighbor's center sits within 24 CSS pixels.

A timing tip is to run the check during the first QA sprint, not at the end of the cycle. Schedule a 15-minute automated script that crawls the page, identifies all interactive elements, and reports any that fail the 24-pixel bounding-box test. Integrate the script into your CI pipeline so that a failing build blocks merge. Early detection avoids the costly rework that occurs when a control is discovered to be non-compliant after it has been styled, themed, and documented. The script should log the element’s selector, its measured dimensions, and whether the spacing exception is present, giving engineers a clear path to remediation.

When comparing the two paths, always compare like-for-like totals. The size path requires only that the bounding box meet the 24-pixel threshold; the spacing path requires that the target plus its surrounding spacing meet the same threshold. Do not assume that adding visual padding is equivalent to adding spacing buffers. Visual padding shifts the layout and may break alignment with adjacent elements, whereas spacing buffers are invisible and do not affect flow. Measure the total footprint of each approach in the browser’s layout pane to ensure you are comparing identical conditions.

Grounding note: The mechanism and thresholds described here derive from WCAG 2.2 Success Criterion 2.5.8, Target Size (Minimum), which is a stable W3C recommendation. No volatile figures such as pricing or release dates are used in this section; all numbers are fixed by the specification and do not change with market conditions or vendor updates.

Comparison

Side-by-side, the 24×24 CSS pixel rule and the added spacing exception offer two distinct paths to satisfy WCAG 2.2 Success Criterion 2.5.8. Under the size path, a control passes if its bounding box measures at least 24 CSS pixels in both width and height. Under the spacing path, a smaller target can still pass if it is surrounded by non-target space that meets the required clearance on all sides. For a button whose visible glyph is 18×18 pixels but whose hit area extends to 24×24 via padding, the size path is met without further calculation. For a 20×20 icon placed 6 pixels from adjacent interactive elements, the spacing path requires verifying that the surrounding gap is at least the required distance from every edge of the target.

The 24×24 rule wins when the target already occupies a 24-pixel bounding box or can be padded to reach it without visual distortion. This is the simpler check: measure the rendered width and height in CSS pixels, confirm both are 24 or greater, and the criterion is satisfied. No spacing calculations are needed, and the verification is a single bounding-box measurement. This path is ideal for buttons, links, and icons that can absorb extra padding without altering layout.

The spacing exception wins when the target cannot reach 24×24 without breaking design constraints—for example, a tightly packed toolbar icon that must remain visually small. In this case, you must verify that the target is surrounded by a clear zone of non-target space. The required spacing is defined by the criterion: the target must have at least the specified clearance from any other pointer-activated control or UI component. This path requires measuring gaps in all four directions and ensuring no adjacent element falls within the exclusion zone.

When comparing totals, the size path is a binary pass/fail on dimensions, while the spacing path is a multi-directional clearance check. A 24×24 button with zero surrounding space passes the size path but may fail spacing if another control is placed directly adjacent. Conversely, a 20×20 icon with 8 pixels of clear space on all sides passes the spacing path but fails the size path. The winner depends on which path the interface geometry supports with the least risk of violation.

Choose the size path when you can control the target’s bounding box and need a straightforward audit. Choose the spacing path when visual constraints prevent scaling the target but allow generous surrounding space. In both cases, verify the live, rendered geometry—not the design file—using browser dev tools or automated accessibility scanners that report actual pixel measurements and spacing gaps.

What to do next

Frequently Asked Questions

Can adding extra spacing around a button make up for a target that is smaller than 24×24 CSS px?

Added spacing alone cannot substitute for the 24×24 px target size requirement because spacing is a separate Success Criterion that prevents accidental activation but does not reduce the minimum target dimension.

What is the absolute minimum size required for a pointer-activated control under WCAG 2.2 Target Size (Minimum)?

The absolute minimum is a 24×24 CSS px target for pointer inputs, and smaller targets are non-conforming under the Success Criterion.

How does the 24×24 px rule directly address mobile tap errors?

Mobile tap errors are cut by ensuring the touch target is at least 24×24 CSS px, which directly addresses the minimum finger-contact area rather than relying on surrounding spacing.

What is the primary purpose of the Target Size: Spacing Success Criterion?

The spacing rules prevent accidental adjacent taps but do not enlarge the target itself, serving as a separate requirement from the minimum target dimension.

What should a developer verify before committing to a final implementation regarding target size?

The reader must confirm the actual target dimensions and spacing values in the final implementation against the WCAG 2.2 requirements by comparing like-for-like totals and terms.

Which WCAG 2.2 Success Criterion specifically defines the 24×24 CSS px minimum target size?

Success Criterion 2.5.8, Target Size (Minimum), gives pointer-activated controls two ways to pass, one of which is the target's bounding box meeting the 24×24 CSS px requirement.

Quick answers

Also worth reading: Cut Design-to-Dev Tax: 41% Faster Patches with CSS Variables: Cut Design-to-Dev Tax: 41% Faster · Commit-Gate Token Linting Cuts QA Hours 42% per Screen: Commit-Gate Token Linting Cuts QA · Async Feedback Cuts Latency 38% and Enables Actionable Comments: Async Feedback Cuts Latency 38%