WCAG 2.5.8 Target Size is one of the most overlooked yet critical success criteria in the WCAG 2.2 update, directly impacting how users with motor impairments, tremors, or limited dexterity interact with digital interfaces. Introduced as part of the broader push toward inclusive design, this criterion requires interactive elements like buttons, links, and form controls to meet a minimum touch target size of 24×24 CSS pixels, ensuring users don’t struggle to tap the right element on mobile or touchscreen devices. For businesses aiming at true ADA compliance, ignoring target size isn’t just a legal risk, it’s a usability failure that alienates a significant portion of your audience. In this guide, we’ll break down exactly what WCAG 2.5.8 requires, common accessibility barriers it solves, and practical steps to implement compliant target sizes without disrupting your existing UI design.
Direct Answer: How Do You Implement WCAG 2.5.8?
To implement WCAG 2.5.8, ensure pointer-operable targets are at least 24 × 24 CSS pixels, or provide sufficient spacing so smaller targets do not fall within another target’s 24-pixel minimum area. Then test adjacent controls, inline links, custom components, responsive layouts, and keyboard/pointer interaction to verify the applicable exceptions and spacing requirements.
Definition Box: What Is a Target in WCAG 2.5.8?
Target: The region of a user interface that receives a pointer input, such as a button, link, checkbox, icon control, or other interactive component.
For WCAG 2.5.8, the important measurement is the target size or the surrounding target area, not necessarily the visible pixels of the icon or text.
For example, a 16 × 16 pixel search icon can potentially comply if its interactive button provides a sufficiently large target area.
Why Does WCAG 2.5.8 Matter?
Small interactive controls can be difficult to activate accurately. This is especially relevant for users with limited motor control, users operating interfaces on touchscreens, and users who have difficulty making precise pointer movements.
WCAG 2.5.8 establishes a 24 × 24 CSS pixel minimum target size at Level AA, subject to specific exceptions.
The criterion was introduced inWCAG 2.2 and is different from WCAG 2.1’s Level AAA Target Size criterion, which uses a larger 44 × 44 CSS pixel target.
WCAG 2.5.8 vs. WCAG 2.5.5
Criterion
WCAG Version
Conformance Level
Minimum Target
2.5.5 Target Size
WCAG 2.1
AAA
44 × 44 CSS pixels
2.5.8 Target Size (Minimum)
WCAG 2.2
AA
24 × 24 CSS pixels
The 24 × 24 CSS pixel requirement should not be confused with a requirement that every visible icon must be 24 × 24 pixels. The interactive target and its available spacing are what need to be evaluated.
Step 1: Identify Every Pointer-Operable Target
Start your audit by inventorying interactive elements.
Look for:
Buttons
Links
Icon buttons
Close controls
Menu buttons
Pagination controls
Checkboxes
Radio buttons
Switches
Custom dropdown controls
Carousel controls
Video controls
Map controls
Form controls
Social-media buttons
Shopping-cart controls
Search controls
Delete and edit icons
Do not limit the audit to <button> elements. Custom controls implemented with <div>, <span>, or other elements can also create accessibility problems.
Example
A visually small close icon may look like this:
<button class=”close-button” aria-label=”Close”>
×
</button>
The character itself might be only a few pixels high, but the button can still provide a sufficiently large target.
Step 2: Measure the Actual Interactive Target
The next step is to determine the size of each target.
A common mistake is measuring only the visible content.
For example:
.icon {
width: 16px;
height: 16px;
}
This does not automatically mean the interactive target is 16 × 16 pixels.
The icon could be placed inside a larger button:
.icon-button {
width: 24px;
height: 24px;
}
Or, preferably, the control can have additional padding:
.icon-button {
min-width: 44px;
min-height: 44px;
padding: 10px;
}
The second approach can provide a more comfortable interaction area while keeping the visual icon relatively small.
Step 3: Use CSS to Create an Adequate Target Area
For controls under your direct design and development control, establish an accessible minimum size.
A simple implementation is:
button,
[role=”button”] {
min-width: 24px;
min-height: 24px;
}
However, applying this globally can create unwanted layout problems.
A better approach is to create a reusable component rule:
.target-control {
min-width: 24px;
min-height: 24px;
display: inline-flex;
align-items: center;
justify-content: center;
}
For touch-oriented interfaces, many teams choose a larger target such as 44 × 44 CSS pixels because it provides additional usability beyond the WCAG 2.5.8 minimum.
.touch-control {
min-width: 44px;
min-height: 44px;
display: inline-flex;
align-items: center;
justify-content: center;
}
Important: 44 × 44 is not the minimum required by WCAG 2.5.8. It is a larger design target that can provide additional usability benefits.
Step 4: Check Spacing Between Smaller Targets
WCAG 2.5.8 does not require every target to independently occupy a 24 × 24 CSS pixel box in every circumstance.
One important exception concerns spacing.
A target can be smaller than 24 × 24 CSS pixels when sufficient spacing exists so that its target does not overlap the 24 × 24 CSS pixel target area of another target.
Consider two small controls:
[ A ] [ B ]
If they are sufficiently separated, their target areas may satisfy the spacing exception.
By contrast:
[A][B][C][D]
Closely packed controls can create an accidental activation problem.
Practical CSS Example
.action-list {
display: flex;
gap: 8px;
}
.action {
min-width: 24px;
min-height: 24px;
}
Do not assume that adding an arbitrary gap value automatically establishes WCAG conformance. The actual target geometry must be evaluated.
Step 5: Understand the WCAG 2.5.8 Exceptions
This is one of the most important parts of implementation.
WCAG 2.5.8 contains specific exceptions. A target does not necessarily fail simply because its dimensions are below 24 × 24 CSS pixels.
The criterion includes exceptions for situations such as:
Spacing — A target smaller than 24 × 24 can comply when sufficient spacing exists around it.
Equivalent — Another control for the same function that satisfies the size requirement is available.
Inline — The target is within a sentence or block of text.
User Agent Control — The size of the target is determined by the user agent rather than the author.
Essential — A particular presentation of the target is essential to the information or functionality.
These exceptions should be evaluated based on the actual WCAG requirements rather than used as blanket justifications for small controls.
Step 6: Pay Special Attention to Inline Text Links
Not every hyperlink in a webpage needs to become a 24 × 24 CSS pixel button.
Inline links within normal text are covered by an exception.
Increasing every inline link’s box to 24 × 24 pixels could make ordinary paragraphs visually awkward and change line spacing.
This is why WCAG 2.5.8 distinguishes inline text links from standalone interactive controls.
Step 7: Fix Icon-Only Buttons Correctly
Icon-only controls are among the most common target-size problems.
For example:
<button class=”share”>
<svg aria-hidden=”true”>…</svg>
</button>
A common mistake is styling only the SVG:
.share svg {
width: 16px;
height: 16px;
}
Instead, give the button an adequate interaction area:
.share {
width: 44px;
height: 44px;
display: inline-flex;
align-items: center;
justify-content: center;
}
The SVG can remain visually smaller:
.share svg {
width: 20px;
height: 20px;
}
This produces a small visual icon with a much larger clickable area.
Step 8: Audit Form Controls
Forms contain many potential target-size issues.
Check:
Checkbox controls
Radio buttons
Select controls
Toggle switches
Date-picker controls
Search buttons
Password visibility buttons
Increment/decrement buttons
A custom checkbox, for example, should not provide only a tiny clickable square if the entire label could reasonably be used as part of the target.
A larger label/control interaction area can improve usability:
<label class=”checkbox-option”>
<input type=”checkbox” name=”terms”>
<span>I agree to the terms</span>
</label>
.checkbox-option {
min-height: 44px;
display: inline-flex;
align-items: center;
gap: 10px;
}
This also makes the control easier to operate on touch devices.
Step 9: Check Responsive Designs
A component that passes on desktop can fail on mobile.
Audit target sizes at:
Desktop widths
Tablet widths
Mobile widths
Zoomed layouts
Responsive navigation states
Touch-oriented interfaces
Pay particular attention to:
Hamburger menus
Header icons
Close buttons
Sticky navigation
Bottom navigation
Product quantity controls
Pagination
Carousel arrows
Responsive CSS can unintentionally reduce target dimensions.
For example:
@media (max-width: 600px) {
.icon-button {
width: 18px;
height: 18px;
}
}
This should trigger an accessibility review because the mobile breakpoint has reduced the target below the 24 × 24 CSS pixel minimum.
Step 10: Test Target Geometry in Browser DevTools
Automated accessibility tools can identify many issues, but target size requires careful manual evaluation.
In Chrome or another browser’s developer tools:
Inspect the interactive element.
Identify its CSS dimensions.
Check padding and margins.
Determine the actual clickable area.
Examine neighboring targets.
Test the component at different viewport sizes.
Check whether a WCAG 2.5.8 exception applies.
Remember that CSS layout can be more complicated than a single width and height declaration.
Automated Testing vs. Manual Testing
Testing Method
What It Can Help Identify
Limitations
Browser DevTools
Dimensions, padding, layout
Requires manual analysis
Automated accessibility scanner
Potentially undersized controls
May not understand every exception
Keyboard testing
Focus and operability
Does not fully test pointer target size
Touch-device testing
Real-world activation
Does not replace WCAG evaluation
Code review
CSS/component patterns
Cannot determine every rendered state
Manual WCAG audit
Target size + exceptions
Requires trained evaluator
A reliable WCAG 2.5.8 audit should combine automated testing with manual review.
Common WCAG 2.5.8 Implementation Mistakes
Mistake 1: Measuring Only the Icon
A 16 × 16 SVG does not necessarily mean the target is 16 × 16 pixels.
Measure the interactive control.
Mistake 2: Assuming 24 Pixels Is Always Enough
A 24 × 24 CSS pixel target satisfies the basic minimum dimension, but usability can still benefit from larger controls.
For many touch interfaces, 44 × 44 CSS pixels can provide a more comfortable interaction area.
Mistake 3: Ignoring Target Spacing
Several small controls placed close together can create a target-size problem even when each individual control appears visually acceptable.
Evaluate the relationship between neighboring targets.
Mistake 4: Applying min-width: 24px Globally
A global rule can break layouts and does not automatically solve every WCAG issue.
Target interactive components intentionally through reusable design-system classes.
Mistake 5: Treating Every Link as a Button
Inline text links have a specific exception under WCAG 2.5.8.
Do not distort normal paragraph typography merely to force every inline link into a button-like box.
Mistake 6: Relying Entirely on Automated Tools
Automated testing is useful, but it may not correctly evaluate contextual exceptions, target relationships, or the actual intent of a component.
Manual testing remains necessary.
Recommended Design-System Pattern
The easiest long-term solution is to build target size into your design system rather than fixing individual pages.
For example:
:root {
–target-min-size: 24px;
–target-comfortable-size: 44px;
}
.accessible-control {
min-width: var(–target-min-size);
min-height: var(–target-min-size);
display: inline-flex;
align-items: center;
justify-content: center;
}
For primary touch controls:
.touch-target {
min-width: var(–target-comfortable-size);
min-height: var(–target-comfortable-size);
display: inline-flex;
align-items: center;
justify-content: center;
}
This creates a repeatable development standard.
WCAG 2.5.8 Implementation Checklist
Before declaring a page compliant, verify:
All pointer-operable targets have been identified.
Target dimensions have been evaluated.
Targets generally provide at least 24 × 24 CSS pixels.
Adjacent smaller targets have been checked for adequate spacing.
Inline text links have been evaluated under the applicable exception.
Equivalent controls have been considered where relevant.
User-agent-controlled controls have been identified.
Essential presentation exceptions have not been incorrectly applied.
Mobile layouts have been tested.
Icon-only buttons have adequate target areas.
Form controls have been evaluated.
Automated testing has been supplemented with manual testing.
Keyboard accessibility has also been verified separately.
Custom components have been reviewed across states and breakpoints.
What Is the Difference Between Target Size and Visual Size?
Target size describes the area that can receive the user’s pointer input. Visual size describes what the user actually sees.
These measurements can be different.
For example:
44px target area
┌──────────────────────────┐
│ │
│ 20px icon │
│ │
└──────────────────────────┘
The icon remains visually compact while the interactive region is large enough for comfortable activation.
This distinction is particularly important for minimalist navigation bars and icon-heavy interfaces.
How Should Developers Implement WCAG 2.5.8 in a Design System?
The best approach is to treat target size as a component-level requirement.
Create standard accessible components for:
Buttons
Icon buttons
Navigation controls
Form controls
Pagination
Toggles
Menus
Dialog controls
Media controls
Then enforce minimum target dimensions through design tokens, component CSS, code review, and automated regression testing.
This prevents the same accessibility issue from being repeatedly introduced across different pages.
Official WCAG Guidance
For implementation and conformance decisions, developers should use the official W3C specification rather than relying solely on third-party accessibility checklists.
These should be treated as the primary references when determining whether a specific implementation satisfies WCAG 2.5.8.
Frequently Asked Questions About WCAG 2.5.8
What is the minimum target size under WCAG 2.5.8?
WCAG 2.5.8 requires pointer-operable targets to be at least 24 × 24 CSS pixels, unless a specified exception applies. The requirement is a Level AA success criterion in WCAG 2.2.
Does WCAG 2.5.8 require buttons to be 44 × 44 pixels?
No. WCAG 2.5.8 establishes a 24 × 24 CSS pixel minimum at Level AA. A 44 × 44 CSS pixel target is associated with the more stringent WCAG 2.5.5 Target Size criterion at Level AAA, and larger targets may also be chosen as a usability best practice.
Do inline links have to be 24 × 24 pixels?
No. WCAG 2.5.8 includes an exception for targets within a sentence or block of text. Normal inline links therefore do not need to be artificially enlarged to 24 × 24 CSS pixels.
Can a 16 × 16 icon comply with WCAG 2.5.8?
Yes, potentially. The icon itself does not have to be 24 × 24 pixels if its interactive target has sufficient size or another applicable WCAG 2.5.8 exception applies.
Does spacing between buttons matter for WCAG 2.5.8?
Yes. The spacing exception can allow a target smaller than 24 × 24 CSS pixels when it is positioned so that its target area does not overlap the 24 × 24 CSS pixel target area of another target.
Can automated accessibility tools test WCAG 2.5.8?
Automated tools can help identify potential target-size problems, but they cannot reliably determine every WCAG 2.5.8 exception or contextual requirement. Manual inspection and testing are therefore important parts of a complete audit.
