Standalone links across the site are 17 to 26px tall, under any touch target floor #240

New Issue

Closed

opened 2026-09-10 07:07:23 -05:00 by null · 0 comments

null commented

2026-09-10 07:07:23 -05:00

Owner

Found at build a25077d. 491 findings across all 18 routes and all ten device profiles, in seven components: the three footer columns and the two phone links (a.text-navy-light, 17px), the header nav (17px), the privacy contents (17px), the related-links lists (26px), the back links (20px), the card Learn more links (20px), and the standalone privacy address (20px).

Links inside a sentence are deliberately untouched, because WCAG 2.5.8 exempts them, and padding would reach into the lines above and below. LINK_CLASS in ContentBlocks is used both ways, so it stays padding-free and the callers that need a target add .tap-target beside it.

The trap, which cost a round: vertical padding on an inline box is painted and hit-tested but does not enter the line box, so an inline link reports a taller getBoundingClientRect while overlapping its neighbours. And at space-y-2 even an inline-block overlaps, because the negative margin does not shrink the box, only its effect on layout, so each link reached 8px into a gap its neighbour was already reaching 8px into and hit-testing gave the whole gap to whichever painted last. A target that measures right and is not there is worse than one that measures wrong. So .tap-target is inline-block, and every list that uses it moves to space-y-4 / gap-y-4.

Second trap: growing a 39x17 link to 39x36 changes how it is judged. At 17px tall it is row-shaped and wants 32px; at 36px tall it is compact and wants 44. Footer column links therefore also take block, so the row is the target and the row rule applies. The header nav links take py-3 instead, which is free inside a 72px row.

Also fixed here: the menu button was 40x40 where a compact control wants 44x44, and it is now the only navigation up to 1023px.

Verify: node scripts/device-sweep.mjs reports zero touch_target findings across all ten devices; removing tap-target block from the footer columns and returning them to space-y-2 makes it report 342 again.

Found at build a25077d. 491 findings across all 18 routes and all ten device profiles, in seven components: the three footer columns and the two phone links (`a.text-navy-light`, 17px), the header nav (17px), the privacy contents (17px), the related-links lists (26px), the back links (20px), the card `Learn more` links (20px), and the standalone privacy address (20px). Links **inside a sentence are deliberately untouched**, because WCAG 2.5.8 exempts them, and padding would reach into the lines above and below. `LINK_CLASS` in `ContentBlocks` is used both ways, so it stays padding-free and the callers that need a target add `.tap-target` beside it. The trap, which cost a round: vertical padding on an `inline` box is painted and hit-tested but does not enter the line box, so an inline link reports a taller `getBoundingClientRect` while overlapping its neighbours. And at `space-y-2` even an `inline-block` overlaps, because the negative margin does not shrink the box, only its effect on layout, so each link reached 8px into a gap its neighbour was already reaching 8px into and hit-testing gave the whole gap to whichever painted last. **A target that measures right and is not there is worse than one that measures wrong.** So `.tap-target` is `inline-block`, and every list that uses it moves to `space-y-4` / `gap-y-4`. Second trap: growing a 39x17 link to 39x36 changes how it is judged. At 17px tall it is row-shaped and wants 32px; at 36px tall it is compact and wants 44. Footer column links therefore also take `block`, so the row is the target and the row rule applies. The header nav links take `py-3` instead, which is free inside a 72px row. Also fixed here: the menu button was 40x40 where a compact control wants 44x44, and it is now the only navigation up to 1023px. Verify: `node scripts/device-sweep.mjs` reports zero `touch_target` findings across all ten devices; removing `tap-target block` from the footer columns and returning them to `space-y-2` makes it report 342 again.