The 44px Rule Was Always a Compromise. WCAG 2.2 Fixed It. Most Apps Ignored Both.
The 44×44-point minimum touch target recommendation in Apple's Human Interface Guidelines traces back to research on average adult finger width. It was codified in the early years of the iPhone, when the mobile web was new and touchscreens were still a novel interaction mode. The reasoning was sound: the average fingertip is roughly 10–12mm wide, so a 44-point target (approximately 8mm on a standard display density) gives you comfortable margin.
That number became the industry baseline. WCAG 2.1 adopted 44×44 CSS pixels as an enhanced criterion. Google's Material Design recommended 48dp. Every design system picked something in that range and called it done.
Then WCAG 2.2 arrived in October 2023 and revised the formula.
Success Criterion 2.5.8 — the new Level AA minimum — dropped the minimum to 24×24 CSS pixels, but added a spacing requirement: targets smaller than 24×24 need offset spacing that ensures the activation area effectively meets the higher threshold. The change wasn't about making targets smaller. It was about acknowledging that the relationship between adjacent targets matters as much as any individual target's size — and that a rigid single-number standard was masking real-world interaction failures.
Most apps still haven't moved.
Who the Old Standard Was Never Built For
The 44px baseline was derived from average data across a general adult population. That average conceals a distribution.
Research compiled by the Nielsen Norman Group across multiple usability studies found consistent patterns: users over 60 show significantly higher error rates on standard-sized touch targets. Estimates across studies range from 30 to 50% more errors compared to younger adults. Tremor, reduced fine motor control, and decreased grip strength all contribute. The fingertip that comfortably hits a 44px button at 28 becomes unreliable at 68 — not because of user error, but because the target design assumed motor characteristics that change with age.
Parkinson's disease affects roughly 10 million people worldwide. Essential tremor — a neurological condition causing involuntary shaking — affects an estimated 4–5% of adults over 65. Neither condition is rare, and both make sub-optimal touch targets into genuine barriers rather than minor inconveniences. For a user with moderate essential tremor, tapping a standard-sized icon button reliably may require multiple attempts on every single tap, for every single interaction, for every session.
The W3C's Cognitive and Learning Disabilities (COGA) Accessibility Task Force has documented an additional dimension: users with cognitive disabilities may struggle to recover from a missed tap and re-orient to the correct target. A small target isn't just harder to hit — it creates a correction flow that can be disorienting for users who are already managing attention or processing challenges.
The 44px rule served the median user reasonably well. It was never designed for the full range of people who would encounter it.
What WCAG 2.2 Actually Requires
WCAG 2.2 introduced two success criteria for target size. 2.5.5 (Level AAA) sets a 44×44px minimum — unchanged from WCAG 2.1's enhanced criterion. 2.5.8 (Level AA) is the new enforceable minimum: 24×24 CSS pixels, with a spacing requirement for targets that fall below 24×24.
The Level AA designation matters in practice. Level AA is the legally referenced standard in most regulatory frameworks. The European Accessibility Act, which began enforcement for digital products and services in EU member states in June 2025, references WCAG 2.1 Level AA as its technical baseline and increasingly extends toward 2.2 requirements in interpretation guidance.
This means for products operating in European markets, 2.5.8 is no longer aspirational. Dark patterns crossed from design concern to legal liability in 2026 under similar regulatory pressure; accessibility requirements are on the same trajectory, just further along.
What does the implementation look like? In React Native, it typically means adding hitSlop values to small interactive elements — the property that expands the touchable area beyond the visual bounds. In native iOS, it means reviewing frame vs. visual bounds for interactive controls. In web contexts, it means ensuring that padding and spacing on interactive elements produce activation areas that meet the criterion, not just visual sizes. An icon button that renders as 20×20px but has 12px of padding on all sides effectively meets 2.5.8 — but you need to audit it intentionally, because CSS doesn't enforce it automatically.
The Hidden Cost Nobody Logs
The error-rate data is the obvious measurement. There's a harder-to-quantify cost that may matter more: what users do when they consistently fail to hit targets.
Research on user behavior during interface failures shows a consistent pattern: users don't typically attribute the failure to the interface. They attribute it to themselves. "I'm not good with technology." "I have clumsy fingers." "These apps are designed for younger people." The attribution goes inward.
Repeated failed taps on a button that was simply too small — for reasons the user has no visibility into — produce learned helplessness. A gradual withdrawal from that feature, from that flow, from that product. This shows up in analytics as low engagement with specific UI elements. It shows up in customer support as "the app is hard to use." It shows up in churn, eventually, as a user who stopped trying.
The causal chain from "the target was too small" to "the user churned" is real and documented in accessibility research. It's just not logged anywhere as an accessibility failure.
Glassmorphism creates similar invisible barriers: a design decision that reads beautifully on a design review monitor fails users in low-light conditions, on lower-resolution screens, and with aging eyes. The failure doesn't register as a design flaw in aggregate metrics — it registers as individual user frustration that produces no actionable signal.
WCAG compliance doesn't guarantee full accessibility. The gap between what audits check and what creates genuine access is real for cognitive accessibility; it's equally real for motor accessibility. You can pass a 2.1 audit while still systematically failing users with tremor, users on small-screened devices at arm's length, and users whose motor control varies across the day.
What Standard Audits Miss
A standard accessibility audit checks target sizes in isolation — often by measuring the rendered CSS pixel dimensions of interactive elements on a single viewport size. What it typically doesn't assess:
- How adjacent targets interact (do the activation zones overlap, forcing precision that offsets the target size benefit?)
- Target size behavior across different viewport sizes and device pixel ratios
- Whether focus indicators are proportionally large enough to be useful alongside the target
- Whether the error recovery flow — what happens when you tap the wrong thing — is itself accessible
The enforcement gap is between the nominal requirement and the experience it's supposed to produce. A 24×24 button with 8px margin on all sides technically satisfies 2.5.8. A user with moderate tremor still misses it regularly, because the effective activation area, while compliant, wasn't designed with that user's motor range in mind.
The standard is the floor. What you build above it is the actual user experience.
The Conversation That Keeps Getting Deferred
Touch target sizing sits in an uncomfortable position in most design processes. Developers focus on layout and component behavior, not tappable area arithmetic. Designers often assume "big enough" without testing against users with motor difficulties. Product managers don't usually have motor accessibility in their acceptance criteria.
The result: a feature ships, passes whatever audit exists, and the users who were supposed to benefit from the minimum requirements find themselves tapping the wrong button, retrying, and eventually abandoning the flow.
The finger-width research from the early iPhone era was right about the average. It was never right about the distribution. In 2026, with over a billion people aged 60 or older using smartphones globally, "average" is a narrower and less adequate design target than any early mobile guideline anticipated.
The 44px number isn't wrong. It's just no longer the complete question.
Photo by cottonbro CG studio via Pexels.