The 2025 TestParty Guide to WCAG 2.5.5 – Target Size (Level AAA)

Why did the tiny button go to therapy? It had trouble dealing with all the pressure from users who couldn't hit it on the first try.

WCAG 2.5.5 Target Size requires interactive elements to be at least 44 by 44 CSS pixels—large enough for users with motor impairments, tremors, or anyone using a touchscreen to activate reliably. While it's a Level AAA criterion (the highest conformance level), it's become a practical necessity in our mobile-first world and a key factor in usability lawsuits.

Table of Contents

• What WCAG 2.5.5 Requires
• Why This Matters
• Quick Implementation Guide
• Common Mistakes to Avoid
• How to Test for WCAG 2.5.5
• How TestParty Helps
• FAQs

What WCAG 2.5.5 Requires

WCAG 2.5.5 mandates that clickable or tappable targets—buttons, links, form controls, custom interactive widgets—must be at least 44 by 44 CSS pixels in size.

Key exceptions where smaller targets are acceptable:

• Equivalent: A larger version of the same target (≥44×44px) exists elsewhere on the page
• Inline: The target appears within a sentence or block of text (like a hyperlink mid-paragraph)
• User Agent Control: The browser or OS determines the size, and the author hasn't modified it
• Essential: The specific size is critical to the information being conveyed (rare)

What counts as a target:

• Buttons, links, checkboxes, radio buttons, toggle switches
• Custom controls like star ratings, sliders, color pickers
• Icon-only buttons (hamburger menus, close buttons, social icons)
• Clickable cards, tiles, or list items

Special considerations:

• For controls like sliders or color pickers where users select by position, the entire interactive area counts as one target
• For inline links, the line-height (perpendicular to text flow) is considered part of the target area

Why This Matters

Real user impact:

People with Parkinson's, arthritis, cerebral palsy, or limited fine motor control struggle to tap small targets accurately. Older adults, users with tremors, and anyone holding a phone one-handed while multitasking benefit from larger touch targets. Making buttons 44×44px or larger dramatically reduces mis-taps and frustration.

Legal and compliance context:

While 2.5.5 is Level AAA (not required for most legal compliance), its sibling criterion WCAG 2.5.8 Target Size (Minimum) at Level AA requires 24×24px and is part of WCAG 2.2. Many organizations adopt the 44×44px standard anyway because it aligns with Apple's Human Interface Guidelines and Android's Material Design recommendations. ADA lawsuits increasingly cite inadequate touch target sizes as evidence of inaccessibility, especially on mobile. Section 508, EN 301 549, and the European Accessibility Act reference WCAG 2.2 Level AA, which now includes minimum target sizing.

Business case:

Larger targets reduce user errors, lower bounce rates, and improve conversion rates—especially on mobile, where over 60% of web traffic originates. A checkout button users can't reliably tap is revenue left on the table.

Quick Implementation Guide

1. Set minimum dimensions in CSS:

/* Ensure all interactive elements meet minimum size */
button,
a.button,
input[type="submit"],
input[type="checkbox"],
input[type="radio"] {
  min-width: 44px;
  min-height: 44px;
}

/* For icon-only buttons, use padding to expand hit area */
.icon-button {
  width: 24px;  /* visible icon size */
  height: 24px;
  padding: 10px; /* expands clickable area to 44×44px */
}

2. Use padding or transparent borders to expand clickable areas without changing visual appearance. The clickable region can be larger than the visible icon or text.

3. Add spacing between adjacent targets to prevent accidental activation of the wrong control. A few pixels of margin goes a long way.

4. Test on actual devices. CSS pixels aren't always physical pixels—zoom, viewport settings, and device pixel ratios matter. Verify with real fingers on real screens.

5. Leverage semantic HTML. Native <button> and <a> elements are easier to size consistently than <div> or <span> with click handlers.

Key WCAG techniques:

• C42: Using min-height and min-width to ensure target size
• G166: Providing audio alternatives for video-only content (not directly related, but often tested alongside)

Common Mistakes to Avoid

Tiny icon buttons with no padding. A 16×16px SVG icon wrapped in a <button> with no padding fails this criterion. Add padding or increase the button's dimensions.

Checkbox and radio inputs left at default size. Many browsers render these at 12–16px. Use CSS or custom controls to enlarge them, or wrap them in a larger clickable <label>.

Densely packed mobile navigation. Hamburger menus, close buttons, and nav icons crammed into a 40px header often fall short. Give each target breathing room.

Assuming visual size equals clickable size. A 20×20px icon might look small but have a 44×44px clickable area thanks to padding. Conversely, a large-looking element with pointer-events: none on part of it may have a smaller effective target.

How to Test for WCAG 2.5.5

Automated checks:

• Measure computed width and height of interactive elements in the DOM
• Flag buttons, links, and inputs smaller than 44×44px
• Identify clusters of targets without adequate spacing

Manual verification:

• Use browser DevTools to inspect computed dimensions and padding
• Test on touch devices (phone, tablet) to confirm real-world usability
• Check exceptions: Is a small inline link acceptable? Is there an equivalent larger target?
• Verify spacing: Are adjacent targets far enough apart to avoid accidental activation?

Checklist:

• All standalone buttons and links ≥44×44px?
• Form controls (checkboxes, radios, selects) ≥44×44px or wrapped in large labels?
• Icon-only buttons have sufficient padding or dimensions?
• Adequate spacing (≥8px) between adjacent interactive elements?

How TestParty Helps

TestParty's AI-powered accessibility platform automates detection, remediation, and monitoring of target size violations across your entire digital footprint—websites, web apps, and mobile interfaces.

What TestParty detects:

TestParty's DOM and source code analysis scans every interactive element on your pages and measures computed dimensions (width, height, padding, margin). It flags:

• Buttons, links, and form controls smaller than 44×44 CSS pixels
• Icon-only buttons with insufficient clickable area
• Checkboxes and radio inputs at default browser size (typically 12–16px)
• Densely packed navigation or toolbar elements with inadequate spacing
• Custom interactive widgets (star ratings, toggles, sliders) that don't meet minimum size

TestParty distinguishes between visual size and effective clickable area, accounting for padding and transparent borders. It also identifies inline links and other exceptions, surfacing them for human review rather than false-flagging.

How TestParty suggests fixes:

For each undersized target, TestParty generates code-level remediation:

• CSS patches adding min-width: 44px; min-height: 44px; to buttons and links
• Padding adjustments to expand clickable areas without changing visual design (e.g., padding: 12px; on a 20×20px icon button)
• Margin recommendations to space out adjacent targets and prevent mis-taps
• Custom control guidance for checkboxes, radios, and toggles—suggesting larger custom implementations or clickable label wrappers

These AI-generated fixes are reviewed by your developers or TestParty's accessibility specialists before being committed, ensuring they don't break layouts or conflict with design requirements.

Developer workflow integration:

TestParty integrates directly into your development lifecycle to catch target size issues before they reach production:

• CI/CD gates block pull requests that introduce undersized interactive elements
• PR annotations flag specific lines of code (e.g., a new button component) with target size violations and suggest fixes inline
• IDE plugins provide real-time feedback as developers write CSS or component code
• Pre-commit hooks warn when new interactive elements fall short of 44×44px

This shift-left approach prevents regressions—especially critical when rolling out new UI components, design system updates, or responsive breakpoints.

Ongoing monitoring:

TestParty continuously scans your live site and staging environments, tracking target size compliance over time:

• Dashboards show the count and severity of undersized targets across pages, templates, and components
• Regression alerts notify you when a deployment introduces new violations
• Audit-ready reports document compliance for legal, procurement, or accessibility audits, with before/after evidence of remediation

For ecommerce platforms (Shopify, WooCommerce, headless storefronts), TestParty works at the theme and template level—fixing a button component once cascades the improvement across thousands of product pages, checkout flows, and account interfaces.

TestParty's embedded guidance explains why each target size violation matters, helping teams internalize best practices and build accessible interfaces by default.

Some TestParty features described in this article are currently under development. Visit TestParty.ai to learn more about our current capabilities and roadmap, or book a demo at TestParty.ai/book-a-demo to see TestParty in action.

Disclaimer: Some of this article was generated with Large Language Models (LLMs) and Artificial Intelligence (AI). There may be some errors and we advise you to consult with human professionals for detailed questions.

FAQs About WCAG 2.5.5

What is WCAG 2.5.5 in plain language?

WCAG 2.5.5 requires clickable or tappable elements (buttons, links, form controls) to be at least 44 by 44 CSS pixels. This ensures users with motor impairments, tremors, or anyone using a touchscreen can reliably activate controls without frustration or errors.

Is WCAG 2.5.5 required for ADA compliance?

No—2.5.5 is a Level AAA criterion, and ADA compliance typically requires Level AA conformance. However, WCAG 2.2 introduced 2.5.8 Target Size (Minimum) at Level AA, which requires 24×24px. Many organizations adopt the stricter 44×44px standard (2.5.5) because it aligns with mobile platform guidelines and improves usability.

Does the 44×44px rule apply to inline links in paragraphs?

No—inline links (links within sentences or blocks of text) are exempt from the 44×44px requirement under the "Inline" exception. However, the clickable area should still be reasonably large (typically the line-height), and best practice is to ensure adequate spacing between lines to prevent mis-taps.

Can I use padding to meet the 44×44px requirement without changing visual size?

Yes—the clickable area (including padding and borders) must be 44×44px, but the visible icon or text can be smaller. For example, a 20×20px icon with 12px of padding on all sides creates a 44×44px clickable target. This is a common and effective technique for icon buttons.

How do I handle checkboxes and radio buttons that are too small?

Native checkboxes and radios are often 12–16px by default. You can enlarge them with CSS (width, height, transform: scale()), use custom-styled controls, or wrap them in a large clickable <label> element. The label itself can serve as the 44×44px target, making the entire label clickable.

What if I have a toolbar with many small icons?

If space is constrained, consider: (1) increasing icon button padding to meet 44×44px, (2) adding spacing between buttons to reduce mis-taps, (3) providing an equivalent larger menu or control elsewhere on the page (the "Equivalent" exception), or (4) using a responsive design that stacks or expands controls on smaller screens.