2.5.8 Target Size (Minimum)
- Level AA
- Operable
- New in WCAG 2.2
Summary
Small tap targets are one of the most common barriers for people with tremors, limited dexterity, or larger fingers, and for anyone using a phone one-handed or on the move. This criterion sets a floor: anything a pointer can activate (buttons, links, icons, form controls) must either be at least 24 by 24 CSS pixels, or have enough clear space around it that a 24 pixel circle centred on it does not overlap a neighbouring target.
The requirement is new in WCAG 2.2 at Level AA. It applies to the size of the activation area, not the visible artwork: a 16 pixel icon inside a 32 pixel padded button passes comfortably. Five exceptions (spacing, equivalent, inline, user agent control, essential) narrow the scope, and most disputes in an audit turn on whether one of them genuinely applies.
Official wording
The size of the target for pointer inputs is at least 24 by 24 CSS pixels, except when:
Spacing: Undersized targets (those less than 24 by 24 CSS pixels) are positioned so that if a 24 CSS pixel diameter circle is centered on the bounding box of each, the circles do not intersect another target or the circle for another undersized target;
Equivalent: The function can be achieved through a different control on the same page that meets this criterion;
Inline: The target is in a sentence or its size is otherwise constrained by the line-height of non-target text;
User Agent Control: The size of the target is determined by the user agent and is not modified by the author;
Essential: A particular presentation of the target is essential or is legally required for the information being conveyed.
EN 301 549 mapping
This success criterion is new in WCAG 2.2. EN 301 549 V3.2.1, the harmonised European standard currently in force, references WCAG 2.1 and contains no clause for it. A revision aligned with WCAG 2.2 is in progress; until it is published and cited in the Official Journal of the EU, this criterion is not part of the harmonised standard.
Checked against EN 301 549 V3.2.1 (2021-03).
In practice
Web
Measure the target's hit area, not its visual footprint. In browser developer tools, inspect the element and read the computed size of its bounding box, including padding (padding is part of the clickable area; margin is not). Anything interactive that measures at least 24 by 24 CSS pixels passes without further analysis.
For smaller targets, apply the spacing test: imagine a 24 pixel diameter circle centred on the target's bounding box. If that circle does not intersect any adjacent target, or the circle of any adjacent undersized target, the spacing exception applies. In practice this means undersized controls need breathing room in every direction, which is where dense toolbars, pagination controls, and icon rows most often fail.
Two exceptions do a lot of work on the web. Links inside a paragraph are exempt (inline exception): a text link's height is constrained by the line height of the surrounding prose. Unstyled native form controls are exempt (user agent control): a default checkbox is the browser's sizing decision, not the author's. The moment you style that checkbox or pull the link out of the sentence into a standalone menu item, the exemption is gone.
iOS
CSS pixels correspond to points (pt) on iOS at standard scale, so the WCAG floor is 24 by 24 pt. Note that Apple's own Human Interface Guidelines recommend 44 by 44 pt for all controls: a target that follows platform guidance passes this criterion with a wide margin, and a target that fails WCAG's 24 pt floor is severely undersized by the platform's own standards.
Measure the tappable frame, not the glyph. An SF Symbol icon rendered at 17 pt inside a UIButton whose frame is 44 by 44 pt is a 44 pt target. Use Xcode's view debugger (Debug View Hierarchy) or Accessibility Inspector to read the frame of the control; on device, enabling Developer settings touch indicators can help confirm what actually receives the tap. Watch for custom hit testing: overriding point(inside:with:) or adding a larger hitTest region enlarges the effective target even when the frame looks small, and the effective target is what this criterion measures.
Common iOS failure spots: custom toolbars with tightly packed 20 pt icons, table row accessory icons, tag chips, and close buttons on cards or sheets positioned hard against other controls.
Android
CSS pixels correspond to density-independent pixels (dp) on Android, so the WCAG floor is 24 by 24 dp. Material Design guidance recommends touch targets of at least 48 by 48 dp, so, as on iOS, platform-conformant apps clear this criterion easily and WCAG failures indicate a control well below platform norms.
Measure the touchable bounds, not the drawable. Use Layout Inspector in Android Studio, or enable "Show layout bounds" in developer options on device, to see each view's actual bounds. Android also lets authors expand a small view's touchable area with TouchDelegate (or InteractionSource padding patterns in Compose); where a delegate is present, the expanded area is the target. Accessibility scanning built into modern Android tooling flags touch targets below 48 dp, which is stricter than WCAG: treat those flags as platform guidance, and grade against the 24 dp WCAG floor with the spacing exception in mind.
Common Android failure spots: overflow icons in dense list rows, custom seekbar thumbs, chip close icons, and adjacent icon buttons in custom bottom bars.
Pass and fail examples
Passes:
- A 16 pixel gear icon inside a button with 8 pixels of padding on every side: the activation area is 32 by 32, well above the floor.
- A row of 20 by 20 pixel toolbar icons spaced 28 pixels apart centre to centre: each 24 pixel circle stays clear of its neighbours' circles, so the spacing exception applies.
- A "terms and conditions" link inside a sentence of body text: inline exception.
- An unstyled native browser checkbox: user agent control exception.
- A tiny 18 by 18 map pin where a full-size "view location" button elsewhere on the same screen does the same job: equivalent exception, provided the alternative genuinely performs the same function.
Fails:
- Pagination dots 10 pixels wide with 6 pixel gaps: undersized and their 24 pixel circles overlap the neighbouring dots.
- A 16 by 16 close icon in the corner of a banner, flush against a link: undersized, no clear space, no qualifying exception.
- A styled custom checkbox rendered at 18 by 18 pixels: styling it removed the user agent exemption.
- Stacked comment action links ("Reply", "Edit", "Delete") rendered outside sentences at 17 pixel line height with no spacing: they are standalone targets, not inline in a sentence, so the inline exception does not apply.
Not a fail under this criterion:
- A target that is hard to see but comfortably sized: low visual contrast belongs to 1.4.11 Non-text Contrast, not here.
- Each selectable position on a slider or colour gradient: controls where a value is chosen by position count as a single target under the criterion's note, so you grade the control once as a whole rather than grading every selectable point. The whole control must still be adequately sized or spaced.
Commonly confused with
- Target Size (Enhanced), SC 2.5.5. The Level AAA sibling requires 44 by 44 CSS pixels with fewer exceptions. If an auditor cites a 44 pixel expectation against a Level AA audit, they are applying the AAA criterion (or platform guidance) rather than 2.5.8.
- Platform guidelines (44 pt on iOS, 48 dp on Android). These are platform recommendations, not WCAG requirements. An app can miss the platform figure and still pass WCAG's 24 pixel floor. Report the two separately: one is a conformance result, the other is a quality recommendation.
- Visual size versus hit area. A small icon is not automatically a failure; the measurement is the activation area including padding and any expanded hit region. Grading the artwork instead of the target is the most common false fail in practice.
- Non-text Contrast, SC 1.4.11. "I can barely see this control" is a contrast finding; "I can barely hit this control" is a target size finding. Dense little icons often earn both, but they are separate criteria with separate evidence.
- Dragging Movements, SC 2.5.7. Also new in WCAG 2.2 and often reviewed on the same screens. 2.5.7 asks whether dragging has a single-pointer alternative; 2.5.8 asks whether the thing you press is big enough. A tiny drag handle can fail both.
How AUDITSU tests this
AUDITSU's audit walkthrough includes target size in its visual checks for every screen you review. The walkthrough asks you to identify interactive elements that look small or crowded, measure the suspect ones (activation area, not artwork), and apply the spacing circle test before grading. Each question records a pass, fail, or not applicable result per screen, with the evidence attached, so the finding lands in your report tied to the exact screen and control.
Because EN 301 549 V3.2.1 does not yet include this criterion, AUDITSU tracks it under WCAG 2.2 conformance. When your audit targets the European Accessibility Act, the walkthrough treats 2.5.8 as forward guidance until the revised harmonised standard adopts WCAG 2.2.
For the full guided workflow, see the audit platform.