WCAG 2.5.8: Target Size (Minimum)
The size of the target for pointer inputs is at least 24 by 24 CSS pixels, except where Spacing, Equivalent, Inline, User-agent control, or Essential applies. Meeting this Level AA criterion makes buttons, links, and controls easier to tap and click accurately — for everyone, but especially for people with motor impairments, tremor, or limited dexterity, and anyone using a touchscreen on the move.
The success criterion, in full
The size of the target for pointer inputs is at least 24 by 24 CSS pixels, except where: Spacing, Equivalent, Inline, User-agent control, or Essential.
Why target size matters
Small targets are hard to hit. A user has to position the pointer precisely and hold it steady to activate a control, and that demand excludes a large group of people: those with hand tremors, arthritis, Parkinson's disease, or reduced fine-motor control; people using a touchscreen one-handed on a bus or while walking; and anyone using a head pointer, switch, or other alternative input. When targets are crowded and tiny, missed taps trigger the wrong action, cause accidental purchases, or force frustrating re-attempts.
Larger targets reduce error rates for everyone— a classic illustration of Fitts's Law, which predicts that the time to acquire a target shrinks as the target grows and as the distance to it falls. WCAG 2.5.8 sets a pragmatic floor of 24×24 CSS pixels for Level AA, while the stricter 2.5.5 Target Size (Enhanced) asks for 44×44 at Level AAA.
What the 24×24 rule actually measures
Three details trip people up most often:
- 1
The target is the whole hit area, not the visible icon. Padding counts. A 14 px icon wrapped in a button with 6 px of padding on each side has a 26×26 px target and passes. You almost never need to enlarge the artwork — you enlarge the clickable region around it.
- 2
CSS pixels, not device pixels. The 24 px is measured in CSS reference pixels, the same unit you set widths in. A high-density “Retina” display does not change the requirement — a control that is 24 CSS pixels wide conforms regardless of how many physical pixels render it.
- 3
Both dimensions must reach 24 px. A long, 16 px-tall button might be plenty wide but still fails on height. Check width and height — undersized height is the single most common real-world failure, especially for dense menu rows and compact icon buttons.
Rule of thumb: if you give every stand-alone interactive control a minimum height and width of 24px (44px is even better) and keep small targets spaced apart, you will satisfy 2.5.8 in the vast majority of cases.
The five exceptions
A target may be smaller than 24×24 px and still conform if any one of these five exceptions applies. Knowing them prevents both over-engineering and false failures.
1. Spacing
Undersized targets pass if they have enough spacing around them.
A target under 24×24 px is allowed when a 24 px diameter circle, centered on the bounding box of each target, does not intersect the circle of any adjacent target (or the bounding box of any other target). In practice this means a small icon can stay small as long as nothing tappable sits within roughly 24 px of its center.
2. Equivalent
Another control on the same page does the same thing at full size.
If a 24×24 px (or larger) control on the same page performs the identical function, the smaller target is exempt. For example, a tiny inline 'edit' pencil can be undersized if a full-size 'Edit' button elsewhere on the page does the same job.
3. Inline
Links inside a sentence or block of text are exempt.
Targets whose position is determined by the flow of surrounding text — such as a link in the middle of a paragraph — are excluded. Their size is constrained by line-height and the reading layout, so forcing them larger would break the text.
4. User agent control
The browser sets the size and you have not changed it.
If the size of the target is determined by the user agent (the browser) and is not modified by the author, it passes. A default, unstyled checkbox or radio button rendered by the browser is the classic example. Once you restyle its dimensions with CSS, the exception no longer applies.
5. Essential
A specific small presentation is essential or legally required.
If a particular small presentation of the target is essential to the information being conveyed — or is legally required — it is exempt. Pins on an interactive map that mark exact geographic coordinates are the canonical example, because moving or enlarging them would misrepresent the locations.
Code examples
Enlarge the hit area without enlarging the icon (CSS)
The most reliable fix is to set a minimum size on the control and let padding center a small icon inside it.
/* Any clickable control: never smaller than 24x24 CSS px */
.icon-button {
display: inline-flex;
align-items: center;
justify-content: center;
min-width: 24px;
min-height: 24px;
/* 44x44 is the recommended, more comfortable target */
padding: 10px;
}
/* The visible glyph can stay small */
.icon-button svg {
width: 16px;
height: 16px;
}Extend a small target with a pseudo-element
When you cannot change layout dimensions, an invisible::beforeoverlay expands the clickable region without affecting the visual size.
.compact-link {
position: relative;
}
/* Expand the hit area to at least 24x24 without moving anything */
.compact-link::before {
content: "";
position: absolute;
inset: 50% auto auto 50%;
width: max(24px, 100%);
height: max(24px, 100%);
transform: translate(-50%, -50%);
}Accessible React icon button
A real button element, an accessible name for screen readers, a guaranteed minimum size, and a visible focus indicator — all in one.
function CloseButton({ onClick }: { onClick: () => void }) {
return (
<button
type="button"
onClick={onClick}
aria-label="Close dialog"
className="
inline-flex items-center justify-center
min-w-[44px] min-h-[44px] p-2
rounded-md
focus-visible:outline focus-visible:outline-2
focus-visible:outline-offset-2 focus-visible:outline-blue-600
"
>
<XIcon aria-hidden="true" className="w-4 h-4" />
</button>
)
}Using the Spacing exception for a toolbar of small icons
If you genuinely need 16 px icons, give them enough gap that a 24 px circle around each center never overlaps its neighbor.
/* 16px targets pass under the Spacing exception when
centers are >= 24px apart. With 16px icons, an 8px gap
puts centers 24px apart (16 + 8). */
.toolbar {
display: flex;
gap: 8px;
}
.toolbar button {
width: 16px;
height: 16px;
}Common mistakes
- Measuring only the icon or text glyph instead of the full padded hit area — the target is the bounding box, padding included.
- Passing on width but failing on height. Dense menu rows, breadcrumb links, and compact icon buttons frequently clear 24px wide but fall short of 24px tall.
- Restyling a native checkbox or radio smaller than 24px. Once you set its dimensions, the User-agent control exception no longer protects it.
- Assuming all links are exempt under Inline. Only links inside a run of text qualify; navigation links, button-styled links, and list-row links must meet 24×24.
- Placing small targets too close together. Undersized icons need ~24px center-to-center spacing to qualify under the Spacing exception.
- Confusing 2.5.8 (24px, AA) with 2.5.5 (44px, AAA) and either over-building or under-building. Know which target you are conforming to.
How to test for 2.5.8
- 1
Inspect rendered dimensions
Open browser DevTools, select each interactive element, and read the box-model width and height in CSS pixels. Include padding — the hit area is the full bounding box.
- 2
Flag anything under 24px
List every control whose width or height is below 24px. These need a fix, or must qualify under one of the five exceptions.
- 3
Check spacing on undersized targets
For small targets, measure center-to-center distance to neighbors. If a 24px circle around each center does not overlap, they pass under Spacing.
- 4
Run automated checks
axe DevTools, Lighthouse, and similar scanners catch many obvious target-size failures and undersized tap targets quickly across a page.
- 5
Finish with a real touch test
Automation cannot feel a missed tap. Try the interface on an actual phone, ideally one-handed, and confirm controls are comfortable to hit.
Run a full sweep with our Mobile Accessibility Checker and audit a live URL with the URL Accessibility Auditor.
Related success criteria
2.5.5 Target Size (Enhanced) — AAA
The stricter 44×44 CSS pixel requirement. Meeting it automatically satisfies 2.5.8 and aligns with native platform guidance.
2.5.7 Dragging Movements — AA (new in 2.2)
Another pointer-input criterion: any drag action must have a single-pointer alternative. Often evaluated alongside target size on touch interfaces.
2.4.1 Bypass Blocks — A
Reducing repetitive interaction is a sibling goal: skip links cut the number of small targets a keyboard user must traverse.
Keyboard Accessibility Guide
Target size governs pointer input; keyboard operability covers the complementary path. Robust UIs need both.
Frequently asked questions
What is the minimum target size under WCAG 2.5.8?
WCAG 2.5.8 Target Size (Minimum) requires that the target for any pointer input is at least 24 by 24 CSS pixels, unless one of five exceptions applies (Spacing, Equivalent, Inline, User-agent control, or Essential). It is a Level AA success criterion that was added in WCAG 2.2. Note that CSS pixels are a reference unit and are not the same as physical device pixels — a target measured in the browser at 24 CSS pixels meets the requirement regardless of the device's pixel density.
Is WCAG 2.5.8 the same as 24px or 44px?
They are two different success criteria. WCAG 2.5.8 Target Size (Minimum) is Level AA and requires 24×24 CSS pixels — it is new in WCAG 2.2. WCAG 2.5.5 Target Size (Enhanced) is Level AAA and requires 44×44 CSS pixels — it has existed since WCAG 2.1. If you are aiming for the common Level AA conformance target, 24×24 is your floor, but 44×44 is widely recommended as a usability best practice, and it matches the platform guidance from Apple (44pt) and Google Material (48dp).
Does the target size include padding, or only the visible icon?
The target is the full clickable or tappable region — its bounding box — not just the visible glyph or text. A 16×16 px icon inside a button with 8 px of padding on every side has a 32×32 px target and passes. This is the most common and most useful way to satisfy 2.5.8: keep the icon visually small but expand the hit area with padding, a larger height, or a pseudo-element overlay.
How does the spacing exception work?
Draw an imaginary 24 px diameter circle centered on each undersized target. If no target's circle overlaps the circle (or bounding box) of any neighboring target, the targets pass under the Spacing exception even though each is smaller than 24×24 px. Concretely, two 16 px icons pass if their centers are at least 24 px apart, because their 24 px circles will not intersect. This exception is why a row of small, well-spaced toolbar icons can conform without being enlarged.
Do inline text links need to be 24×24 pixels?
No. Links embedded in a sentence or paragraph are covered by the Inline exception because their size is dictated by the line-height of the surrounding text. You do not need to enlarge a link in the middle of running prose. However, stand-alone links presented as navigation items, buttons, or list rows are not inline and must meet the 24×24 requirement (or qualify under another exception such as Spacing).
How do I test for WCAG 2.5.8 compliance?
Use your browser developer tools to inspect each interactive element and read its rendered width and height in CSS pixels — include padding in the measurement, since the hit area is the bounding box. For undersized targets, measure center-to-center spacing to check the Spacing exception. Automated tools such as axe DevTools and Lighthouse flag many target-size issues, but spacing-exception and equivalent-control cases need manual judgment. Always finish with a real touch test on a phone.