Twenty-two of the thirty-six tap targets on our mobile homepage are 20 pixels tall, and the page passes WCAG anyway

WCAG 2.5.8 Target Size (Minimum) asks for 24 by 24 CSS pixels, and it is an AA criterion, which means it is the bar most teams actually hold themselves to. I measured every interactive element on eleven pages of PubTrivia at a 390 pixel viewport expecting to find a pile of failures. I found 22 targets that are 20 pixels tall on the homepage alone, and zero failures. The gap between those two sentences is the whole point of this post.

The sweep

Chrome with Emulation.setDeviceMetricsOverride at 390 by 844, device scale factor 3, mobile flag on. For every a, button, input, select, textarea, [role=button] and summary with a non-zero box, I took getBoundingClientRect(), then for each undersized target measured the centre to centre distance to its nearest neighbour.

Heights on the homepage, as a histogram:

20px x 22    21px x 1    22px x 1    26px x 1
36px x 2     44px x 5    128px x 1   151px x 3

Thirty-six targets. Twenty-four of them are under 24 pixels in one dimension. Five reach 44, and those five are the "Start free, no card needed" buttons. The two at 36 are "Sign in" (77 by 36) and "Get started" (107 by 36) in the header, and the 26 pixel one is the wordmark beside them.

The features index is the worst page on the site by this measure, because it is a long list of links:

17px x 15    19px x 15    20px x 21    22px x 1
26px x 1     36px x 2     44px x 1     128px x 1   151px x 2

Fifty-nine targets, 52 of them under 24 pixels, and exactly one element on the entire page is 44 pixels tall. The 15 targets at 17 pixels are the secondary links under each card, the ones that read "More on per-question timers" and similar: 200 to 320 pixels wide and 16.5 pixels tall, because they are a text-sm line with no padding at all.

Why none of them fail

2.5.8 has five exceptions, and the one that saves this site is Spacing: an undersized target passes if a 24 pixel diameter circle centred on it does not intersect the circle of any other target. In practice that means the centres have to be at least 24 pixels apart.

Our footer is 21 links in five stacked columns, each 20 or 22 pixels tall, with a 12 pixel gap between them. Twenty plus twelve is 32 pixels of centre to centre spacing, so each one clears the circle test with eight pixels to spare. The same arithmetic holds for the card links in the body, which sit in flow with generous vertical rhythm, and for the two header buttons, which are over 24 in both dimensions anyway.

Across the eleven pages I measured, the counts came out like this:

Two hundred and forty-three undersized targets, no failures. That result is not an achievement, it is an accident of using a type scale with normal line spacing and never packing links tightly together. If any one of those footer columns had used a 4 pixel gap instead of 12, the same 20 pixel links would have failed.

The AAA bar is a different story

2.5.5 Target Size (Enhanced) asks for 44 by 44, which is also roughly what Apple and Google have recommended for a decade. Against that bar:

• homepage: 27 of 36 targets under 44
• features: 55 of 59
• FAQ: 27 of 32
• the privacy policy: 10 of 10, with four of its targets at 16 pixels tall

The only things on the site that clear 44 pixels are the primary call to action buttons and the big card links, and the card links clear it by accident: they wrap a heading and a summary paragraph in a single anchor, which is why three of them are 151 pixels tall. A measurement that counts the biggest and smallest targets on our marketing pages is really measuring which elements got a padded button component and which got a bare <a>.

The honest reading of the whole sweep is that we pass the criterion we are measured against and would fail the one a thumb cares about. A 17 pixel high link 300 pixels wide is easy to hit horizontally and fiddly vertically, and the spacing exception exists precisely because that is survivable, not because it is good.

Check it yourself

Open any page on pub-trivia.app, switch DevTools to device mode at 390 pixels wide, and paste this:

[...document.querySelectorAll("a,button,input,select,[role=button]")]
  .map(e => e.getBoundingClientRect())
  .filter(r => r.width && r.height)
  .reduce((a, r) => (a[Math.round(r.height)] = (a[Math.round(r.height)] || 0) + 1, a), {})

You will get the histogram above for whichever page you are on. Then inspect any footer link and read the computed box: 20 pixels tall, 12 pixels of margin below it. The number that decides whether that is a pass is the 12, not the 20, which is the bit of 2.5.8 worth remembering.