Minimum Touch Target Size: WCAG 24px vs Apple 44pt vs Material 48 dp

Minimum Touch Target Size: WCAG 24px vs Apple 44pt vs Material 48 dp

WCAG 2.2 Success Criterion 2.5.8 (Level AA) requires pointer targets of at least 24 by 24 CSS pixels, or enough spacing that 24 px circles around small targets do not overlap. The 44 by 44 CSS pixel figure is the stricter Level AAA criterion, 2.5.5. Apple's 44 by 44 pt and Google's 48 by 48 dp are platform design guidance, not WCAG requirements.

Those four numbers are not competing answers to one question. They come from three bodies, use three different units, and carry three different kinds of weight. A web team audited against WCAG 2.2 AA fails a 20 px icon button with no spacing and passes a 24 px one, whatever Apple or Google recommend. An iOS team following the Human Interface Guidelines aims for 44 pt because Apple's own button guidance says a hit region needs it. An Android team using Jetpack Compose gets 48 dp from the Material components without asking. Picking one number for a shared design system means knowing which of those obligations you actually carry.

The four numbers side by side

This table sets each rule beside its unit, its status and the allowances written into it. Everything in it comes from the documents listed at the end, read on October 31, 2026.

The AAA criterion has no spacing exception at all, so a 30 px button surrounded by empty space still fails 2.5.5. Apple publishes two numbers, not one, and its accessibility page calls 28 by 28 pt the minimum control size on iPhone and iPad. And only the first two rows are conformance language. "Strive to meet," "as a general rule" and "we recommend" are how Apple and Google phrase theirs.

Where the AA rule came from

2.5.8 is new in WCAG 2.2, which W3C published as a Recommendation on October 5, 2023 and reissued in its current dated version on December 12, 2024. The 44 px AAA criterion was carried over from WCAG 2.1, where it was numbered 2.5.5 as well. Teams whose last audit was against 2.1 AA had no target size requirement at Level AA at all; the 2.2 update added the 24 px floor beneath the old AAA figure. Our WCAG 2.2 compliance guide lists the other eight criteria that arrived with it, five of them at Level A or AA.

How WCAG measures a target

The WCAG glossary defines a target as a "region of the display that will accept a pointer action, such as the interactive area of a user interface component." Pointer input covers a mouse, a pen or a touch contact, so 2.5.8 is not a touch-only rule. W3C's Understanding document says it "primarily helps touch users" but also helps mouse and pen users with a tremor or reduced precision.

The measurement is stricter than "24 wide and 24 tall." Understanding 2.5.8 says it must be "conceptually possible to draw a solid 24 by 24 CSS pixel square, aligned to the horizontal and vertical axis" that sits completely inside the target. Four consequences follow for designers:

• Rounded corners can shrink a target below 24. W3C's Figure 3 shows a target whose rounded corners leave no room for the 24 px square. A 24 by 24 box with a large corner radius is undersized. Circular icon buttons are the extreme case: a circle of diameter d holds an axis-aligned square of side d divided by the square root of 2, so a circular hit area needs a diameter of at least 34 CSS px (24 times 1.414 is 33.9) to pass on size alone. A 32 px round button is undersized and must pass by spacing instead.
• Zoom does not help. "The requirement is independent of the zoom factor of the page." When users zoom, CSS pixel sizes stay the same, so you cannot argue that a 16 px target becomes 32 px at 200 percent.
• Overlapping regions do not count twice. The glossary note says that where two targets overlap, the overlapping area "should not be included in the measurement," unless both perform the same action or open the same page. Extending a hit area with a pseudo-element so that it runs under its neighbour can make both smaller under the rule, not larger.
• Covered targets are excused only while covered. Targets hidden under a dropdown, a modal, a cookie banner or a survey prompt are exempt while obscured, but the new content on top is measured like anything else.

One more note from the criterion text matters for sliders and colour pickers. Targets "that allow for values to be selected spatially based on position within the target are considered one target," so a 200 px slider track is one big target, not hundreds of tiny ones. The thumb is a different matter if it is a separate control.

The exceptions, criterion by criterion

The AA and AAA criteria share three exception names but word them differently, and the spacing exception exists only at AA. This comparison is built from the criterion text in each Understanding document.

The AAA inline note adds a useful detail: "A footnote or an icon within or at the end of a sentence is considered to be part of a sentence," so an external-link icon trailing a sentence is exempt there too. The same note says that if a whole sentence is the target and it stands alone, outside a block of text, it needs to be 44 by 44.

The equivalent exception is the one most often stretched. It requires a control that achieves the same function on the same page. A hamburger menu that eventually reaches the same destination as a tiny footer link may or may not qualify; a settings screen elsewhere in the app does not.

Points, dp and CSS pixels at 1x, 2x and 3x

All three units are logical units. None of them is a device pixel, and each is multiplied by the screen's scale factor before it reaches the panel.

• CSS pixel. WCAG defines it as "the canonical unit of measure for all lengths and measurements in CSS," density-independent and set as close as possible to the CSS reference pixel. CSS Values and Units Level 3 defines that reference pixel as the visual angle of one pixel on a 96 dpi device at arm's length, about 0.0213 degrees, and fixes 1px at 1/96 of a CSS inch.
• Apple point. The unit the Human Interface Guidelines use for every size. On a 2x display each point covers 2 by 2 device pixels; on a 3x display, 3 by 3.
• Android dp. Google's density documentation defines one dp as "roughly equal to one pixel on a medium-density screen (160 dpi, or the 'baseline' density)," with the conversion px = dp × (dpi / 160). It gives the scale factor as 1.0 at medium density, 1.5 at high, 2.0 at extra-high and 0.75 at low; the density buckets run up to about 480 dpi (xxhdpi, 3x) and 640 dpi (xxxhdpi, 4x).

Multiplying each rule by those factors gives the device-pixel sizes below. This is our arithmetic from the definitions above; the device pixel ratio for CSS is whatever the browser reports as window.devicePixelRatio.

At any shared scale factor, 48 dp is 4 logical units, or about 9 percent, wider than 44 pt or 44 CSS px, and twice the AA floor. The table also shows why a 3x export from a design tool misleads: a 72 px tall button in an @3x PNG is a 24 pt or 24 CSS px button, sitting exactly on the AA floor, not a generous one.

Two unit errors that keep circulating

"44 pt" written into a stylesheet is not 44 CSS pixels. CSS has its own pt unit, the typographic point, defined in CSS Values Level 3 as 1/72 of an inch, while 1px is 1/96 of an inch. So min-height: 44pt in CSS computes to 44 × 96 / 72 = 58.67 CSS pixels. Apple's point is a different unit with the same name. When a spec says "44 pt" and the developer types 44pt, the button grows a third larger than intended. When the developer instead assumes 44 pt means "44 of whatever unit we use," they may land on 44 dp on Android, which is below Google's 48. Translate Apple's 44 pt as a logical size, not by copying the abbreviation.

48 dp is not a WCAG number. Nothing in WCAG 2.2 mentions 48. It comes from Google's Android documentation, which cites the Material Design accessibility guidelines, and it applies to touch interfaces on that platform. A web page with 40 by 40 CSS px buttons fails Google's recommendation and passes WCAG 2.5.8 comfortably; it fails only 2.5.5, the AAA criterion. Audits that report a 40 px button as a WCAG failure at AA are wrong about the rule, even if the button would be better at 48.

Physical size, as an illustration only

How large any of these feels on a phone depends on the phone, so treat this paragraph as an illustration with stated inputs. Using Android's 160-per-inch baseline as a yardstick, 48 dp is 48 / 160 = 0.3 inch, or about 7.6 mm. If an iPhone shows roughly the same number of points per inch, 44 pt would be about 7 mm and a 24 px web target about 3.8 mm. CSS's nominal 1/96 inch per pixel applies at arm's-length viewing; on a handheld screen held closer, browsers draw each CSS pixel physically smaller, which is why a 24 px target on a phone is much smaller than a quarter inch.

Spacing-circle arithmetic for a row of 16 px icon buttons

The spacing exception is where most of the confusion sits, and the arithmetic is simple enough to do on paper. Take a toolbar of six icon buttons. Each button's clickable area is exactly the 16 by 16 CSS px icon, with no padding. Each is undersized, so 2.5.8 asks whether it passes by spacing.

The rule, from Understanding 2.5.8: centre a 24 CSS px diameter circle (radius 12) on each undersized target's bounding box. The target passes if its circle does not intersect another target or another undersized target's circle. That gives two separate conditions for a pair of neighbours whose centres are d pixels apart:

1. Circle against circle. Two radius-12 circles overlap when d is less than 24. They pass when d is 24 or more.
2. Circle against the neighbouring target itself. The neighbour's near edge sits d − 8 from your centre (8 being half of 16). Your circle reaches it when d − 8 is less than 12, that is, when d is less than 20.

For two undersized neighbours, condition 1 is the stricter one, so the centres must be at least 24 px apart. With 16 px buttons, d equals 16 plus the gap, so the gap must be at least 8 px.

At exactly 24 px between centres, the circles touch without overlapping. W3C treats that as a pass: its Figure 5 shows 20 by 20 targets with a 4 px gap, centres 24 apart, and marks the row as passing.

The overlap figures are 24 − d for the circles and 20 − d for circle against target; they are our calculation from W3C's rule.

The same row, built four ways

Now set the spacing approach beside the alternatives. Each row below holds six icons of 16 px, and the width is what the toolbar occupies in CSS pixels, then in device pixels on a 3x phone.

Build B costs 8 CSS px more than build A across the whole row, and it looks identical. A 16 px glyph centred in a 24 px box leaves 4 px on each side, so the visible space between neighbouring glyphs is 8 px in both builds. The difference is where the clickable area ends. In A, a tap in the space between two icons hits nothing. In B, it hits the nearer button, and the row passes on size, so it keeps passing if someone later drops a larger control right beside it.

That last point is the practical reason to avoid relying on the exception. Build A passes only because of its neighbours. Put a 40 px search field directly against the last icon and the arithmetic changes: the field is not undersized, so only condition 2 applies, and the icon's circle reaches the field's edge unless the gap is at least 12 − 8 = 4 px. W3C's Figure 10 shows exactly this case, a 16 px target needing a 4 px gap from a large one. Stack a second row of 16 px icons below the first with a 1 px gap, as in W3C's Figure 7, and both rows fail vertically even if they pass horizontally. The rows need 8 px between them too.

Build C and D are where the AAA and platform numbers lead. The glyph stays 16 px; only the padding grows. A 44 px box around a 16 px icon leaves 14 px of padding on each side, so neighbouring glyphs sit 28 px apart, which is a deliberate and fairly airy look for a mobile toolbar. Six of them need 264 CSS px, which fits on a 360 px wide phone with room for margins but not much else in the same row.

What Apple actually publishes

The Human Interface Guidelines give the 44 pt figure in two places, and they do not say quite the same thing.

The Buttons page says that "as a general rule, a button needs a hit region of at least 44x44 pt" (60 by 60 pt in visionOS) so that people can select it "whether they use a fingertip, a pointer, their eyes, or a remote." Its change log shows the page last updated on December 16, 2025, for Liquid Glass guidance.

The Accessibility page has a table of control sizes per platform, which we reproduce as published:

The page asks designers to "strive to meet the recommended minimum control size for each platform," and adds that spacing matters as much as size: "about 12 points of padding around elements that include a bezel" and "about 24 points of padding" around the visible edges of elements without one. Its change log shows the last change on June 9, 2025, after a full rewrite on March 7, 2025.

So "Apple requires 44 pt" overstates the source in two ways. Apple does not phrase it as a requirement, and its own table puts the floor for an iPhone control at 28 pt, with 44 pt as the default. For a design system, 44 pt is still the right default on iOS: it is what Apple's own buttons page asks for, and 28 pt is a floor for dense, secondary controls rather than a target. On macOS, where input is a pointer, the numbers drop to 28 and 20 pt, closer to the WCAG AA floor than to the mobile figures.

Where Google's 48 dp comes from

Google's "Make apps more accessible" page for Android, last updated October 23, 2026, says: "For touch interfaces, we recommend that each interactive UI element have a focusable area, or touch target size, of at least 48dpx48dp. Larger is even better." It immediately adds that for precise input, mice and trackpads, "the touch target can be smaller."

Google's Compose accessibility page, updated October 28, 2026, ties the number to Material: set the minimum size to 48 dp "to correctly follow the Material Design accessibility guidelines." It says Material components such as Checkbox, RadioButton, Switch, Slider and Surface enforce this internally, but only when they can receive user actions; a Checkbox with a null onCheckedChange loses the padding. The Material 3 Compose reference describes the minimumInteractiveComponentSize modifier as reserving "at least 48.dp in size to disambiguate touch interactions if the element would measure smaller."

That modifier's documentation has a subtlety worth carrying into any design system that copies it. The Compose page says it "reserves at least 48 dp of layout space in each dimension and centers the element in that space," and that it "doesn't expand the touch target itself." Reserving layout space is the native equivalent of the spacing approach in build A: the neighbours move away, but the tappable area is still the drawn element. In the older View system, Google's Accessibility Scanner help page points to android:minWidth and android:minHeight, or a TouchDelegate that lets a parent handle touches on behalf of a smaller child, to get the 48 dp.

The Material Design site itself renders its pages with a browser script, so the Material figures here are as Google's Android documentation states and cites them. Teams that need Material's own wording should read the accessibility pages on m3.material.io in a browser.

Which number your design system should adopt

A shared system has to pick tokens, and the four numbers do not reduce to one. This is the rule we suggest, written so that each step follows from an obligation or a documented recommendation rather than taste.

1. Set 24 CSS px as the floor for every pointer target, measured as a hit area. It is the only Level AA requirement among the four, and most organisations that conform to anything conform to AA. Make it a lint or design-review rule, not a guideline: no interactive component ships with a hit area that cannot hold a 24 px square, unless one of the 2.5.8 exceptions is named in the component's documentation.
2. Meet 24 with size, not spacing, by default. Build B in the toolbar table costs a few pixels and survives later layout changes. Reserve the spacing exception for documented cases such as dense data grids, where you test the actual layout.
3. Use 44 as the touch default on the web and on iOS. That is the AAA figure in CSS pixels and Apple's button figure in points. Apply it at least to the controls the 2.5.5 Understanding document singles out for larger sizes: those used frequently, those whose result cannot easily be undone, those near the edge of the screen or hard to reach, and those that are part of a sequential task.
4. Use 48 dp on Android, and let the platform components supply it. If your system maps tokens per platform, the same "touch-target" token resolves to 44 on web and iOS and 48 on Android. If you need one number everywhere, choose 48: it satisfies every row of the rule table on touch screens.
5. Allow a dense mode for pointer-first interfaces, but not below 24. Desktop tools, admin tables and design apps can use smaller controls, as Apple's own macOS figures of 28 and 20 pt show. WCAG still applies to them, and its floor is 24 CSS px or valid spacing.

Put as a single sentence: adopt the largest touch figure among the platforms you ship to as the default, and treat 24 CSS px as the floor no web control goes below without a written exception.

The dense-mode figure of 32 to 36 is our suggestion, not a published rule; any value of 24 or more meets 2.5.8.

A note on what the glyph should be

Icon size and target size are separate tokens. A 16, 20 or 24 px glyph inside a 44 px target is a normal pairing, and Google's own Compose example draws a small box inside a 48 dp clickable area. Our guide to icon design principles for interfaces covers glyph grids and stroke weights; the point here is only that enlarging the glyph to fill the target is unnecessary. Padding does the work. When the same icon also ships as an app icon, its export sizes are a different problem entirely, set out in our app icon sizes guide for iOS, Android and PWAs.

Building a larger hit area in CSS without a larger icon

Three techniques cover nearly every case on the web, each with a trade-off.

Padding plus a minimum size. Give the button min-width and min-height of 24px (or 44px) and centre the icon inside. This is the choice least likely to break later, because the hit area is the element's own box and nothing overlaps. Use CSS pixels or rem for these tokens; our px, rem and em guide explains why a rem-based minimum grows with the user's font size while a px one does not. Either satisfies 2.5.8 as long as the computed size at default settings is 24 CSS px or more.

An invisible extension. A positioned ::before or ::after pseudo-element with negative insets enlarges the clickable region beyond the visible button. It works, but the WCAG glossary's overlap note applies: if the extended area runs under a neighbouring target, the overlap does not count toward either target's size. Keep extensions inside the space between controls.

A coarse-pointer media query. The CSS media feature pointer: coarse matches devices whose primary input is imprecise, such as a touch screen. Teams use it to switch from a 24 px dense size to 44 px on touch. Treat it as a progressive improvement, not a substitute for the 24 px floor: a laptop with a touch screen may report a fine primary pointer, and WCAG's floor applies to every pointer type.

Whatever the technique, measure the result in the browser's developer tools in CSS pixels, at 100 percent zoom, and check corner radius. Design files work too, as long as the frame is drawn at 1x, where one unit equals one CSS pixel or one point. Measuring an @2x or @3x export and dividing in your head is how a 24 px button gets recorded as 72.

Auditing an existing screen against all four rules

When a screen arrives for review, this order finds the real failures fastest:

1. List every interactive element that is not inline text. Icon buttons, chips, close buttons, stepper arrows, pagination numbers, checkbox labels, custom scrollbars and carousel dots are the usual suspects.
2. Measure each hit area, not each icon. Record width and height in CSS px or pt. Mark anything that cannot contain a 24 by 24 square as undersized, remembering that a circular hit area needs about 34 px of diameter.
3. For each undersized target, measure centre-to-centre distance to every neighbour. Against another undersized target, 24 or more passes. Against a full-size target, the gap from the small target's edge to the big one must be at least 12 minus half the small target's size in that direction.
4. Check for an exception before calling a failure. Is the same action available through a 24 px control on the page? Is the element a browser default? Is it inside a sentence?
5. Then compare with the platform figures. Anything under 44 on iOS or the web, or under 48 dp on Android, is a design-quality finding rather than an AA failure, and the report should say so.

Carousel dots are the classic case. Eight dots of 8 px with 8 px gaps put centres 16 px apart, so each dot's circle overlaps the next. They fail 2.5.8 unless the previous and next arrows count as an equivalent control for the same function, which they do only if they let users reach every slide.

A tidy audit report keeps the two kinds of finding apart: AA failures that block conformance, and platform-guidance gaps that are worth fixing in the next design-system release. For the rest of the WCAG 2.2 checks designers own, including focus appearance and dragging alternatives, start with our WCAG 2.2 compliance guide, which has a release checklist. Readers coming to this from file and asset questions can find the rest of our web and UI material through the image formats guide that anchors that section, and the design system from scratch guide shows where a target-size token sits among spacing and type tokens.

Touch target questions

Is 44 by 44 pixels required for WCAG 2.2 AA?

No. Level AA requires 24 by 24 CSS pixels under SC 2.5.8, or spacing that satisfies its circle test, or one of its other exceptions. The 44 by 44 CSS pixel figure is SC 2.5.5, which is Level AAA. W3C's Understanding document recommends 44 for important controls, but it is not an AA requirement.

Is Material's 48 dp a WCAG requirement?

No. WCAG never mentions 48. Google's Android documentation recommends 48 by 48 dp touch targets and cites the Material Design accessibility guidelines. A 48 px web target exceeds both WCAG figures, but a 40 px one still passes AA.

Is 44 pt the same as 44 px?

Not in CSS. A CSS pt is 1/72 inch and a CSS px is 1/96 inch, so 44pt in a stylesheet is 58.67px. Apple's point is a separate logical unit multiplied by the display scale (2x or 3x), as is the CSS pixel by the device pixel ratio. Translate Apple's figure as "44 logical units" and write it in your own unit.

Does padding count toward the target size?

Yes. WCAG measures the region that accepts the pointer action, so padding that is part of the clickable element counts. Margin does not, because it is outside the element. Overlapping hit areas do not count for either target unless both do the same thing.

Do text links in a paragraph need to be 24 px tall?

No. Both criteria exempt targets in a sentence. 2.5.8 also exempts targets whose size is constrained by the line height of surrounding text. Standalone links, such as a "Read more" under a card or a list of footer links, are not inline and are measured normally.

Does WCAG target size apply to native iOS and Android apps?

WCAG is written for web content, and its criteria are phrased in CSS pixels. Whether an app must meet it depends on the law or contract that applies to you, a legal question rather than a sizing one. Many native teams treat 2.5.8 as a floor and use Apple's 44 pt or Google's 48 dp as their defaults.

Documents cited, with check dates

• W3C, Understanding SC 2.5.8: Target Size (Minimum), criterion text, exceptions, size requirement and Figures 3, 5, 7 and 10; read October 31, 2026.
• W3C, Understanding SC 2.5.5: Target Size (Enhanced), criterion text, inline notes and the list of controls that merit larger sizes; read October 31, 2026.
• W3C, Web Content Accessibility Guidelines (WCAG) 2.2, W3C Recommendation 12 December 2024, glossary entries for target, pointer input and CSS pixel; read October 31, 2026.
• W3C, CSS Values and Units Module Level 3, Candidate Recommendation Draft 22 March 2024, absolute lengths and the reference pixel; read October 31, 2026.
• Apple, Human Interface Guidelines: Buttons, change log last entry December 16, 2025; read October 31, 2026.
• Apple, Human Interface Guidelines: Accessibility, control size table and padding guidance, change log last entry June 9, 2025; read October 31, 2026.
• Google, Android Developers, Make apps more accessible, page last updated October 23, 2026; read October 31, 2026.
• Google, Android Developers, Accessibility API defaults in Compose, page last updated October 28, 2026; read October 31, 2026.
• Google, Android Developers, androidx.compose.material3 package summary, minimumInteractiveComponentSize entry, page last updated October 26, 2026; read October 31, 2026.
• Google, Android Developers, Support different pixel densities, dp definition, conversion formula and density buckets, page last updated October 23, 2026; read October 31, 2026.
• Google, Android Accessibility Help, Touch target size, Accessibility Scanner guidance; read October 31, 2026.