Success Criterion 2.5.8, Target Size (Minimum), is one of the new Level AA criteria introduced in WCAG 2.2. It is also one of the most misunderstood. In every audit I have run since WCAG 2.2 became the active standard, I find developers who have heard of target size requirements but have a fundamentally incorrect understanding of how to measure compliance.
Let me walk through exactly what the criterion requires, where the confusion comes from, how to measure it correctly, and what to actually fix when you find a failure.
What SC 2.5.8 Actually Says
The full criterion reads:
The size of the target for pointer inputs is at least 24 by 24 CSS pixels, except where: the target offset is at least 24 CSS pixels on all sides; the target is in a sentence or its size is otherwise constrained to the line-height of non-target text; a particular presentation of the target is essential or legally required; and the target is determined by the user agent and not modified by the author.
There is a lot happening here. Let me break it down into plain language.
The 24×24 CSS Pixel Minimum
The base requirement is simple: interactive targets — buttons, links, checkboxes, radio buttons, any tappable or clickable UI element — must be at least 24×24 CSS pixels in size.
Note: this is CSS pixels, not physical pixels. On high-DPI (Retina) screens, a CSS pixel is rendered as multiple physical pixels. The measurement is always in CSS pixels.
/* Failing: target smaller than 24x24 CSS pixels */
.icon-btn {
width: 20px;
height: 20px;
}
/* Passing: meets 24x24 minimum */
.icon-btn {
min-width: 24px;
min-height: 24px;
}
/* Best practice: exceed the minimum with padding */
.icon-btn {
width: 16px;
height: 16px;
padding: 10px; /* Makes actual tap area 36x36 */
}
/* The 44x44 AAA target from WCAG 2.1 — best practice for mobile */
.btn-touch {
min-height: 44px;
min-width: 44px;
}
The Spacing Exception — The Part Everyone Gets Wrong
Here is where the confusion enters. SC 2.5.8 includes an exception: even if the target itself is smaller than 24×24 CSS pixels, it passes the criterion if the target offset — the space between the target's bounding box and any other target or content — is at least 24 CSS pixels on all sides.
This means a 16×16 pixel icon button can technically pass SC 2.5.8 if it has at least 24 CSS pixels of clear space around it with no other interactive targets or content within that space.
Visualizing the Offset
Imagine drawing a 24×24 circle centered on the geometric center of the target. If that circle does not overlap any other target or the spacing boundary of any other target, the target passes — regardless of its own size.
/* Button that's smaller than 24x24 but may pass via spacing */
.small-btn {
width: 16px;
height: 16px;
/* Needs 24px of clear space on all sides from other targets */
margin: 28px; /* This might work if nothing else is nearby */
}
/* More reliable approach: use padding to expand the tap area */
.small-icon-btn {
width: 16px;
height: 16px;
padding: 14px; /* Total area: 44x44 — exceeds 24x24 AND 44x44 */
/* No spacing concerns because the tap area itself is large enough */
}
The Exceptions in Detail
Exception 1: Inline Text Links
Links that appear within a paragraph of text — inline links — are exempt. The criterion acknowledges that controlling the size of an inline link is inherently constrained by the surrounding text's line height and font size. If you tried to make every inline link 24×24 pixels, it would break the text flow entirely.
This exception applies only to genuinely inline links — links that appear in the flow of a sentence. A row of standalone navigation links does not qualify as inline text just because they are on the same line.
Exception 2: Essential or Legally Required Presentation
If the specific visual presentation of a control is legally required or functionally essential — for example, a map control where the clickable points are necessarily small to represent geographic accuracy — the criterion does not apply.
Exception 3: User Agent Controls
If the browser or operating system renders and controls the interactive element — a native <input type="date"> calendar picker, for example — and the author has not modified its size, the element is exempt. Once you style it with CSS, the exemption ends.
How to Measure Target Size Correctly
The most common measurement mistake I see is developers opening DevTools, inspecting the element, and checking the "Computed" dimensions of the element itself. This is often wrong.
The correct measurement is the clickable/tappable area — which includes padding if the element is sized with padding, but does not include margins. Margins create spacing between elements but are not part of the element's interactive area.
/* Example: measuring what matters */
.btn {
width: 80px; /* Content width */
height: 20px; /* Content height */
padding: 8px 12px; /* Top/bottom, Left/right */
margin: 16px; /* Does NOT count toward target size */
}
/*
Actual clickable area:
- Width: 80px + 12px + 12px = 104px ✓
- Height: 20px + 8px + 8px = 36px ✓ (exceeds 24px)
*/
For border-box sizing, the width and height you set include padding but not margin:
/* With box-sizing: border-box (default in most modern codebases) */
.btn {
box-sizing: border-box;
width: 100px; /* This IS the total clickable width */
height: 36px; /* This IS the total clickable height */
padding: 8px; /* Already included in 36px */
}
/* Passes 24x24 ✓ */
Elements That Most Commonly Fail SC 2.5.8
In my audits, these are the UI patterns that fail this criterion most frequently:
Icon-Only Buttons in Toolbars and Navigation
Share buttons, close buttons, edit buttons, three-dot menus — wherever you find rows of icon buttons, you frequently find targets below 24×24. The visual icon might be 16×16, and if there is no padding expanding the tap area, it fails.
Checkboxes and Radio Buttons
Native checkboxes are typically 13–16px in most browsers. While the label text provides additional tap area in some implementations, the checkbox itself often fails. Custom-styled checkboxes that replicate this small size are frequent failures.
/* Expanding checkbox tap area with label */
.form-group {
display: flex;
align-items: center;
gap: 8px;
min-height: 24px; /* Ensures label row meets minimum height */
}
label {
display: flex;
align-items: center;
gap: 8px;
min-height: 24px;
cursor: pointer;
}
input[type="checkbox"] {
width: 18px;
height: 18px;
margin: 3px; /* Adds spacing around the checkbox itself */
cursor: pointer;
}
Close Buttons on Notification Banners and Toast Messages
That little X to dismiss a banner? Often 16×16 or smaller. And because it is positioned in a compact notification component, there is no spacing margin to save it. A minimum of 24×24 for the button element (including padding) resolves this.
Pagination Controls
Number links and previous/next arrows in pagination are frequently cramped. The numbers need to be individually at least 24×24 or have sufficient spacing between them that the offset exception applies.
Why This Matters Beyond Compliance
I want to be direct about who this criterion actually protects. Target size requirements exist primarily for:
- People with motor disabilities who have limited precision of movement — tremors, spasticity, limited range of motion make small targets genuinely impossible to activate reliably
- Users of switch access devices who use scanning to navigate — hitting a 16×16 target with a switch is significantly harder than hitting a 44×44 target
- Anyone using a touch screen with a finger — the average adult fingertip covers approximately 44–57 CSS pixels at typical viewing distance, which is why the original WCAG 2.1 AAA criterion specified 44×44
- Users with low vision who may be zoomed in, have a larger pointer, or have reduced spatial precision
The 24×24 minimum is the floor, not the goal. If you have the design freedom to make interactive targets 44×44 CSS pixels — which is what Apple's Human Interface Guidelines and Google's Material Design have recommended for years — do it. Your entire user base will benefit, and you will exceed WCAG 2.5.8 by a comfortable margin.
Quick Audit Checklist for SC 2.5.8
- Identify every interactive element on the page: links, buttons, checkboxes, radio buttons, selects, custom controls
- For each element, measure the clickable/tappable area in DevTools (include padding in the measurement)
- For any element below 24×24: check whether the spacing offset exception applies — is there at least 24px of clear space to the nearest other interactive element on all sides?
- For any element that fails both the size test and the spacing test: check whether it qualifies for an exception (inline text link, user agent control, essential presentation)
- Flag all remaining failures for remediation
Pay particular attention to mobile viewports — many targets that are adequate on desktop shrink on mobile due to responsive layout changes.
Need a real accessibility audit?
Not a Lighthouse score — a thorough WCAG 2.2 AA audit with manual JAWS testing and code-level remediation guidance your developers can actually use.
Schedule a Free Consultation