WCAG 2.5.8: Target Size (Minimum)

What This Rule Means

WCAG 2.5.8 Target Size (Minimum) is a Level AA success criterion introduced in WCAG 2.2. It states that the size of the target for pointer inputs must be at least 24×24 CSS pixels, with one important exception: if the target itself is smaller than 24×24 CSS pixels, then there must be sufficient offset spacing around it so that the total area — including the spacing — meets the 24×24 threshold in every direction. In other words, the target's bounding box plus any adjacent whitespace that is free of other targets must collectively reach 24 CSS pixels horizontally and 24 CSS pixels vertically.

The criterion applies to any element that can receive a pointer event: links (<a>), buttons (<button>), checkboxes, radio buttons, select controls, sliders, custom widgets with pointer event listeners, and any element given an ARIA role that implies interactivity. It does not apply to non-interactive elements such as decorative images or static text, even if they happen to be large.

A target passes this criterion when at least one of the following is true:

• The target's rendered size is at least 24×24 CSS pixels in both dimensions.
• The target is smaller than 24 CSS pixels in one or both dimensions, but the offset between the target's edge and the nearest adjacent interactive element is large enough so that the combined target-plus-offset area is at least 24×24 CSS pixels.
• The target is an inline element within a sentence or block of text, which is explicitly excluded because reflowing such targets would disrupt reading.
• The target's visual size is determined entirely by the browser's default user-agent stylesheet and the author has not modified it — this is the native-control exception.
• A non-interactive presentation of the same information exists and the small target is simply an alternative, not the only means of activation.

A target fails when it is smaller than 24×24 CSS pixels and there is not enough offset spacing to compensate, and none of the exceptions above apply. Common real-world failures include small icon-only buttons (such as a 16×16 close icon in a modal), tightly packed navigation links with minimal padding, and social-share icon rows where each icon is rendered at 20×20 pixels with only 2px of margin between them.

It is worth noting that WCAG 2.5.8 is a minimum requirement. The related AAA criterion 2.5.5 Target Size (Enhanced) requires at least 44×44 CSS pixels with no spacing offset exception, and many usability guidelines recommend 44–48 CSS pixels as a comfortable touch target. Meeting 2.5.8 is the floor, not the ceiling.

Why It Matters

Motor impairments affect pointer precision in a wide variety of ways. People with Parkinson's disease, essential tremor, cerebral palsy, multiple sclerosis, stroke-related hemiplegia, or repetitive strain injuries may be unable to land a pointer on a small target reliably. Older adults also experience a natural decline in fine motor control: approximately 15% of people over 65 report significant difficulty using a mouse or touchscreen. Beyond clinical conditions, even situationally impaired users — someone holding a smartphone with one hand on a moving bus, or someone whose finger is large relative to a small phone screen — struggle with tiny targets.

According to the World Health Organization, over 1.3 billion people worldwide live with some form of disability, and motor impairment is among the most common categories. When interactive elements are too small or too close together, these users experience accidental activations, missed taps, and repeated errors that make a site effectively unusable. The frustration is compounded on touch devices where there is no hover state to confirm cursor position before committing to a click.

Consider a concrete scenario: a Turkish e-commerce site selling electronics displays a row of five social-share icons at the top of each product page, each 18×18 pixels with 3px of gap between them. A user with essential tremor trying to share a product to WhatsApp repeatedly taps the wrong icon, triggering unwanted Facebook shares. There is no way for her to undo these shares quickly, and the task becomes so error-prone that she abandons it entirely. Increasing each icon to 24×24 CSS pixels, or adding padding so the clickable area reaches 24×24, would resolve the problem without changing the visual design significantly.

Beyond accessibility, adequate target sizing correlates with higher conversion rates, lower bounce rates, and better Core Web Vitals scores related to interaction readiness. Mobile-first indexing by search engines also favors pages that provide good touch usability, making target sizing a factor that intersects accessibility and SEO.

Related Axe-core Rules

• target-size (experimental): This rule checks whether interactive elements have a rendered size of at least 24×24 CSS pixels or, for smaller elements, whether sufficient offset spacing exists so the total reachable area meets the threshold. The rule queries the computed dimensions and bounding rectangles of focusable and pointer-interactive elements and flags any that fail the size-or-offset test. Because it is currently marked experimental, it is not included in axe-core's default ruleset and must be explicitly enabled with runOnly: { type: 'tag', values: ['wcag22aa', 'experimental'] } or by enabling experimental rules in axe DevTools. The rule may produce false positives for inline text links and native controls that browsers size differently across platforms, so manual review is always recommended after an automated scan. It cannot reliably detect spacing-based passes when complex CSS layouts, transforms, or overlapping z-index stacking contexts are involved, which is why manual inspection of computed styles in DevTools remains essential.

Because target size depends on visual rendering, computed CSS, viewport dimensions, and the proximity of neighboring interactive elements, automated tools can flag obvious failures but cannot replace human judgment. A tool can measure a button's bounding box, but determining whether the offset between two adjacent targets is truly free of other interactive elements — especially in dynamic or JavaScript-driven interfaces — requires manual verification.

How to Test

1. Automated scan with axe DevTools: Install the axe DevTools browser extension. Open the page under test. In the axe DevTools panel, enable experimental rules before running the scan (look for the rule tag filter and add experimental). After the scan completes, filter results by the rule ID target-size. For each flagged element, note the reported dimensions. Verify the finding manually before logging it as a confirmed failure, because experimental rules carry a higher rate of false positives.
2. Automated scan with Lighthouse: Run a Lighthouse accessibility audit in Chrome DevTools or via the CLI. Lighthouse includes a tap-targets audit that checks for targets smaller than 48×48 CSS pixels with insufficient spacing — note this uses a stricter threshold than WCAG 2.5.8, so Lighthouse failures are a superset of WCAG failures. Review the flagged elements in the report and cross-reference with the 24×24 WCAG threshold to determine which constitute actual Level AA failures versus best-practice recommendations.
3. Manual measurement with browser DevTools: Open DevTools and inspect each interactive element. In the Computed panel, check width and height. If either is below 24px, switch to the Box Model view and check padding. If padding brings the target to 24×24, it passes. If not, measure the gap to the nearest adjacent interactive element using the element's bounding rectangle: run document.querySelector('your-selector').getBoundingClientRect() in the console and compare the coordinates of neighboring elements. If the combined gap in each dimension brings the effective reachable area to 24px, it passes.
4. Touch simulation: In Chrome DevTools, enable device emulation and switch to a touch-optimized device profile. Attempt to tap each small interactive element. Note any instances where activating the intended element is difficult or where adjacent elements are accidentally triggered.
5. Keyboard and screen reader testing (for context): While WCAG 2.5.8 is specifically a pointer criterion, confirming that small targets also have visible focus indicators and are reachable by keyboard helps identify compound issues. Use NVDA with Firefox or JAWS with Chrome to navigate interactive elements and confirm they are reachable and activatable regardless of size.
6. Real device testing: Test on a physical mobile device — ideally both a large-screen Android and a smaller iOS device — to confirm that targets that pass on desktop also pass at mobile viewport sizes, since CSS pixel density and zoom behavior can affect perceived target size.

How to Fix

Small icon-only button — Incorrect

<!-- Close button is only 16x16 CSS pixels, no padding, adjacent to other controls -->
<button class='close-btn' aria-label='Close dialog'>
  <svg width='16' height='16' aria-hidden='true'></svg>
</button>

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

Small icon-only button — Correct

<!-- Adding padding increases the interactive area to 24x24 CSS pixels
     while the visual icon remains 16x16. The min-width/min-height
     ensures the target meets the WCAG 2.5.8 threshold. -->
<button class='close-btn' aria-label='Close dialog'>
  <svg width='16' height='16' aria-hidden='true'></svg>
</button>

<style>
  .close-btn {
    min-width: 24px;
    min-height: 24px;
    padding: 4px;
    border: none;
    background: none;
    cursor: pointer;
    display: inline-flex;
    align-items: center;
    justify-content: center;
  }
</style>

Tightly packed navigation links — Incorrect

<!-- Each link renders at roughly 20px tall with 1px margin,
     leaving insufficient offset spacing between targets -->
<nav aria-label='Main navigation'>
  <ul class='nav-list'>
    <li><a href='/about'>About</a></li>
    <li><a href='/services'>Services</a></li>
    <li><a href='/contact'>Contact</a></li>
  </ul>
</nav>

<style>
  .nav-list li { margin: 1px 0; }
  .nav-list a { font-size: 12px; line-height: 1.4; display: block; }
</style>

Tightly packed navigation links — Correct

<!-- Padding on each anchor ensures the target area is at least 24px tall.
     The gap between items is now large enough to satisfy the offset rule
     even if the text itself is smaller than 24px. -->
<nav aria-label='Main navigation'>
  <ul class='nav-list'>
    <li><a href='/about'>About</a></li>
    <li><a href='/services'>Services</a></li>
    <li><a href='/contact'>Contact</a></li>
  </ul>
</nav>

<style>
  .nav-list { list-style: none; padding: 0; margin: 0; }
  .nav-list a {
    display: block;
    padding: 6px 8px; /* vertical padding brings block height to >= 24px */
    font-size: 14px;
    line-height: 1.4;
    text-decoration: none;
  }
</style>

Checkbox with tiny hit area — Incorrect

<!-- The default checkbox is visually 13px on many browsers and has no
     associated label providing additional target area -->
<input type='checkbox' id='agree'>
<span>I agree to the terms</span>

Checkbox with associated label — Correct

<!-- Wrapping the input in a <label> makes the entire label text also
     a valid pointer target. The label's line-height and padding ensure
     the combined hit area easily exceeds 24x24 CSS pixels.
     The input itself is given min-width/min-height as a fallback. -->
<label class='checkbox-label'>
  <input type='checkbox' id='agree' class='checkbox-input'>
  I agree to the terms
</label>

<style>
  .checkbox-label {
    display: inline-flex;
    align-items: center;
    gap: 8px;
    padding: 4px 0;
    cursor: pointer;
    min-height: 24px;
  }
  .checkbox-input {
    min-width: 24px;
    min-height: 24px;
    cursor: pointer;
  }
</style>

Social share icon row — Incorrect

<!-- Each icon is 18x18px with only 2px gap; the combined
     reachable area for each icon is only 20px, below the 24px threshold -->
<div class='share-row'>
  <a href='#' aria-label='Share on Twitter'>
    <img src='twitter.svg' width='18' height='18' alt=''>
  </a>
  <a href='#' aria-label='Share on Facebook'>
    <img src='facebook.svg' width='18' height='18' alt=''>
  </a>
</div>

<style>
  .share-row { display: flex; gap: 2px; }
  .share-row a { display: inline-block; line-height: 1; }
</style>

Social share icon row — Correct

<!-- Each anchor now has min-width and min-height of 24px via padding,
     and the gap between anchors is at least 3px so the offset rule is
     satisfied independently even without the padding. -->
<div class='share-row'>
  <a href='#' class='share-link' aria-label='Share on Twitter'>
    <img src='twitter.svg' width='18' height='18' alt=''>
  </a>
  <a href='#' class='share-link' aria-label='Share on Facebook'>
    <img src='facebook.svg' width='18' height='18' alt=''>
  </a>
</div>

<style>
  .share-row { display: flex; gap: 6px; }
  .share-link {
    display: inline-flex;
    align-items: center;
    justify-content: center;
    min-width: 24px;
    min-height: 24px;
    padding: 3px;
  }
</style>

Common Mistakes

• Setting width and height on the icon inside a button rather than on the button itself: Developers often constrain the SVG or image to 16–20px but forget that the <button> element needs min-width: 24px; min-height: 24px and appropriate padding to create an adequate tap target.
• Removing default browser padding from buttons and inputs with padding: 0 or a global reset: CSS resets that zero out padding on form elements eliminate the buffer that keeps native controls at a usable size. Always re-add explicit padding after a reset.
• Relying on line-height alone to increase link height without display: block or display: inline-block: Inline elements do not respond to height or vertical padding in the way block elements do, so a link may appear taller visually while its actual clickable bounding box remains small.
• Using pointer-events: none on a wrapper and attaching click handlers to a tiny inner element: This defeats any padding or min-size applied to the wrapper, reducing the effective target to the inner element's rendered size.
• Applying overflow: hidden to a button container that clips the button's padding: The visual click area is clipped to the container's boundaries, making the effective target smaller than the button's own dimensions suggest.
• Forgetting to account for CSS transforms such as scale(): A button scaled down visually via transform: scale(0.7) still has its original bounding box for pointer events in most browsers, but this behaviour is inconsistent and unreliable — always size targets at their final rendered scale.
• Assuming that a large <label> compensates for a tiny <input> when the label and input are not programmatically associated: If the <label> does not use for matching the input's id, or if the input is not wrapped inside the label, clicking the label text does not activate the input, so only the input's own small target area is functional.
• Not testing at the viewport sizes where targets are actually rendered: A button that is 32×32 CSS pixels on desktop may be rendered at 22×22 CSS pixels on a narrow mobile viewport due to fluid scaling or viewport-relative units (vw, vmin), creating a failure that only appears on mobile.
• Treating the WCAG 2.5.8 exception for inline text links too broadly: The exception applies only to links that are genuinely inline within a run of text (e.g., a hyperlink inside a paragraph). Stand-alone links styled to look like text — such as a "Forgot password?" link below a form — are not inline links and must meet the 24×24 threshold.
• Not auditing third-party widgets and embedded components: Cookie consent banners, chat widgets, and analytics overlays frequently include tiny buttons (accept, close, minimize) injected by external scripts. These are still part of the page's accessibility posture and must comply with WCAG 2.5.8 even if the code is not authored in-house.

Relation to Turkey's Accessibility Regulations

Turkey's Presidential Circular 2025/10, published in Official Gazette No. 32933 on 21 June 2025, establishes binding accessibility requirements for a broad range of digital service providers operating in Turkey. The Circular explicitly references WCAG 2.2 as the technical standard, and Level AA conformance is required to qualify for the Erişilebilirlik Logosu (Accessibility Logo) issued by the Ministry of Family and Social Services (Aile ve Sosyal Hizmetler Bakanlığı). Because WCAG 2.5.8 is a Level AA criterion in WCAG 2.2, it falls directly within the scope of this mandatory framework.

The entity types covered by the Circular include public institutions and government agencies at central and local levels, banks and financial services firms, hospitals and private healthcare providers, telecommunications operators with 200,000 or more subscribers, e-commerce platforms, travel agencies, private transport companies, and private schools authorized by the Ministry of National Education (Milli Eğitim Bakanlığı). For all of these organisations, WCAG 2.5.8 compliance is not merely a best-practice recommendation — it is a regulatory obligation tied to the ability to display the Accessibility Logo and to demonstrate legal compliance during audits.

In practical terms, this means that a Turkish bank's mobile-responsive web application must ensure that its transfer confirmation buttons, one-time password input fields, and navigation controls all meet the 24×24 CSS pixel minimum target size. Similarly, an e-commerce site must verify that its add-to-cart buttons, quantity selectors, and filter controls are adequately sized across all device profiles. Healthcare portals must audit appointment-booking calendars, which are notorious for small date cells, and either expand those cells or provide sufficient offset spacing. Telecom self-service portals must check that their account management links and toggle controls in data-plan selectors meet the threshold.

Failure to comply with the Circular can result in administrative sanctions and may preclude an organisation from displaying the Accessibility Logo, which is increasingly used as a trust signal by Turkish consumers. Beyond penalties, non-compliance exposes organisations to complaints filed with the relevant supervisory bodies. Given that Turkey has a growing population of older adults — the Turkish Statistical Institute projects that people aged 65 and over will comprise 16.3% of the population by 2040 — the practical impact of small targets will only increase over time, making early compliance both an ethical priority and a sound long-term business strategy.