What WCAG Actually Requires for Touch Targets
Two WCAG Success Criteria govern the minimum size of interactive elements, and they are frequently conflated. The one that matters for most projects is Success Criterion 2.5.8: Target Size (Minimum), introduced in WCAG 2.2 (published October 5th, 2023) and rated level AA — the de facto standard for public websites.
Under SC 2.5.8, the bare minimum for a non-inline interactive element is 24×24 CSS pixels. This is separate from SC 2.5.5: Target Size (Enhanced), which is level AAA and demands targets of at least 44×44 pixels. Level AAA conformance is rarely required; it is typically reserved for large or specialized institutions. Until WCAG 3.0 ships — a milestone still a decade or more away — WCAG 2.2 remains the governing standard.
Expanding Targets Without Changing Layout
The simplest way to meet SC 2.5.8 is to expand the clickable area with CSS padding. A 16×16-pixel icon, for instance, becomes conformant with a padding: 4px declaration, which invisibly grows its bounding box to 24×24 pixels.
CSS margin is a different story. While the SC's spacing exception technically permits undersized targets when a 24-pixel-diameter circle centered on each target's bounding box does not intersect another target, margin does not enlarge the interactive region itself. Relying on that exception to game the criterion is what Adrian Roselli has called adversarial conformance — it may pass an automated check but fails the intent of helping users actually click or tap the element.
Inline Elements Are Exempt
Targets that appear inline within a line of text — such as links inside a paragraph — do not need to meet the 24×24 minimum. The SC explicitly carves out cases where "the target is in a sentence or its size is otherwise constrained by the line-height of non-target text."
The size of the target for pointer inputs is at least 24×24 CSS pixels, except where:
Inline: The target is in a sentence or its size is otherwise constrained by the line-height of non-target text;
Apple, Android, and Unit Confusion
Part of the confusion around target sizes comes from platform guidelines that appear to contradict WCAG. Apple's Human Interface Guidelines recommend interactive elements of at least 44×44 points, while Google's Material Design specifies 48×48 density-independent pixels. These numbers exceed WCAG's minimums, but they are expressed in platform-specific units — points and dp — not CSS pixels, and the three are frequently (and incorrectly) treated as interchangeable.
The hierarchy of authority matters here:
Human interface guidelines inform design systems, which shape the sites and apps authors build. But they are not the arbiters of accessibility compliance. WCAG sits at the top of that chain, and third-party guidelines—no matter how well-intentioned—do not override or redefine its criteria.
The Media Query Dead End
Some developers have tried to use the CSS pointer media feature to detect touchscreens and conditionally enlarge targets only for coarse pointers. The logic assumes mice are for fine movements and touchscreens for broad gestures. That assumption breaks down quickly because devices are multimodal: a touchscreen laptop supports a trackpad, keyboard, mouse, and voice input simultaneously, without any mode switch.
The detection approach also fails to account for motor control conditions. People with hand tremors or arthritis often use mice — fine input may be painful but still the user's preferred method. Meanwhile, stylus accessories enable fine detail work on touchscreens, and users plug mice and keyboards into phones. A mode-based approach to inclusive design is both more work to build and maintain, and it fundamentally misreads how people interact with their devices.
Responsive vs. Inclusive Design
These terms are often used interchangeably but refer to different goals:
- Responsive Design is about designing for an unknown device.
- Inclusive Design is about designing for an unknown user.
Building one experience that accommodates an unknown number of people using an unknown suite of devices in unknown ways is more proactive, costs less to create and maintain, delivers less data, and carries less compliance risk than maintaining separate input-mode experiences. Recognizing that inputs can come from unexpected sources — a tongue-operated touchpad, an eyebrow-raising head pointer — reinforces why designing for inclusive interactions by default is the more robust path.
Minimum Is Not a Synonym for Optimal
The WCAG 24×24 CSS pixel minimum for interactive targets represents the industry’s consensus on a baseline that works for most people in most situations. But it is important to parse that sentence carefully: the operative word is minimum.
The spec itself acknowledges that this size is a compromise between universal functionality and broad feasibility, which is exactly why the stricter SC 2.5.5 carries an AAA rating. Even the criterion’s own documentation concedes the limits of the rule:
“This Success Criterion defines a minimum size and, if this can’t be met, a minimum spacing. It is still possible to have very small and difficult-to-activate targets and meet the requirements of this Success Criterion.”
In practice, moving toward a 40-pixel target can meaningfully improve usability for people who struggle with the smaller conformant size. The 24×24 rule is not a recommendation; it is a floor.
When Bigger Starts to Backfire
There is also a real risk in overcorrecting. Oversized interactive areas are prone to accidental activation, especially when placed near other controls. That risk becomes more serious when a mis-tap triggers an irreversible action, such as a delete or a financial transaction.
Another subtle failure mode: elements that are large enough may no longer read as interactive. Users scan for visual affordances, and an element that occupies too much space can be mistaken for static content and skipped entirely.
Context Should Drive the Decision
Choosing the right target size requires knowing who your users are, why they are on your service, and the physical circumstances in which they interact with it. The Glow Baby app, for instance, deliberately enlarges its touch targets because its primary audience is parents holding a squirming infant while trying to log feeding times or check charts.
WCAG itself supports this situational thinking. SC 2.5.8 includes an Essential exception for cases where the position of a target is part of its meaning, such as map pins that must sit on their corresponding locations. But this exemption is not a loophole to exploit for convenience; it is a documented mechanism for cases where the rule genuinely cannot apply, and the guidance strongly encourages providing alternative paths to the same functionality where practical.
Device and Environment Matter
Target size decisions do not happen in a vacuum. Large fixed touchscreens, such as kiosks, benefit from larger interactive areas simply because the user’s reach and the screen geometry demand it. On the other end of the scale, smartwatches are moved constantly in space, and voice input may serve users better than trying to hit a tiny on-screen control.
Contexts of use are equally decisive. In-car interfaces should minimize distraction with simple, large controls that keep eyes on the road. High-stress settings like hospitals and oil rigs call for the same treatment. Audiences also shape the requirement: software built for children or for older adults, where age-related motor and vision decline is common, generally needs targets that exceed the WCAG floor.
That does not mean every interface must be resized up. Dense, data-heavy tools like the Bloomberg terminal remain usable and understandable with tightly packed controls precisely because their expert users work in a context where information density trumps generous spacing.
Design Systems as a Safety Net
Component libraries offer one of the best opportunities to embed accessible defaults—not by dictating a single size, but by offering a range. A button component might ship in small, medium, and large variants, where the smallest is still WCAG-conformant and the larger options exist for contexts that demand more generous hit areas.
This matters because you cannot predict where every component will be placed once the design system is in the hands of your wider team. Baking safer defaults into the system means integrations inherit good behavior rather than requiring each consumer to solve the same accessibility problem from scratch.
Evidence Over Assumptions
There is no magic formula that yields the perfect target size for every interface. Reaching that answer requires understanding your actual audience and how they work within your application. The most direct way to gain that knowledge is to ask people.
Accessibility research does not have to be a heavy lift or limited to users of assistive technology. Low-fidelity prototypes are an inexpensive way to test assumptions before writing production code. Structured methods for evaluating designs with disabled participants are well documented and increasingly practical to apply.
Settling the Debate
Compliance and usability are related but not identical goals. Meeting the minimum WCAG size does not guarantee a comfortable experience for every user, yet the standard still serves as a necessary starting line for the whole web.
- 24×24 CSS pixels is the minimum for WCAG conformance.
- Inline links within text are exempt from the target-size requirement.
- 44×44 pixels corresponds to an AAA-level rating, which is reserved for niche, high-stakes experiences.
- Platform guidelines from Apple, Android, and others must themselves align with WCAG.
- Devices are multimodal; inputs can come from touch, pointer, voice, or keyboard at different times.
- Design systems should carry accessible sizes by default.
- Very large targets may fail to read as interactive and can trigger accidental activation.
- User research is the only reliable way to know what size works for your specific audience.
