Search topics
Tap targets smaller than 44 by 44 pixels
The basket's buttons are 32 pixels square: enough for the 24-pixel minimum, but short of 44 by 44, so a shaky hand still misses them.
min-width: 32px; min-height: 32px The problem
People with tremors or using a head pointer miss 32-pixel buttons and have to try again.
A shopping basket shows each item on one line: "Linen napkins, Qty 2", then three icon buttons to decrease the quantity, increase it, and remove the item. The buttons are 32 by 32 pixels, 4 pixels apart: the size the tap targets too small and too close together guide uses to fix the same row at Level AA. With a steady hand they are easy to press.
Someone with a tremor aims at plus and the tap lands 18 pixels to the right of its centre, 2 pixels past its edge: nothing happens. They aim again, and the next tap lands in the gap. Raising the quantity from 2 to 5 takes three presses and, on a bad day, twice as many taps. Nothing breaks; the cost is in the retries.
WCAG 2.5.5 Target Size (Enhanced), at Level AAA, asks for every pointer target to be at least 44 by 44 CSS pixels. These buttons are 32. They pass 2.5.8 Target Size (Minimum), which asks for 24, so an AA audit finds nothing. W3C's technique C44 meets 2.5.5 by setting the target's size in CSS, as the fixes below do.
Unlike 2.5.8, 2.5.5 has no spacing exception. At AA, a small target passes when a 24-pixel circle centred on it touches no other target and no other small target's circle; at AAA, empty space around the button doesn't count, and the target itself must be 44 by 44. So widening the gap between these buttons is not a fix here. Where two hit areas overlap, the overlapping part doesn't count towards either target's size.
None of the four exceptions applies. These buttons are not inside a sentence or block of text, the browser didn't set their size, no 44-pixel control on the page does the same thing, and nothing about a basket needs them small. The browser lets a button be any size it is given; 32 pixels was a design choice, and a common one.
The people 2.5.5 is written for are the people 2.5.8 already helps, with more room: compared with these buttons, a 44-pixel target catches a tap up to 6 pixels further out on every side. The same room helps anyone tapping with a thumb on a moving bus, holding a phone in one hand, or tapping with a knuckle or only part of a finger.
3 of 10 groups affected
- No vision (not affected)
- Low vision (affected)
- Colour vision (not affected)
- No hearing (not affected)
- Hard of hearing (not affected)
- No speech (not affected)
- Motor (affected)
- Reach, strength (affected)
- Cognitive (not affected)
- Seizures (not affected)
- Limited reach and strength People with tremors or limited fine motor control land a tap a few pixels from where they aimed. On a 32-pixel button that is often outside it, so they try again, and each try costs effort.
- Limited manipulation A head pointer, eye tracking or a mouth stick wanders more than a hand on a mouse; a 44-pixel target leaves room to settle on it.
- Limited vision People with low vision see the edges of a small button less clearly, so they aim less exactly.
axe-core's target-size rule measures against 24 pixels, the Level AA minimum, so it passes this row. axe has no rule for 2.5.5. The audit measures each control's hit area by testing where clicks along its middle land, from the centre outwards, so a pseudo-element that extends the area counts, and records a lead for each kind of control whose hit area is at least 24 pixels both ways but under 44 in either. Links inside a sentence are skipped. It is a lead because only a person can tell whether a 44-pixel control elsewhere on the page does the same thing. Automated click tests press the exact centre of an element, so they never miss a small one. An AI-generated interface built from a component library inherits its button sizes, and the default and small buttons of shadcn/ui and Bootstrap are all under 44 pixels.
Try it
Turn on the shaky hand, then raise the quantity to 5 by clicking plus.
With the shaky hand on, each click or tap lands up to 20 pixels from where you pointed, and a mark shows where it landed: a green dot on a button, a red ring beside it. Aim at the middle of plus. On the 32-pixel buttons some taps miss; at 44 pixels the same aim lands every time.
Broken Can you fix this?
The fix
Make every tap target at least 44 by 44 pixels.
<div class="line-actions"> <button type="button" aria-label="Decrease quantity">−</button> <button type="button" aria-label="Increase quantity">+</button> <button type="button" aria-label="Remove Linen napkins">×</button></div>What is wrong3 points
- Each target is 32 by 32 pixels, 12 short of 44 in each direction.
- A tap more than 16 pixels from a button's centre, sideways or up and down, misses it.
- The 4-pixel gap doesn't help: space around a target doesn't count towards 2.5.5.
44-pixel buttons
<div class="line-actions"> <button type="button" aria-label="Decrease quantity">−</button> <button type="button" aria-label="Increase quantity">+</button> <button type="button" aria-label="Remove Linen napkins">×</button></div>How it is fixed3 steps
- Raise each button's
min-widthandmin-heightto 44 pixels. The visible button is the whole hit area, so people can see how much room they have. - Keep
flex-shrink: 0, so a narrow screen can't squeeze the buttons back under 44. - Widen the gap to 8 pixels, so the larger buttons don't read as one block.
This fixes the Before and passes 2.5.5, and 2.5.8 with it. The HTML does not change.
Use 44-pixel buttons. They do the same job as the extended hit area with less CSS and nothing invisible to break, and people can see the room they have to aim at. Keep the extended hit area for a design system whose 32-pixel button you can't change: it passes, but people still aim at a 32-pixel shape, and because the area can't be seen, a later change to the gap or the line's padding can make areas overlap or clip without anyone noticing. Spacing the buttons further apart is not an option at this level.
Measure the hit area in CSS pixels, not the icon inside it: padding and pseudo-elements count, and margins do not. A browser hit-tests a rounded button along its rounded edge, and WCAG doesn't say how a round target is measured at this level, so draw a round button inside a square 44-pixel hit area rather than as a 44-pixel circle.
Two widely used component libraries draw their buttons between the two criteria: shadcn/ui's icon buttons run from 24 to 40 pixels, and Bootstrap's buttons are 38 pixels tall, 31 with .btn-sm. Apple's design guidelines give 44 by 44 points as the default control size on iOS and iPadOS, and Android's accessibility guidance asks for 48 by 48 density-independent pixels; in a phone's browser, on a page with a width=device-width viewport, a point or a density-independent pixel is about one CSS pixel, so the three figures can be compared directly. Set the 44-pixel minimum on the shared icon button, not on each use, so a dense row can't shrink it again.
The exceptions are narrow. A link inside a sentence is exempt, but a row of links outside one, such as a footer or a pager, is not. An equivalent 44-pixel control only counts when it is on the same page and does the same thing; don't rely on one hidden in a menu. A control the browser draws counts as the browser's only while its size is left alone.
Design ideas
44-pixel targets can still look light.
Two ways to give the basket line 44-pixel targets without making it look heavy, and two common looks that fall short. Point at each one or Tab to it: the fill that appears is the area that takes the click.
In the design file
- Draw every button and link outside a sentence at 44 by 44 pixels or more, measured on the area that takes the tap.
- When an icon is smaller than its button, draw the 44-pixel button as its own shape, even one that shows only on hover.
- Leave enough gap, and padding above and below the row, that neighbouring 44-pixel areas never overlap.
- Draw a round button inside a 44-pixel square, not as a 44-pixel circle.
Passes
- Bare icons in 44-pixel buttons Only the 20-pixel icons show at rest, as light as a row of small buttons. Each sits in a 44-pixel square with 12-pixel corners that fills on hover and focus, and the squares sit side by side without overlapping.
- Linen napkinsA stepper bar 44 pixels tall Minus, the quantity and plus share one outlined bar 44 pixels tall, its corners rounded like the buttons, so three targets read as one control. Each button is 44 pixels wide, and remove is a 44-pixel square of its own, 8 pixels away.
Fails
- Option chips 32 pixels tallWCAG 2.5.5 Gift wrap and the other extras as outlined pills 32 pixels tall, 8 apart, the height Material Design gives its filter chips. The space between them does not count at this level: make each chip 44 tall, or extend its area to 44.
- Linen napkins Qty 2Save for later and Remove as small wordsWCAG 2.5.5 The actions under the item are words in boxes 28 pixels tall, set like a line of text. A row of actions is not a sentence, so the exception for links in text does not apply: give each word a box 44 pixels tall.
Verify the fix
4 checks.
Test with: Target measurement, Touch, Mouse, Zoom
Record the OS, browser and assistive-technology versions, the build, the date, and the actual result of each step. Repeat after the shared button styles change.
Limits
This is a starting pattern, not a guarantee for every application. Level AAA is rarely required in full, but a site can meet single AAA criteria such as this one. The guide covers icon buttons in one row; grids, sliders and drag handles need their own checks. A target big enough to hit can still act on the wrong press: buttons that act on press and can't be cancelled covers taking a slip back. Test with the people and devices your users actually have.
This is a recreated teaching example, not a finding about a named client. The code is a starting pattern: test it in your own product. No completed assistive-technology test is claimed here.
References
- WCAG Understanding: target-size-enhanced (opens in a new tab)
- WCAG Technique C44 (opens in a new tab)
- WCAG Understanding: target-size-minimum (opens in a new tab)
- developer.apple.com: accessibility (opens in a new tab)
- support.google.com: 7101858 (opens in a new tab)
- developer.mozilla.org: ::before (opens in a new tab)
EaseWeb service
Fixed it? Keep it from coming back.
I turn guides like this one into rules your coding agents follow and checks your CI runs. Then I retest by hand with a keyboard and screen readers, periodically.