WCAG 2.5.5: Target Size (Enhanced)

What This Rule Means

WCAG 2.5.5 Target Size (Enhanced) is a Level AAA criterion under WCAG 2.2 that sets a strict minimum size for interactive elements. Specifically, it requires that the size of the target — the clickable or tappable area of any user interface component — must be at least 44 by 44 CSS pixels in both width and height. This applies to all pointer-based interactions including mouse clicks, touchscreen taps, and stylus input.

It is important to understand what exactly constitutes the "target" in this context. The target is the entire activatable area of the control, not just its visual representation. A small icon might be visually 16×16 pixels, but if the surrounding padding expands the clickable region to 44×44 pixels, the criterion can still be satisfied. This means developers can use padding strategically to meet the requirement without altering the visual design dramatically.

The criterion defines a pass as any interactive element whose target area measures at least 44×44 CSS pixels. A fail occurs when an interactive element's activatable area falls below this threshold in either dimension — for example, a link that is 44 pixels wide but only 20 pixels tall would still fail.

WCAG 2.5.5 provides several official exceptions where the 44×44 requirement does not apply. These are:

• Spacing: Undersized targets are acceptable if sufficient offset spacing separates them from all other targets. The target must be positioned so that, if a 44×44 CSS pixel circle were centered on it, that circle would not intersect any other target or the bounding box of any other target's 44×44 circle. This exception prevents the rule from requiring layout changes when adjacent controls are inherently small but well-separated.
• Equivalent: An alternative control on the same page performs the same function and meets the minimum size requirement.
• Inline: The target is in a sentence or its size is otherwise constrained by the line-height of non-target text. Hyperlinks within a paragraph of body text, for instance, are exempt because resizing them would disrupt the text flow.
• User agent control: The size is determined entirely by the browser or operating system and cannot be altered by the author. Native browser form controls in their unstyled state may fall into this category.
• Essential: A particular presentation of the target is essential to the information being conveyed. This is a narrow exception for cases where changing the target size would fundamentally alter meaning or functionality.

This criterion was introduced in WCAG 2.2 and supersedes the earlier, less stringent guidance on pointer targets. Its companion criterion, WCAG 2.5.8 Target Size (Minimum) at Level AA, sets a lower bar of 24×24 CSS pixels with a spacing-based calculation, but 2.5.5 remains the gold standard for enhanced accessibility.

Why It Matters

Motor and dexterity impairments affect a substantial portion of the global population. According to the World Health Organization, approximately 1.3 billion people — or 16% of the world's population — live with some form of significant disability, with motor and musculoskeletal conditions being among the most prevalent. Conditions such as Parkinson's disease, essential tremor, cerebral palsy, multiple sclerosis, stroke-related hemiplegia, and repetitive strain injuries all reduce a person's ability to perform precise pointer movements. On mobile devices, even users without disabilities may struggle with small targets when using gloves, when their hands are wet, or simply when using a phone one-handed.

Consider a concrete real-world scenario: a person with rheumatoid arthritis is browsing a Turkish e-commerce platform on a touchscreen tablet to purchase medication. The checkout flow includes small radio buttons, narrow dropdown menus, and a 24×18 pixel "Confirm Order" button. Each mis-tap either selects the wrong option or does nothing, forcing the user to retry multiple times. The frustration is not merely inconvenient — it may cause them to abandon the purchase entirely, turning an accessibility failure into a direct revenue loss for the business.

Beyond motor impairments, adequately sized targets benefit a wide range of users. Older adults commonly experience reduced fine motor control and diminished visual acuity simultaneously, making small targets doubly difficult. Users with cognitive disabilities may take longer to position a pointer and are more likely to trigger adjacent controls if targets are crowded. Even sighted, able-bodied users benefit from larger targets on mobile devices — a truth that has driven design conventions at major technology companies for years. Apple's Human Interface Guidelines recommend a minimum tap target of 44×44 points, and Google's Material Design guidelines recommend at least 48×48 density-independent pixels for the same reasons.

From an SEO and usability perspective, Google's Core Web Vitals metric "Interaction to Next Paint" (INP) rewards interfaces where user interactions are registered quickly and correctly. Mis-taps caused by undersized targets inflate interaction failure rates, inflate time-on-task, and increase bounce rates — all signals that can indirectly affect search ranking. Accessibility improvements at the pointer level therefore have measurable business consequences beyond compliance.

Related Axe-core Rules

WCAG 2.5.5 requires manual testing. There is no fully automated axe-core rule that reliably flags all target size violations for this enhanced criterion. The reason automated tools struggle here is multifaceted: the effective target size depends on computed CSS layout including padding, margin, and pseudo-element dimensions that vary by viewport, device pixel ratio, and dynamic rendering. Additionally, the spacing exception requires calculating the geometric offset between adjacent targets — a calculation that requires the full rendered layout tree and proximity analysis that automated DOM-parsing tools cannot perform accurately in all cases. Furthermore, whether an element qualifies for the "inline" or "equivalent" exception requires semantic and contextual understanding that is beyond automated rule engines.

• target-size (axe-core experimental): Axe-core includes an experimental rule named target-size that checks interactive elements against the WCAG 2.5.8 Level AA threshold of 24×24 CSS pixels with spacing offsets. While this rule can surface some smaller violations, it does not enforce the stricter 44×44 threshold required by 2.5.5, and it may miss violations where padding or pseudo-elements affect the rendered hit area in ways the DOM snapshot does not capture. Treat any results from this rule as a starting point, not a complete audit.
• Manual visual inspection: Because no automated rule fully covers 2.5.5, testers must visually inspect and measure interactive targets using browser developer tools, CSS pixel rulers, or accessibility browser extensions. This includes checking that padding is included in the hit area and that spacing exceptions are genuinely met — not merely assumed.

How to Test

1. Run an automated scan as a baseline: Open axe DevTools or Lighthouse in Chrome DevTools on the page under test. In axe DevTools, filter results by "target-size" if available under experimental rules. Note any flagged elements, but understand this scan will not catch all 2.5.5 violations and may reference the 2.5.8 threshold rather than 44×44 pixels. Use Lighthouse's accessibility audit to look for related pointer-target warnings.
2. Measure target sizes with browser DevTools: Open Chrome or Firefox DevTools and use the Elements panel to inspect each interactive element — buttons, links, form inputs, checkboxes, radio buttons, custom controls, and icon-only controls. In the Computed styles panel, check the rendered width and height. Remember that padding is included in the click target for block-level elements but may not be for inline elements. Verify that the computed hit area is at least 44×44 CSS pixels.
3. Use the browser's built-in accessibility tools: In Chrome DevTools, open the Rendering tab and enable "Emulate a focused page" or use the Accessibility Tree to inspect elements. For Firefox, use the Accessibility Inspector to identify interactive elements and cross-reference their bounding box dimensions.
4. Test on real touch devices: Connect a physical iOS device and test with VoiceOver enabled (triple-press the side button to activate). Navigate by tapping and use the rotor to move between interactive elements. Attempt to activate small targets and note how often adjacent elements are accidentally triggered. Repeat on an Android device using TalkBack (swipe right to navigate, double-tap to activate). Pay special attention to custom widgets built from <div> or <span> elements.
5. Test spacing exceptions manually: For any target smaller than 44×44 pixels that claims the spacing exception, draw an imaginary 44×44 pixel bounding box centered on that target and visually confirm that no other interactive element falls within that box. Browser extensions or overlay tools that draw bounding boxes can assist here.
6. Keyboard and screen reader verification: Test with NVDA + Firefox and JAWS + Chrome by tabbing through all interactive elements. While keyboard focus does not directly test pointer target size, it helps identify whether any controls are reachable and confirms the element inventory against which you will cross-reference pointer sizes. VoiceOver + Safari on macOS can be used to verify that custom controls announce themselves correctly and have adequate activation areas when pointer-clicked.
7. Test at multiple viewport sizes: Target sizes can vary between desktop and mobile layouts. Test at 320px, 768px, and 1280px viewport widths to confirm that responsive designs maintain the 44×44 minimum at all breakpoints, particularly in hamburger menus, carousels, and data table action columns.

How to Fix

Icon-only button with insufficient size — Incorrect

<!-- A close button rendered as a small SVG icon with no padding.
     The rendered size is approximately 16x16 CSS pixels, far below the 44x44 minimum. -->
<button class='close-btn'>
  <svg width='16' height='16' aria-hidden='true'>
    <use href='#icon-close'></use>
  </svg>
  <span class='sr-only'>Close dialog</span>
</button>

<style>
.close-btn {
  background: none;
  border: none;
  padding: 0;
  cursor: pointer;
}
</style>

Icon-only button with insufficient size — Correct

<!-- Padding is added to expand the hit area to at least 44x44 CSS pixels
     while preserving the visual icon size. The button itself has explicit
     min-width and min-height to guarantee compliance across browsers. -->
<button class='close-btn'>
  <svg width='16' height='16' aria-hidden='true'>
    <use href='#icon-close'></use>
  </svg>
  <span class='sr-only'>Close dialog</span>
</button>

<style>
.close-btn {
  background: none;
  border: none;
  padding: 14px; /* 16px icon + 14px * 2 padding = 44px total hit area */
  min-width: 44px;
  min-height: 44px;
  cursor: pointer;
  display: inline-flex;
  align-items: center;
  justify-content: center;
}
</style>

Custom checkbox built from a div — Incorrect

<!-- A visually styled custom checkbox that is too small to meet the target size
     requirement. The div has no padding and renders at 20x20 pixels. -->
<div role='checkbox' aria-checked='false' tabindex='0' class='custom-check'></div>

<style>
.custom-check {
  width: 20px;
  height: 20px;
  border: 2px solid #333;
  border-radius: 3px;
  cursor: pointer;
}
</style>

Custom checkbox built from a div — Correct

<!-- The visual box remains 20x20 pixels but is wrapped in a label element
     whose total clickable area is expanded to 44x44 via padding.
     Using a native input element is strongly preferred over role=checkbox
     because it provides built-in keyboard and pointer behavior. -->
<label class='check-wrapper'>
  <input type='checkbox' class='sr-only'>
  <span class='custom-check' aria-hidden='true'></span>
  Subscribe to newsletter
</label>

<style>
.check-wrapper {
  display: inline-flex;
  align-items: center;
  gap: 8px;
  min-height: 44px; /* entire label row is at least 44px tall */
  cursor: pointer;
  padding: 12px 0; /* vertical padding expands the hit area */
}
.custom-check {
  width: 20px;
  height: 20px;
  border: 2px solid #333;
  border-radius: 3px;
  flex-shrink: 0;
}
.sr-only {
  position: absolute;
  width: 1px;
  height: 1px;
  padding: 0;
  margin: -1px;
  overflow: hidden;
  clip: rect(0,0,0,0);
  white-space: nowrap;
  border: 0;
}
</style>

Navigation links in a toolbar with crowded spacing — Incorrect

<!-- Toolbar links rendered as small inline elements.
     Each link is approximately 32px wide and 24px tall,
     and they are spaced only 4px apart — failing both size and spacing exceptions. -->
<nav aria-label='Secondary navigation'>
  <a href='/help' class='nav-link'>Help</a>
  <a href='/settings' class='nav-link'>Settings</a>
  <a href='/logout' class='nav-link'>Logout</a>
</nav>

<style>
.nav-link {
  font-size: 12px;
  padding: 2px 4px;
  margin: 0 2px;
}
</style>

Navigation links in a toolbar with crowded spacing — Correct

<!-- Each link now has padding that expands its hit area to at least 44x44 px.
     The gap between links is also increased so the spacing exception would
     apply even if sizing were relaxed in future. -->
<nav aria-label='Secondary navigation'>
  <a href='/help' class='nav-link'>Help</a>
  <a href='/settings' class='nav-link'>Settings</a>
  <a href='/logout' class='nav-link'>Logout</a>
</nav>

<style>
.nav-link {
  font-size: 14px;
  display: inline-flex;
  align-items: center;
  min-height: 44px;
  padding: 0 16px; /* horizontal padding extends width well past 44px */
  margin: 0 4px;
  text-decoration: underline;
}
</style>

Common Mistakes

• Assuming the visual bounding box equals the hit area: Setting width: 44px; height: 44px on the icon image inside a button does not make the button 44×44 — only adding those dimensions or equivalent padding to the <button> element itself creates the correct hit area.
• Using padding: 0 to reset browser styles without a compensating minimum size: CSS resets often strip all padding from buttons and inputs. After a reset, always re-apply sufficient padding or explicit min-width and min-height values to restore the activation area.
• Relying on line-height alone to increase target height: Increasing line-height affects text spacing but does not always expand the clickable area of an anchor or button. Use padding-top and padding-bottom instead.
• Placing multiple small icon buttons side-by-side without sufficient spacing: A row of 24×24 social media share icons with only 2px margins fails both the size requirement and the spacing exception, since the 44px circles centered on each icon would overlap their neighbors.
• Misapplying the inline text exception to navigation links: The exception applies to links within a sentence or paragraph of flowing text. Navigation menus, toolbars, and lists of links are not inline text and do not qualify for this exception, even if they use display: inline.
• Building custom controls with role='button' on a <span> and forgetting to size the span: Screen readers will announce the span as a button, but its default rendered size will be determined only by its text content, which is typically far below 44×44 pixels. Always add display: inline-flex, min-width, min-height, and padding.
• Not testing on real touch devices at the actual viewport size: Measuring pixels in desktop DevTools is not sufficient. CSS pixel density and OS-level touch target hit-testing behavior can differ between simulated and physical device environments.
• Overlooking dynamically rendered controls: Tooltips, datepicker day cells, autocomplete suggestion items, and modal close buttons are often injected by JavaScript libraries with hardcoded small sizes. Audit third-party widget output and override their styles if necessary.
• Claiming the spacing exception without measuring it: The spacing exception is geometric and precise. Visually assuming that controls look far enough apart is not sufficient — the 44px circle test must be applied to each undersized target to confirm no overlap exists.
• Forgetting to verify after responsive breakpoint changes: A button that is 44×44 on desktop may collapse to 30×30 on a 375px mobile viewport due to percentage widths or flexbox shrinking. Always re-test target sizes at every major breakpoint.

Relation to Turkey's Accessibility Regulations

Turkey's Presidential Circular No. 2025/10, published in the Official Gazette No. 32933 on June 21, 2025, establishes mandatory web and mobile accessibility requirements based on the WCAG 2.2 standard. The circular applies to a defined set of entities operating within Turkey and sets legal obligations for conformance to specific WCAG levels.

The covered entity types under the circular include: public institutions and agencies at both central and local government level; banks and financial institutions regulated by the Banking Regulation and Supervision Agency (BDDK); hospitals and healthcare providers, both public and private; telecommunications operators with 200,000 or more subscribers; e-commerce platforms above specified revenue or transaction thresholds; travel agencies operating online booking services; private transport companies offering digital ticketing or reservation; and private schools and educational institutions authorized by the Ministry of National Education (MoNE).

WCAG 2.5.5 Target Size (Enhanced) is a Level AAA criterion and is not among the minimum mandatory requirements established by the circular, which focuses primarily on Level A and AA compliance. However, the circular explicitly encourages covered entities — particularly those serving the public, healthcare patients, and students — to pursue AAA conformance where feasible, recognizing that it represents best-in-class accessibility practice.

For organizations in Turkey, implementing WCAG 2.5.5 carries particular strategic value in several contexts. Government portals serving elderly citizens, healthcare scheduling systems used by patients with chronic conditions, and banking applications accessed by people with motor impairments all benefit substantially from 44×44 pixel target sizes. Turkey has a rapidly aging population, and the Turkish Statistical Institute (TÜİK) projects that citizens aged 65 and older will constitute over 16% of the population by 2040 — a demographic for whom pointer target size is a critical usability factor.

Even where AAA is not legally mandated, organizations that voluntarily meet WCAG 2.5.5 demonstrate a commitment that can reduce litigation risk, strengthen procurement eligibility for government contracts that require accessibility documentation, and improve user satisfaction metrics in competitive markets such as e-commerce and fintech. Accsible's SDK provides configurable touch-target enhancement features that can help organizations meet or approach this criterion, and documentation of such efforts can form part of an Accessibility Conformance Report (ACR) or VPAT submission required by institutional procurement processes.