WCAG target size is 24 by 24 CSS pixels, unless an exception applies

A pointer target has to be 24 by 24 CSS pixels. A smaller one still passes when a 24 pixel circle on it does not cross the next control. WCAG target size is that rule. It is success criterion 2.5.8, Level AA, added in WCAG 2.2. One button that meets it says nothing about the rest of the page.

What 24 by 24 CSS pixels measures

The size test is a square you could draw inside the control. The W3C understanding of 2.5.8 says a solid 24 by 24 CSS pixel square must fit inside the hit area. That area is the part that accepts the pointer. The square lines up with the page. The drawing on the button can be smaller. The hit area cannot.

CSS pixels stay the same when a person zooms. Pinch-to-zoom is not how you meet it.

There is a stricter sibling. 2.5.5 Target Size (Enhanced) is Level AAA and asks for 44 by 44 CSS pixels. Level AA does not. If a client brief says "AAA target size," they mean 44, not 24.

Who a small target shuts out

WCAG 2.2 added this criterion on 5 October 2023, one of nine new success criteria. The W3C example is a person with a hand tremor who hits Cancel while aiming at Submit, then starts the form over. The understanding page also names phone users, one-handed use, large fingers, and someone on a shaking bus. The harm is the wrong control.

A missing label is a different problem. This one is about the pointer landing where the person meant. Keyboard focus hidden under a banner is a different problem again, and it still takes the Tab key: when a cookie banner covers the button you just tabbed to.

Which smaller targets still pass

Smaller than 24 by 24 CSS pixels is not an automatic miss. The same criterion lists five exceptions. Spacing is the one you can measure with a circle. The other four depend on what the control is for, and the pixels alone will not tell you which one applies.

1. Spacing. Center a circle 24 CSS pixels across on the box. It must not intersect another target, or the circle of another undersized target. The W3C picture is a row of 20 by 20 buttons with 4 CSS pixels between them. That row passes. The same buttons with no gap do not.
2. Equivalent. The same action exists on another control on the same page that does meet the size.
3. Inline. The target sits in a sentence, or the line height of the surrounding text sets its size. Links in a paragraph are the case. A row of page numbers is not a sentence. You can pad those.
4. User agent control. The browser drew it, and the author did not resize it. A default month calendar is the W3C example. Restyle that calendar and the exception is gone.
5. Essential. The tight layout is the information. Map pins are the example. Moving them would lie about where the places are.

The W3C sufficient technique for the spacing case is C42, min-height and min-width on the target container. It is one way to make room. It does not retire the other exceptions, and it does not cover the rest of WCAG 2.2.

How to measure one control

Stay at the zoom the page loads with. Pick a button, an icon link, or another control that is not sitting inside a paragraph. In the inspector, read the box that accepts the click. If a 24 by 24 CSS pixel square fits inside it, the size test is met and spacing is optional.

If the square does not fit, center a circle 24 CSS pixels across on that box. The spacing exception fails when the circle crosses the next control, or the circle of the next small control. Then look for a second, larger control that does the same job. If that one is on the page, the small one can use the equivalent exception. Skip a control the browser drew and the site did not restyle. Skip a map pin whose position is the point.

Do that on the controls people actually hit: the icon row, the pagination, the pair of buttons at the end of a form. A paragraph of links can wait.

What the scan records for target size

A missing row is not a pass. Complience.app runs axe-core 4.13 and asks for the wcag22aa tag, along with the older A and AA tags. That tag is what includes the target-size rule. Deque's rule list for axe-core 4.13 says the WCAG 2.2 checks ship disabled, so a default axe run skips them. This scan is not that default.

The rule's own line is "All touch targets must be 24px large, or leave sufficient space." It passes when the unobscured box is at least 24 CSS pixels, or when the offset to the next widget is. Links inside a block of text are not in the set it checks. Elements in the SVG namespace are not in that set either. A <button> that contains an icon still is, because the button is the widget.

A hard miss is a finding. The report id is axe-target-size, and the impact is serious. When the engine cannot decide, the row goes under Needs manual review. The report says those checks are not included in the score. That bucket is for unfinished work: content overflowing the box, a shape split into too many pieces, or a neighbor that is not in the tab order.

The rule does not apply the equivalent exception, the essential exception, or an unmodified browser control. A finding is a dated negative for that control on that URL. Silence is not a pass of 2.5.8.

What else a WCAG 2.2 checker runs, and what it still leaves to a person, is in what a WCAG 2.2 checker actually covers.