Touch Target Size on E-Commerce Sites: What WCAG 2.5.8 Actually Requires
Quick answer: WCAG 2.5.8 Target Size (Minimum) (Level AA, new in WCAG 2.2) requires that “the size of the target for pointer inputs is at least 24 by 24 CSS pixels,” with five specific exceptions (spacing, equivalent, inline, user agent control, essential). On e-commerce sites the components that most often fail it are small icon-only controls — a wishlist heart, a cart line-item’s remove “×”, quantity-stepper +/- buttons, color/size swatch chips, and carousel dot indicators — where the clickable area is exactly the size of the glyph, with no padding added around it.
This article is general accessibility information, not legal advice. Meeting WCAG 2.1/2.2 AA is a technical-practice standard, not a legal determination — consult qualified counsel for legal risk questions.
What the success criterion actually says
SC 2.5.8’s own text is short: the target for any pointer input needs to be at least 24 by 24 CSS
pixels, or fall under one of five stated exceptions. The Understanding
doc is specific about how
“size” is measured — not by the visible icon, but by the full interactive bounding box: “For a
target to be ‘at least 24 by 24 CSS pixels’, it must be conceptually possible to draw a solid 24
by 24 CSS pixel square, aligned to the horizontal and vertical axis such that the square is
completely within the target.” Padding counts. A 14px icon inside a <button> with 8px of padding
on every side clears the bar; the same icon with no padding doesn’t, even though the glyph itself
never changed size.
The five exceptions, quoted directly from the Understanding doc:
- Spacing — “Undersized targets… are positioned so that if a 24 CSS pixel diameter circle is centered on the bounding box of each, the circles do not intersect another target.” A row of small icons can pass without growing any of them, as long as there’s enough space between them.
- Equivalent — “The function can be achieved through a different control on the same page that meets this criterion.” A tiny inline icon is fine if a full-size equivalent exists elsewhere on the same page.
- Inline — “The target is in a sentence or its size is otherwise constrained by the line-height of non-target text.” An inline text link doesn’t need to be artificially padded to 24px tall.
- User agent control — “The size of the target is determined by the user agent and is not
modified by the author.” A browser’s native
<select>dropdown arrow, for example. - Essential — “A particular presentation of the target is essential or is legally required for the information being conveyed.” Narrow use case; doesn’t apply to most e-commerce UI.
The Understanding doc’s own Intent section explains the reasoning in plain terms: “Users with dexterity limitations and those who have difficulty with fine motor movement find it difficult to accurately activate small targets when there are other targets that are too close.” It names tremors, spasticity, and quadriplegia specifically, and notes the criterion also improves touchscreen usability generally — a benefit that isn’t limited to any one disability.
The AA floor and the AAA target
WCAG actually defines target size twice, at two conformance levels. SC 2.5.8 (AA, 2.2) sets the 24×24 CSS pixel floor described above. SC 2.5.5 Target Size (Enhanced) (Level AAA, WCAG 2.1) is a stricter version of the same idea: “the size of the target for pointer inputs is at least 44 by 44 CSS pixels,” with its own narrower exception set (equivalent, inline, user agent control, essential — no spacing exception at this level).
2.5.8’s 24×24 floor is the AA-level bar worth building toward — it isn’t part of Quietramp’s current WCAG 2.1 AA audit scope, since 2.5.8 belongs to WCAG 2.2, not 2.1. But 2.5.5’s 44×44 figure is worth knowing as the design target to build toward beyond that, not just the compliance minimum to scrape past — the gap between “technically passes” and “comfortable to tap” is real, and 44px is where most native mobile platform guidance already points teams by default.
Where this actually breaks on e-commerce pages
The Understanding doc doesn’t name specific UI components as worked examples — its own illustrations are generic toolbar buttons and menu items. The following is Quietramp’s own applied observation from auditing e-commerce sites specifically, not a claim from the spec itself:
- Wishlist/save-for-later heart icons. Often an 18-20px SVG with no surrounding padding, placed directly on a product card.
- Cart line-item “remove” controls. A small “×” or trash icon next to each cart row — one of the most consequential controls on the page to get wrong, since a customer who can’t tap it reliably may abandon checkout entirely rather than fight with it.
- Quantity stepper +/- buttons. Frequently styled as a single-character button (
+/-) sized to its text, with no minimum dimensions set. - Color/size swatch chips. Small circular or square swatches packed tightly together on a product detail page — a case where the spacing exception matters: if the swatches are far enough apart, they don’t each need to individually grow to 24px.
- Carousel dot indicators and icon-only prev/next arrows. Frequently a handful of CSS pixels each, clustered at the bottom of a hero banner or product gallery.
- Modal/drawer close “×” buttons. Often the single most-used control in the whole interaction (open the cart drawer, close it), and often one of the smallest.
The fix, in practice
The fix almost never requires making the visible icon bigger — it requires making the interactive area bigger, which is a CSS problem, not a design problem:
/* Fails 2.5.8 — 18px icon, no padding, ~18x18 clickable area */
.wishlist-btn {
width: 18px;
height: 18px;
}
/* Passes — same 18px icon, padding brings the target to 24x24+ */
.wishlist-btn {
width: 18px;
height: 18px;
padding: 4px;
box-sizing: content-box;
}For a plain <button> or <a>, min-width/min-height set directly on the element works too,
as long as the full box remains clickable (not just the visible glyph inside it — check that
nothing on top is stealing the pointer events). For tightly packed elements like swatches, invoke
the spacing exception deliberately: keep the visual chip small, but confirm the gap between
adjacent chips is wide enough that a 24px circle centered on each one doesn’t overlap its
neighbor’s circle.
Can an automated scanner catch this?
Partially, and it’s a recent addition. axe-core’s target-size rule (“Ensure touch targets have
sufficient size and space”) is tagged to wcag22aa/wcag258, but per axe-core’s own rule
descriptions, it
ships disabled by default while WCAG 2.2 adoption is still ramping up across the ecosystem — a
default axe-core run on many sites won’t surface this issue at all unless the rule is explicitly
enabled. Even enabled, an automated check can measure a bounding box, but it can’t reliably judge
which exception applies in an edge case (is this really “inline” text, or a mis-marked-up button
pretending to be a sentence?) — the kind of judgment call a manual review is built to make.
FAQ
Does this apply to hover-only desktop interfaces? SC 2.5.8 applies to “pointer inputs” generally, which includes mouse pointers, but the Intent section’s own framing — dexterity limitations and touchscreen precision — makes it most consequential on mobile and tablet, where fat-finger mis-taps are the common failure mode.
Is 2.5.8 required for WCAG 2.1 AA conformance, or only 2.2? 2.5.8 is a WCAG 2.2 success criterion, not 2.1. A site conforming only to WCAG 2.1 AA isn’t required to meet it. It’s included here because WCAG 2.2 is the current version of the standard and target size is a fast, high-value fix regardless of which version a site is formally scoped to.
Do I need to enlarge every icon on the site? No — the fix is almost always padding or spacing around a control, not the visual size of the icon itself. A 16px glyph inside a properly padded 24px+ tap target passes; only the invisible interactive boundary needs to grow.
Get a human-reviewed audit, not just a scan
A default axe-core scan won’t flag target-size issues at all unless the WCAG 2.2 rule is manually enabled — and even then, judging which exception applies to an edge case is a manual call. Quietramp’s audits pair an automated scan with a manual review that catches exactly this kind of gap, delivered as a prioritized, developer-actionable PDF report. See a real sample report or check pricing — $890 one-time, $99/month for ongoing re-checks after fixes ship.
This article is general accessibility information, not legal advice. Meeting WCAG 2.1 or 2.2 AA does not resolve ADA or any other legal compliance question, and nothing here should be read as a compliance guarantee. Consult qualified counsel for legal risk questions.
This article was drafted with AI assistance and reviewed by a person for accuracy before publication.